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

[Emily Stark <[e-mail]>]

The URL can be attacker-controlled in the OCSP case too. (
https://github.com/bifurcation/expect-ct/issues/18#issuecomment-295867109)

As I said in my first message, implementing true preflights would violate
very core architectural principles in Chrome, and would jeopardize our
ability to ship an implementation. Maybe there are other implementors who
would like to chime in to the contrary, but as of now I'm not very inclined
to specify something that can't realistically be implemented.

So that leaves the null-origin preflight that Patrick suggested as the only
option on the table. Do you prefer that, Martin?

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

> 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 <[e-mail]> wrote:
> >
> >
> > 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.
> >
> >
>