Stricter MIME type enforcement via Cross-Origin Read Blocking (CORB)

[Łukasz Anforowicz]

Hello,

I just wanted to give you a heads-up about a newly opened Fetch spec issue that is an attempt to start a broader discussion on how to enforce stricter MIME type checking of cross-origin HTML, XML and JSON responses.  The stricter enforcement should help provide extra defense in depth for some XSSI threats, but is also very important for mitigating the new speculative side-channel attacks like Spectre.

Please loop in any other folks who might be interested in the discussion (including people working on browser standards compliance and on Spectre response).  In particular - I don't have direct contacts/emails of folks working on Edge and Safari/WebKit, so I would appreciate if you could please bring this issue to their attention.

Thanks,

Lukasz

[Boris Zbarsky]

On 3/8/18 6:35 PM, Łukasz Anforowicz wrote:
> I just wanted to give you a heads-up about a newly opened Fetch spec

> issue <https://github.com/whatwg/fetch/issues/681> that is an attempt to

> start a broader discussion on how to enforce stricter MIME type checking
> of cross-origin HTML, XML and JSON responses.

I haven't had a chance to read the proposal in detail yet, but just
wanted to say that in our internal discussions stricter enforcement of
content types is somewhat helpful, but quite insufficient, for
mitigating Spectre-like attacks. What we really need are mechanisms
whereby cross-origin fetches with user credentials can never provide
data to a web renderer process without explicit opt-in on the sender
side. I don't see CORB providing that based on my skim just now.

If we _did_ have such mechanisms, then we would not need the complicated
sniffing CORB is trying to create, from a Spectre point of view.

In other words, still from a Spectre point of view, CORB may be a useful
stopgap, but in the long term it would need to be supplanted by a more
general solution. At that point the sniffing parts of CORB will
effectively become technical debt.

-Boris

[Charlie Reis]

It's true that CORB is optimized to protect as much current web content as it can without causing compatibility problems, and that an opt-in mechanism (e.g., server header) would be a good way for sites to tell the browser about content that shouldn't leak.  (The explainer does mention this as a "CORB opt-in header" near the end.)  That would have much a longer adoption time frame, though, and put more existing web content at risk.

I'm not sure those approaches are necessarily opposed to each other-- if there's eventually enough adoption of such an opt-in header, then removing the sniffing logic and protection for other types may just be an implementation change.  I think the main spec changes we're considering are along the lines of content-type tightening (e.g., nosniff vs image tags), which would likely be useful long term even if the sniffing can later be retired.

Charlie

[Łukasz]

RE: complicated sniffing in CORB

I guess that exactly how much of CORB should be covered by web standards is still an open question.  For example - no observable consequences would be caused by blocking of sniff-confirmed non-images in responses going to image destinations.  This probably means that whether sniffing is implemented (and whether sniffed respones are blocked or not) can be seen as an implementation choice or detail of any particular browser.  Therefore maybe details of CORB sniffing don’t need to be covered by the normative part of web standards.  (sniffing _does_ help to protect more resources, but maybe it is sufficient to cover it in the CORB explainer or in a non-normative part of the specs).

OTOH, standardizing CORB-like handling of nosniff responses would go a long way (*) toward ensuring that implementing CORB doesn’t lead to behavioral differences between browsers.  In my opinion, CORB-protecting nosniff images and multimedia seems like a natural extension of the https://fetch.spec.whatwg.org/#should-response-to-request-be-blon cked-due-to-nosniff section in the Fetch spec - I think adding the following extra item/step is a viable option on the table:

8. If _destination_ is “image” (or “audio”, “video” or “track” or “font”) and _mimeType_ (ignoring parameters) is [HTML MIME type](https://mimesniff.spec.whatwg.org/#html-mime-type) or [XML MIME type](https://mimesniff.spec.whatwg.org/#xml-mime-type) (except `image/svg+xml`) or [JSON MIME type](TBD), then return blocked.

What would you think about such an edit in the Fetch spec?  This seems like an alternative version of Firefox’s earlier attempt to block *all* non-image MIME types in presence of the nonsniff header (alternative that is limited to HTML, XML and JSON MIME types + expanded to cover other destinations like audio and video).  The proposed stricter enforcement of Content-Type header seems desirable even if CORB doesn’t immediately help Firefox defend against Spectre (I don’t feel qualified to comment on Firefox security architecture and whether or not CORB can help with Spectre, but I do think that CORB can act as an extra protection against XSSI attacks).

RE: opt-in on the sender side

Maybe I am misunderstanding what you mean by “opt-in on the sender side”, but presence of the nosniff header can be seen as a signal to opt into CORB protection.  Does that make sense?

(*) “long way”, but not the “whole way”, because CORB also causes observable behavior changes when blocking sniff-confirmed, non-javascript responses from script contexts (such blocking can hide a syntax error that would have otherwise occurred).

[Ehsan Akhgari]

Hi everyone,

On Thu, Mar 8, 2018 at 11:59 PM, Łukasz <luk...@chromium.org> wrote:

RE: complicated sniffing in CORB

I guess that exactly how much of CORB should be covered by web standards is still an open question.  For example - no observable consequences would be caused by blocking of sniff-confirmed non-images in responses going to image destinations.  This probably means that whether sniffing is implemented (and whether sniffed respones are blocked or not) can be seen as an implementation choice or detail of any particular browser.  Therefore maybe details of CORB sniffing don’t need to be covered by the normative part of web standards.  (sniffing _does_ help to protect more resources, but maybe it is sufficient to cover it in the CORB explainer or in a non-normative part of the specs).

OTOH, standardizing CORB-like handling of nosniff responses would go a long way (*) toward ensuring that implementing CORB doesn’t lead to behavioral differences between browsers.  In my opinion, CORB-protecting nosniff images and multimedia seems like a natural extension of the https://fetch.spec.whatwg.org/#should-response-to-request-be-blon cked-due-to-nosniff section in the Fetch spec - I think adding the following extra item/step is a viable option on the table:

8. If _destination_ is “image” (or “audio”, “video” or “track” or “font”) and _mimeType_ (ignoring parameters) is [HTML MIME type](https://mimesniff.spec.whatwg.org/#html-mime-type) or [XML MIME type](https://mimesniff.spec.whatwg.org/#xml-mime-type) (except `image/svg+xml`) or [JSON MIME type](TBD), then return blocked.

What would you think about such an edit in the Fetch spec?  This seems like an alternative version of Firefox’s earlier attempt to block *all* non-image MIME types in presence of the nonsniff header (alternative that is limited to HTML, XML and JSON MIME types + expanded to cover other destinations like audio and video).  The proposed stricter enforcement of Content-Type header seems desirable even if CORB doesn’t immediately help Firefox defend against Spectre (I don’t feel qualified to comment on Firefox security architecture and whether or not CORB can help with Spectre, but I do think that CORB can act as an extra protection against XSSI attacks).

RE: opt-in on the sender side

Maybe I am misunderstanding what you mean by “opt-in on the sender side”, but presence of the nosniff header can be seen as a signal to opt into CORB protection.  Does that make sense?

Unfortunately we don't have something clean written up explaining the idea yet, but the rough idea we've been talking about is to extend the CORS protocol as follows:

  * For all cross-origin fetches, strip the user credentials before making the request and append a new client header to the request, let's call it Access-Control-May-Have-Credentials: true.

  * If the server doesn't understand this new header, it will ignore it and respond to the request without user credentials.

  * If the server does understand this new header, it will understand that the client _may_ have credentials that it is withholding from the server.  In case the server is secured against attacks like Spectre, it can respond with a new header, let's call it Access-Control-Allow-Withheld-Credentials: true.  In that case the client will cancel the first fetch and submit a new cross-origin fetch this time not stripping user credentials if they're available, and not sending Access-Control-May-Have-Credentials.

  * If the server sends a response with Access-Control-Allow-Withheld-Credentials to a client that doesn't understand it, the client won't attempt to resubmit the fetch, and it will be left with the response that was generated without user credentials.

With something like this idea, servers that aren't secured against Spectre won't be sending data generated with user credentials to renderer processes, irrespective of the content type.  Of course there are obvious downsides with this idea, for example there is an additional round-trip for successful cross-origin fetches with user credentials, servers obviously would need to opt into it, etc.  But if you imagine having this kind of mechanism, wouldn't CORB then become unnecessary from the viewpoint of mitigating Spectre like attacks?  (I'm ignoring the XSSI aspect for the purpose of this discussion for now...)

Thanks,

Ehsan

[Charlie Reis]

A few questions to see if I understand, since this doesn't seem sufficient at first glance.

I'm not sure how that would help against requests made by image tags, script tags, or other non-fetch requests that don't use CORS.  Would all subresource requests have to use CORS in your proposal?

Stripping credentials also doesn't seem sufficient for protecting private content in all cases, like cases of ambient authority (e.g., access to intranet resources).  Are you picturing something like RFC 1918 for that?

(The extra round trip for credentialed requests also seems unfortunate, as you note.)

Charlie

[Ehsan Akhgari]

On Fri, Mar 9, 2018 at 6:31 PM, Charlie Reis <cr...@chromium.org> wrote:

A few questions to see if I understand, since this doesn't seem sufficient at first glance.

I'm not sure how that would help against requests made by image tags, script tags, or other non-fetch requests that don't use CORS.  Would all subresource requests have to use CORS in your proposal?

That's the rough idea, yes.  (This part hasn't been completely figured out yet.)

 

Stripping credentials also doesn't seem sufficient for protecting private content in all cases, like cases of ambient authority (e.g., access to intranet resources).  Are you picturing something like RFC 1918 for that?

The problem of ambient authority has been brought up.  I don't think anyone on our side has thought of a specific solution for it yet (others can correct me if I'm wrong on this, it's been a few weeks since we last discussed this internally.)

(The extra round trip for credentialed requests also seems unfortunate, as you note.)

Indeed.  :-(

Cheers,

Ehsan

[Anne van Kesteren]

On Sat, Mar 10, 2018 at 9:10 AM, Ehsan Akhgari <eakh...@mozilla.com> wrote:
> On Fri, Mar 9, 2018 at 6:31 PM, Charlie Reis <cr...@chromium.org> wrote:
>> (The extra round trip for credentialed requests also seems unfortunate, as
>> you note.)
>
> Indeed. :-(

If this is a new mechanism anyway, it seems that using
https://wicg.github.io/origin-policy/ might be a good thing to curb
the many additional roundtrips somewhat. (Of course, that technology
is still somewhat unproven itself, but it's worth figuring out if it
can work before we impose such a massive penalty I think.)


--
https://annevankesteren.nl/

[Ehsan Akhgari]

Maybe?

That proposal as you know gives you an origin-wide mechanism, it's unclear to me how much of the security aspects here is something servers out there can ascertain on a per-resource or per-directory basis versus on a per-origin basis (I'm asking an honest question, not suggesting something disguised as a question!).  If we end up deciding to use this mechanism as our only answer to avoid round trips, it would be nice to have some evidence on hand to suggest that most servers can be secured on a per-origin basis...

Plus, that proposal as it is has some serious issues.  For one thing it adds a new vector for third-party tracking and surveillance to the Web platform.  It seems questionable to me if that's a palatable value proposition in the current age, I think Mozilla isn't too interested in extending the current technical capabilities of trackers on the Web, so adopting that solution would require addressing those issues.  Hopefully we can work to solve them but I haven't had enough chance to evaluate how much the tracking aspects are baked into the core concepts yet.

Cheers,

Ehsan

[Anne van Kesteren]

On Mon, Mar 12, 2018 at 4:50 PM, Ehsan Akhgari <eakh...@mozilla.com> wrote:
> That proposal as you know gives you an origin-wide mechanism, it's unclear
> to me how much of the security aspects here is something servers out there
> can ascertain on a per-resource or per-directory basis versus on a
> per-origin basis (I'm asking an honest question, not suggesting something
> disguised as a question!). If we end up deciding to use this mechanism as
> our only answer to avoid round trips, it would be nice to have some evidence
> on hand to suggest that most servers can be secured on a per-origin basis...

That's a good point, we would need both. So I guess we just need to
make it so that it doesn't preclude an origin-wide solution at some
future point.

> Plus, that proposal as it is has some serious issues. For one thing it adds
> a new vector for third-party tracking and surveillance to the Web platform.
> It seems questionable to me if that's a palatable value proposition in the
> current age, I think Mozilla isn't too interested in extending the current
> technical capabilities of trackers on the Web, so adopting that solution
> would require addressing those issues. Hopefully we can work to solve them
> but I haven't had enough chance to evaluate how much the tracking aspects
> are baked into the core concepts yet.

Yeah, I think the plan is to revise how this works, but it's not
seeing much action at the moment unfortunately.


--
https://annevankesteren.nl/

[Łukasz]

I think we can agree that the value offered by CORB may differ depending on

1. the threats considered (e.g. XSSI vs Spectre)
   
2. the browser (e.g. CORB defense against Spectre depends on Site Isolation)
   
3. the timeline (e.g. CORB might become obsolete if all subresources default to non-credentialed requests, but this seems unlikely to happen soon due to the potential to break existing websites)

I think it is fine to disagree on the value of CORB as long as we can agree on the desirability of the spec changes for covering aspects of CORB that have web-observable effect on the existing websites.  I heard that many people are excited about restricting those MIME types further - this is exactly the kind of spec changes that CORB needs.

So - what do you think about the proposal (*) about blocking nosniff responses for image destinations if the Content-Type of the response HTML, XML or JSON?

• Are there high-level concerns that need to addressed before proceeding (e.g.  do we need more web compatibility data?  or maybe we should discuss how/if the changes are beneficial even without CORB?).
• Or do we just need to iron out the low-level details (e.g. where to define what JSON MIME type means?  or if we need to account for the fact that today CORB blocking doesn't result in network errors?  do we need to worry about 206 and/or text/plain?)
  

Thanks,

Lukasz

PS. This is the first time I am trying to have a discussion about changing the web standards, so please let me know if I should be doing something differently.  For example - maybe instead of exchanging emails I should be adding comments to https://github.com/whatwg/fetch/issues/681 or maybe I should just wrap the changes I am proposing into a code review or a pull request?  I am always open to feedback :-)

(*) https://groups.google.com/a/chromium.org/d/msg/site-isolation-dev/pp5C8XKz7AI/qWmSyFkkBgAJ:

An extra step/item can be added to https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff? :

8. If _destination_ is “image” (or “audio”, “video” or “track” or “font”) and _mimeType_ (ignoring parameters) is [HTML MIME type](https://mimesniff.spec.whatwg.org/#html-mime-type) or [XML MIME type](https://mimesniff.spec.whatwg.org/#xml-mime-type) (except `image/svg+xml`) or [JSON MIME type](TBD), then return blocked.

[Anne van Kesteren]

On Thu, Mar 15, 2018 at 12:02 AM, Łukasz <luk...@chromium.org> wrote:
> I think it is fine to disagree on the value of CORB as long as we can agree
> on the desirability of the spec changes for covering aspects of CORB that
> have web-observable effect on the existing websites. I heard that many
> people are excited about restricting those MIME types further - this is
> exactly the kind of spec changes that CORB needs.

Yes, we definitely like to be more strict on Content-Type in general
if possible. Chrome proving that is definitely welcome.

> So - what do you think about the proposal (*) about blocking nosniff
> responses for image destinations if the Content-Type of the response HTML,
> XML or JSON?

I forgot what issues Firefox hit with this last time, but if Chrome is
willing to take the hit I'm pretty sure we'd put that check back in as
well. (I copied Christoph who implemented nosniff functionality in
Firefox.)

> Are there high-level concerns that need to addressed before proceeding (e.g.
> do we need more web compatibility data? or maybe we should discuss how/if
> the changes are beneficial even without CORB?).

I think there's rough implementer support for putting more
restrictions on responses in general. The other things a standard
change needs are tests, a PR against the standard detailing the
changes, and browser bugs against the browsers that haven't
implemented the change yet and don't have a bug on file already.

> Or do we just need to iron out the low-level details (e.g. where to define
> what JSON MIME type means? or if we need to account for the fact that today
> CORB blocking doesn't result in network errors? do we need to worry about
> 206 and/or text/plain?)

We definitely care about all of these, including test coverage for
them, as they lead to observably different behavior on the web.

> PS. This is the first time I am trying to have a discussion about changing
> the web standards, so please let me know if I should be doing something
> differently. For example - maybe instead of exchanging emails I should be
> adding comments to https://github.com/whatwg/fetch/issues/681 or maybe I
> should just wrap the changes I am proposing into a code review or a pull
> request? I am always open to feedback :-)

Given the sensitive nature of Spectre a private email thread seems
fine. Normally we'd discuss everything in the public issue itself.

> (*)
> https://groups.google.com/a/chromium.org/d/msg/site-isolation-dev/pp5C8XKz7AI/qWmSyFkkBgAJ:
> An extra step/item can be added to
> https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff?
> :
>
> 8. If _destination_ is “image” (or “audio”, “video” or “track” or “font”)
> and _mimeType_ (ignoring parameters) is [HTML MIME
> type](https://mimesniff.spec.whatwg.org/#html-mime-type) or [XML MIME
> type](https://mimesniff.spec.whatwg.org/#xml-mime-type) (except
> `image/svg+xml`) or [JSON MIME type](TBD), then return blocked.

FWIW, when I looked at the Chrome source code it seemed to me that you
had a different XML MIME type definition than the one you link to
here. In particular it considered text/xml+something an XML MIME type
as well for the purposes of CORB (despite Chrome not parsing such MIME
types as XML). That kind of nuance will be important to get right and
test for.

Hope this helps,


--
https://annevankesteren.nl/

[Łukasz]

On Thursday, March 15, 2018 at 3:01:30 AM UTC-7, Anne van Kesteren wrote:

On Thu, Mar 15, 2018 at 12:02 AM, Łukasz <luk...@chromium.org> wrote:
> I think it is fine to disagree on the value of CORB as long as we can agree
> on the desirability of the spec changes for covering aspects of CORB that
> have web-observable effect on the existing websites.  I heard that many
> people are excited about restricting those MIME types further - this is
> exactly the kind of spec changes that CORB needs.

Yes, we definitely like to be more strict on Content-Type in general
if possible. Chrome proving that is definitely welcome.

Ack.  I guess this means that one important milestone will be trying to ship Chrome's implementation of CORB to the stable channel and being on the lookout for breakage (and hopefully we'll be able to get back with good numbers from the stable release channel).  One thing I want to reiterate here is that we are quite flexible when it comes to making tweaks to CORB (so far it hasn't been enabled outside of Site Isolation trials on Dev and Canary) - please let us know if you have any feedback around CORB's behavior.

> So - what do you think about the proposal (*) about blocking nosniff
> responses for image destinations if the Content-Type of the response HTML,
> XML or JSON?

I forgot what issues Firefox hit with this last time, but if Chrome is
willing to take the hit I'm pretty sure we'd put that check back in as
well. (I copied Christoph who implemented nosniff functionality in
Firefox.)

I think this Firefox issue (nosniff images with application/octet-stream MIME type work in Chrome but not Firefox) was the main cause for relaxing the nosniff rules in the Fetch spec.  Before that Fetch spec change, the original nosniff rules tried to cover images, fonts, tracks, service workers, etc (BTW: this makes me wonder how nosniff interacts with service workers in Chrome today - I assumed that these are handled in the same way as <script> tags, but maybe I should double-check...).

Taking that learning experience into account, we restricted CORB to only block HTML, XML and JSON - this avoids having to deal with application/octet-stream.  OTOH, we would love to extend blocking to other MIME types (e.g. PDFs, ZIPs, etc.) - ideally by switching from a blacklist approach (block HTML, XML, JSON) back to the original whitelist approach that Firefox tried (block everything except image/*, application/octet-stream, some other generic-or-legacy MIME types...).  To minimize the risk for now, we've only covered this in the "Appendix: Future work - protecting more resource types" section of the CORB explainer.

> Are there high-level concerns that need to addressed before proceeding (e.g.
> do we need more web compatibility data?  or maybe we should discuss how/if
> the changes are beneficial even without CORB?).

I think there's rough implementer support for putting more
restrictions on responses in general. The other things a standard
change needs are tests,

 

This is a good point.  So far we have 14 tests for CORB, but

• most of them just check that CORB isn't observable (and therefore depend on existing standards / are somewhat redundant wrt other existing WPT tests)
• 1 test that CORB doesn't break text/css
• only 2 tests that verify CORB-induced behavior (both marked as "tentative").  One problem with test authoring is that most of CORB is not web-observable (e.g. blocking of headers in general, blocking of _sniffed_ images, etc.), so tests are forced to verify that CORB had an effect in a very crude way (e.g. by doing image comparison against a reference-html that includes a non-blocked empty image - see img-png-mislabeled-as-html-nosniff.tentative.sub-expected.html).
  

a PR against the standard detailing the changes,

Okay - I can try to propose more specific/detailed spec changes.

 

and browser bugs against the browsers that haven't
implemented the change yet and don't have a bug on file already.

Ack.

> Or do we just need to iron out the low-level details (e.g. where to define
> what JSON MIME type means?  or if we need to account for the fact that today
> CORB blocking doesn't result in network errors?  do we need to worry about
> 206 and/or text/plain?)

We definitely care about all of these, including test coverage for
them, as they lead to observably different behavior on the web.


> PS. This is the first time I am trying to have a discussion about changing
> the web standards, so please let me know if I should be doing something
> differently.  For example - maybe instead of exchanging emails I should be
> adding comments to https://github.com/whatwg/fetch/issues/681 or maybe I
> should just wrap the changes I am proposing into a code review or a pull
> request?  I am always open to feedback :-)

Given the sensitive nature of Spectre a private email thread seems
fine. Normally we'd discuss everything in the public issue itself.

Sounds good.  Please note that this discussion thread includes site-isol...@chromium.org in CC - this is a public discussion list, so if any sensitive issues come up in the future we should make sure to remove it from the list of recipients.

> (*)
> https://groups.google.com/a/chromium.org/d/msg/site-isolation-dev/pp5C8XKz7AI/qWmSyFkkBgAJ:
> An extra step/item can be added to
> https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff?
> :
>
> 8. If _destination_ is “image” (or “audio”, “video” or “track” or “font”)
> and _mimeType_ (ignoring parameters) is [HTML MIME
> type](https://mimesniff.spec.whatwg.org/#html-mime-type) or [XML MIME
> type](https://mimesniff.spec.whatwg.org/#xml-mime-type) (except
> `image/svg+xml`) or [JSON MIME type](TBD), then return blocked.

FWIW, when I looked at the Chrome source code it seemed to me that you
had a different XML MIME type definition than the one you link to
here. In particular it considered text/xml+something an XML MIME type
as well for the purposes of CORB (despite Chrome not parsing such MIME
types as XML). That kind of nuance will be important to get right and
test for.

Thanks for catching this - I'll try to take a closer look. 

Hope this helps,

It does - thanks! :-) 

--
https://annevankesteren.nl/

[Anne van Kesteren]

On Thu, Mar 15, 2018 at 4:39 PM, Łukasz <luk...@chromium.org> wrote:
> (BTW: this makes me wonder how nosniff interacts with service
> workers in Chrome today - I assumed that these are handled in the same way
> as <script> tags, but maybe I should double-check...).

If you mean the service worker script itself, that should already be
restricted to a JavaScript MIME type, irrespective of the nosniff
header. For other worker scripts, there's
https://github.com/whatwg/html/issues/3255 (filed by someone else from
Chrome).

> Sounds good. Please note that this discussion thread includes
> site-isol...@chromium.org in CC - this is a public discussion list, so
> if any sensitive issues come up in the future we should make sure to remove
> it from the list of recipients.

I noticed that after sending my email... I guess there's already
enough information out there that folks can figure it out by
themselves.


--
https://annevankesteren.nl/