Re: Issue #356: Form-encode Expect-CT report bodies?

The "first principles" notion also refers to the fact that the URL is
attacker-controlled.  Being hard to do isn't a great reason not to
preflight, though it is something to consider.

On 9 June 2017 at 16:10, Emily Stark <estark@google.com> wrote:
>
>
> On Fri, Jun 9, 2017 at 8:01 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> On 9 June 2017 at 16:53, Emily Stark <estark@google.com> wrote:
>> > CSP reporting isn't added to the CORS whitelist. It's been in violation
>> > of
>> > CORS for years and there are some vague plans to fix it by sending
>> > preflights, but adding it to the whitelist hasn't really been discussed.
>> > Anne has said that he prefers not to add more to the whitelist, which I
>> > think is a reasonable stance. (see
>> > https://lists.w3.org/Archives/Public/public-webappsec/2017Feb/0009.html
>> > --
>> > though to be fair, the same text/plain idea is rejected in that thread
>> > as
>> > well)
>> >
>> > In addition to the fact that there's not really any principled reason
>> > for
>> > expanding the whitelist, it would mean that, say, an XHR can send the
>> > new
>> > header value, which shouldn't really be allowed.
>>
>> Ahh, I remembered that discussion, but failed to get that critical
>> detail.  My point is that if you want to avoid a preflight, then make
>> sure that you have an analysis to back it up, don't just dodge the
>> issue by using a whitelisted MIME type.
>>
>> If that means using a preflight, then great.  If we go back to first
>> principles, the "POST to intranet site" case would seem to suggest
>> that some preflighting is warranted.
>>
>> Ultimately, I want the same answer for this and for CSP reports.  I
>> would rather not add this to the pile of violating mechanisms though.
>
>
> These are quite different scenarios though. With CSP, sending preflights is
> totally doable and makes sense, except for the fact of the widely deployed
> reporting servers that would break if we suddenly started requiring them to
> respond to preflights. Expect-CT and HPKP are done as part of certificate
> verification and it's not clear that they should be governed by CORS any
> more than OCSP requests or any request made by the OS in the course of
> loading a webpage. I agree with your "first principles" argument that if
> they are cross-origin requests triggered in the course of loading a web
> page, then they can be used by malicious web content and should be subject
> to CORS... but at the same time I'm not sure that it's practical to require
> that any request at any layer of the system triggered during the course of
> loading a web page should go through Fetch and send preflights if needed.
>
>

Received on Friday, 9 June 2017 15:23:04 UTC