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

[Emily Stark <[e-mail]>]

On Fri, Jun 9, 2017 at 8:01 AM, Martin Thomson <[e-mail]>
wrote:

> On 9 June 2017 at 16:53, Emily Stark <[e-mail]> 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.