Intent to Implement and Ship: Cross-Origin Read Blocking (CORB)

[Charlie Reis]

Contact emails

cr...@chromium.org, luk...@chromium.org, ni...@chromium.org

Explainer

chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md

Spec

We have started spec discussions on all web-visible impacts of CORB in https://github.com/whatwg/fetch/issues/681.  These include changes to:

• Nosniff handling (e.g., blocking cross-site HTML/XML/JSON responses with nosniff headers)

• 206 responses (e.g., blocking cross-site range request responses labeled as HTML/XML/JSON)

• Script responses (e.g., whether syntax errors occur on blocked responses for script tags)

• Blocking based on JSON security prefixes

In coordination with the spec editor, we have decided on a strategy for incrementally submitting pull requests for each of these changes separately.  We have started https://github.com/whatwg/fetch/pull/686 for nosniff handling so far, and plan to continue submitting pull requests for the rest.

We are also discussing future extensions of CORB such as opting in via a From-Origin header in https://github.com/whatwg/fetch/issues/687.

Summary

Cross-Origin Read Blocking (CORB) is an algorithm by which dubious cross-origin resource loads may be identified and blocked by web browsers before they reach the web page. CORB reduces the risk of leaking sensitive data by keeping it further from cross-origin web pages. In most browsers, it keeps such data out of untrusted script execution contexts. In browsers with Site Isolation, it can keep such data out of untrusted renderer processes entirely, helping even against side channel attacks like Spectre.

Many of the effects of CORB are not observable since the responses it blocks tend to be opaque to web pages in the first place.  A few observable consequences have been identified, which are being covered in the spec discussions linked above.  This intent is about getting approval to ship these web-observable consequences.

An initial implementation of CORB has been shipped behind a flag since Chrome 63, specifically for users and enterprises who have opted into Site Isolation.  Currently, CORB only protects responses retrieved from isolated origins and sites.  This intent proposes enabling CORB by default, even in absence of Site Isolation.

(Note that CORB was earlier referred to as "cross-site document blocking," or XSDB.)

Motivation

Speculative side-channel attacks like Spectre pose an important challenge for web browsers, since the risk of leaking cross-site data to an attacker's page has increased.  Blocking potentially sensitive responses with CORB provides a key mitigation for Spectre when used together with Site Isolation.

CORB also helps to mitigate Cross-Site Script Inclusion (XSSI) attacks, where pages are able to infer the contents of (typically opaque) cross-site responses, using script tags or other techniques.  CORB keeps the data in such responses out of the page's execution context. For more details, see the explainer's list of mitigated attacks.

Additionally, CORB provides an incentive to web developers to use accurate MIME types and the X-Content-Type-Options: nosniff header, which may be desirable in general.

Risks

Interoperability and Compatibility

For features subject to the same-origin policy (e.g. fetch/XHR), CORB is a defense-in-depth and should not be observable by web content.  However, CORB may have web-visible impact for features that are not subject to the same-origin policy, such as img and script tags.  More specifically, the explainer identifies two cases where CORB impact is web observable:

• Cross-origin <img> elements, where the response contains an image but is mislabeled as text/html content type and served with a X-Content-Type-Options: nosniff header.  CORB would block such an image.

• Cross-origin <script> elements, where the response contains html and the correct text/html Content-Type is used.  When CORB blocks such a response, no syntax error will be generated and sent to the window's "error" event handler.

Based on the data gathered so far, the explainer puts an upper bound on the number of impacted responses: 0.115% of all CORB-eligible responses might have been observably blocked due to a nosniff header or range request.  95.16% of these cases are nosniff responses labeled as HTML requested by an image tag. These are blocked and could possibly contain real images, but we expect most of them actually contained HTML and would not have rendered anyway (as in the only confirmed case so far, which was a tracking pixel).

We have heard tentative support and interest from Firefox and Safari in the spec changes needed for CORB, as we make progress on the spec discussions.

Edge: No signals

Firefox: Public support

Safari: Public support

Web developers: No signals

Ergonomics

CORB might benefit from a future extension that allows applying similar response blocking to more cases, such as From-Origin.  Otherwise CORB shouldn't impact the ergonomics of other APIs, other than providing incentives for web developers to use more accurate MIME types.

CORB should have low risk to performance.  The main impact is that CORB sometimes needs to sniff a response, buffering until an allow/block decision can be made.  This can potentially increase the latency for receiving the first bytes in the renderer, but in practice this should have low impact and happen rarely:

• Sniffing usually makes a decision within the first ~100 bytes.

• Sniffing is only applied to a subset of content types.

• Sniffing is not necessary when the X-Content-Type-Options: nosniff header is present.

• Some sniffing is already done without CORB (by MimeSniffingResourceHandler).

Activation

Developers don’t need to take any extra steps to activate CORB, but they can increase the chance their sensitive data is protected by using correct MIME types and "nosniff" headers (or possibly in the future, using From-Origin).  Polyfills and/or JavaScript libraries are not applicable to CORB.  Recommendations for web developers are available at https://www.chromium.org/Home/chromium-security/site-isolation#TOC-Recommendations-for-Web-Developers, and an audit feature is planned in https://crbug.com/806070.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes, CORB can be supported on all platforms.  Note that it has additional benefits when Site Isolation is enabled, which is currently on track for Windows, Mac, Linux, and Chrome OS.  Experimental support for Site Isolation is available on Android but not yet Android WebView.

Demo link

To test CORB one can turn on the feature by launching Chrome with the --enable-features=CrossSiteDocumentBlockingAlways command line flag.

CORB demo page: https://anforowicz.github.io/xsdb-demo/index.html

Debuggability

Resources blocked by CORB trigger a console message similar to:

Blocked current origin from receiving cross-site document at https://www.chromium.org/ with MIME type text/html.

We are also tracking the plan to add an “audit” feature in the future: https://crbug.com/806070.

Is this feature fully tested by web-platform-tests?

Web-observable aspects of CORB are covered by tests under wpt/fetch/corb.

CORB should not be observable by web features in most cases, which makes it difficult to cover some aspects of CORB with WPT (e.g. see the “Correctly-labeled HTML document” example in the “Observable CORB impact on images” section of the explainer).

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5629709824032768

Requesting approval to ship?

Yes.

[Chris Harrelson]

Hi,

My reading of this intent is that it is requesting approval to ship CORB in general, which in practice would have an evolving definition as the spec and implementation mature and become complete. In the interests of a predictable API surface for developers, consensus-driven specs, and to make it easier to assess compatibility risk to this intent, can you instead propose to ship a precise list of changes to behavior?

An example might be: cross-origin images whose response type doesn't satisfy a list of requirements (listed in some precise spec text) may not be loaded, resulting in a networking error.

Chris

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH%2B8MBbV3VaEv6dt24888_bQbncdMB2HWLcZAxhNJty6iPgs1g%40mail.gmail.com.

[Jochen Eisinger]

I'm in general supportive but agree with Chris that it would be helpful to spell out exactly which changes you plan to ship with this intent.

[Charlie Reis]

Sure, I'll rephrase it and send it back out soon.  Thanks for the suggestion!

Charlie

[Daniel Bratell]

I think it's border line whether this is even a web facing change. If my quick read didn't overlook anything, the goal is to have no observable effects and the implementation seems to be close to that.

The only example of an observable effect is an image served with content type text/html (or some other non-image type) along with the nosniff header telling the browser to basically trust the content type? That it is renderered as an image today seems almost accidental.

You mention that the upper limit of affected requests is 0.1% of the CORB enabled requests (with zero known actual cases), but what percentage is that of the total number of requests?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH%2B8MBZGroZVwCZ4iGUn8pzbYdSS20BAypHKxj_cTw%2BTYiLF3Q%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Charlie Reis]

Thanks for the feedback.  Since some discussion has happened already, I'm sending the revised Intent (based on Chris's suggestion) within the same thread.  Other replies below.

Intent to Implement and Ship: Web Platform Changes for CORB

Contact emails

cr...@chromium.org, luk...@chromium.org, ni...@chromium.org

Explainer

chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md

Spec

Under the umbrella of CORB spec changes discussed in https://github.com/whatwg/fetch/issues/681, we are proposing the following 4 observable changes to web platform behavior:

1) Cross-origin requests for images, media, and fonts will receive empty responses if the response from the network has an HTML, XML, or JSON content type and a nosniff response header.  The responses' headers will be filtered to CORS safelisted response headers and CORS response headers.

Discussion: https://github.com/whatwg/fetch/pull/686

2) Cross-origin requests from media tags will receive empty responses if the response from the network has a 206 (range request) status and an HTML, XML, or JSON content type.  The responses' headers will be filtered to CORS safelisted response headers and CORS response headers.

3) Cross-origin requests from script tags will receive empty responses if the response from the network has an HTML, XML, or JSON content type and is confirmed to be HTML, XML, or JSON using confirmation sniffing logic.  The responses' headers will be filtered to CORS safelisted response headers and CORS response headers.  Such responses would not have run successfully anyway, but now they will not generate a syntax error.  (Note: responses with nosniff headers and the wrong content type are already blocked from script tags.)

4) Cross-origin requests from script tags will receive empty responses if the response from the network starts with a JSON security prefix and is not otherwise permitted via CORS.  The responses' headers will be filtered to CORS safelisted response headers and CORS response headers.  Such responses would not have run successfully anyway, but now they will not trigger infinite loops (e.g., when the for(;;); prefix is present).  (Note: these responses will be blocked in other cases as well, but the effect is not observable for other tag types, such as images.)

Note that changes 2-4 do not yet have spec pull requests of their own: in coordination with the spec editor, we have decided on a strategy for incrementally submitting pull requests for each of these changes separately.  Telemetry gathered so far for CORB shows that only change 1 has a practical impact (with images requests being blocked by CORB most often).

Summary

Cross-Origin Read Blocking (CORB) is an algorithm that can identify and block dubious cross-origin resource loads in web browsers before they reach the web page. CORB reduces the risk of leaking sensitive data by keeping it further from cross-origin web pages. In most browsers, it keeps such data out of untrusted script execution contexts. In browsers with Site Isolation, it can keep such data out of untrusted renderer processes entirely, helping even against side channel attacks like Spectre.

Many of the effects of CORB are not observable since the responses it blocks tend to be opaque to web pages in the first place.  However, we are proposing to ship 4 observable changes to the web platform to make CORB possible, as outlined in the Spec section above.

An initial implementation of CORB has been shipped behind a flag since Chrome 63, specifically for users and enterprises who have opted into Site Isolation, allowing us to collect data about CORB's impact on compatibility.  (Note that CORB was earlier referred to as "cross-site document blocking," or XSDB.)

Motivation

The 4 changes to the web platform outlined allow CORB to protect as many resources as possible while disrupting as few legitimate use cases as possible.  Rather than adopting a purely opt-in approach that might face a slow period of adoption (and thus vulnerability to Spectre attacks), these changes allow CORB to protect a broad class of responses with existing nosniff headers, or which can be confirmed to be HTML, XML, and JSON.

CORB itself provides a key mitigation for speculative side-channel attacks like Spectre, when used together with Site Isolation.  CORB also helps to mitigate Cross-Site Script Inclusion (XSSI) attacks, where pages are able to infer the contents of (typically opaque) cross-site responses, using script tags or other techniques.  CORB keeps the data in such responses out of the page's execution context. For more details, see the explainer's list of mitigated attacks.

Additionally, CORB and the 4 changes proposed here provide an extra incentive to web developers to use accurate MIME types and the X-Content-Type-Options: nosniff header, which may be desirable in general.

Risks

Interoperability and Compatibility

Based on the data gathered so far, the explainer puts an upper bound on the number of impacted responses from the 4 proposed spec changes: 0.115% of all CORB-eligible responses might have been observably blocked due to a nosniff header or range request.  95.16% of these cases are nosniff responses labeled as HTML requested by an image tag. These are blocked and could possibly contain real images, but we expect most of them actually contained HTML and would not have rendered anyway (as in the only confirmed case so far, which was a tracking pixel).

We have heard tentative support and interest from Firefox and Safari in the spec changes needed for CORB, as we make progress on the spec discussions.

Edge: No signals

Firefox: Public support

Safari: Public support

Web developers: No signals

Ergonomics

CORB might benefit from a future extension that allows applying similar response blocking to more cases, such as From-Origin.  Otherwise the 4 proposed changes shouldn't impact the ergonomics of other APIs, other than making response processing more strict and providing incentives for web developers to use more accurate MIME types.

The 4 proposed changes should have low risk to performance.  The main impact is that CORB sometimes needs to sniff a response, buffering until an allow/block decision can be made.  This can potentially increase the latency for receiving the first bytes in the renderer, but in practice this should have low impact and happen rarely:

• Sniffing usually makes a decision within the first ~100 bytes.

• Sniffing is only applied to a subset of content types.

• Sniffing is not necessary when the X-Content-Type-Options: nosniff header is present.

• Some sniffing is already done without CORB (by MimeSniffingResourceHandler).

Activation

Developers don’t need to take any extra steps to activate CORB or the observable changes to response behavior, but they can increase the chance their sensitive data is protected by using correct MIME types and "nosniff" headers (or possibly in the future, using From-Origin).  Polyfills and/or JavaScript libraries are not applicable to CORB.  Recommendations for web developers for CORB are available at https://www.chromium.org/Home/chromium-security/site-isolation#TOC-Recommendations-for-Web-Developers, and an audit feature is planned in https://crbug.com/806070.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes, the 4 observable changes of CORB will apply to all platforms, and we intend to enable CORB by default on all six Blink Platforms.  Note that CORB has additional benefits when Site Isolation is enabled, which is currently on track for Windows, Mac, Linux, and Chrome OS.  Experimental support for Site Isolation is available on Android but not yet Android WebView.

Demo link

To test CORB one can turn on the feature by launching Chrome with the --enable-features=CrossSiteDocumentBlockingAlways command line flag.

CORB demo page: https://anforowicz.github.io/xsdb-demo/index.html

Debuggability

Resources blocked by CORB trigger a console message similar to:

Blocked current origin from receiving cross-site document at https://www.chromium.org/ with MIME type text/html.

We are also tracking the plan to add an “audit” feature in the future: https://crbug.com/806070.

Is this feature fully tested by web-platform-tests?

Web-observable aspects of CORB are covered by tests under wpt/fetch/corb.

CORB should not be observable by web features in most cases, which makes it difficult to cover some aspects of CORB with WPT (e.g. see the “Correctly-labeled HTML document” example in the “Observable CORB impact on images” section of the explainer).

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5629709824032768

Requesting approval to ship?

Yes.

On Thu, Apr 12, 2018 at 8:06 AM Daniel Bratell <bra...@opera.com> wrote:

I think it's border line whether this is even a web facing change. If my quick read didn't overlook anything, the goal is to have no observable effects and the implementation seems to be close to that.

The only example of an observable effect is an image served with content type text/html (or some other non-image type) along with the nosniff header telling the browser to basically trust the content type? That it is renderered as an image today seems almost accidental.

You mention that the upper limit of affected requests is 0.1% of the CORB enabled requests (with zero known actual cases), but what percentage is that of the total number of requests?

That includes all subresource requests, excluding navigations and downloads, as noted here.  I don't have a measurement handy for what percentage of total requests they are, though.

Charlie

[Jochen Eisinger]

lgtm1

[Daniel Bratell]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuicvarcgyU___yaSn9RGkvrx_br%3DFkHt1tSV01FLZrO9Zw%40mail.gmail.com.

[Chris Harrelson]

LGTM3

Thanks for the great and clear description of impact. (Please also update the chromestatus.com entry to match.)

[Charlie Reis]

Thanks!

On Tue, Apr 24, 2018 at 4:32 PM Chris Harrelson <chri...@chromium.org> wrote:

LGTM3

Thanks for the great and clear description of impact. (Please also update the chromestatus.com entry to match.)

chromestatus.com seems to have some pretty tight character limits, so I wasn't able to fit the list of 4 observable changes into the entry directly.  That said, I updated it to point to the specific part of this thread outlining those changes.

https://www.chromestatus.com/feature/5629709824032768

Hope that helps!

Charlie

[Charlie Reis]

As a quick update, CORB has been enabled by default on M68 since r553830 on April 25.  That said, we're aiming to enable Site Isolation (including CORB) on desktop in M67 if all goes well.

Thanks,

Charlie

[bethsh...@gmail.com]

Hello!  I'm building a site using Mobirise, and its hosted on pythonanywhere.com because I'll need to integrate my app.  My first webpage works fine with MS Edge but I keep getting errors with Chrome.  See the screenshot above.  I'm not a good enough programmer to code malicious stuff into a web page and I can't see how my site would be a security risk.  The error message reads like gobbledegook to me (or googledegook even).  Can you tell me in plain english how to get my site working in Chrome?  Thank you. 

[PhistucK]

You need to make sure your server responds with the correct Content-Type HTTP response header and value. Since it is serving CSS, the value must be text/css.

Basically, the HTTP response headers of those CSS URLs must include (a single) Content-Type: text/css (or Content-Type: text/css; charset=utf-8 and the like).

If this is still gibberish to you, search the web for more information about HTTP response headers and the name of the server product you are using as this is not the right place for support.

Please, use stackoverflow.com for this kind of questions in the future.

☆PhistucK

On Mon, Sep 10, 2018 at 1:09 AM <bethsh...@gmail.com> wrote:

Hello!  I'm building a site using Mobirise, and its hosted on pythonanywhere.com because I'll need to integrate my app.  My first webpage works fine with MS Edge but I keep getting errors with Chrome.  See the screenshot above.  I'm not a good enough programmer to code malicious stuff into a web page and I can't see how my site would be a security risk.  The error message reads like gobbledegook to me (or googledegook even).  Can you tell me in plain english how to get my site working in Chrome?  Thank you. 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f380fb74-fe1d-4895-9b63-a545ac64bdda%40chromium.org.

[Łukasz Anforowicz]

It appears that you are serving CSS resources (e.g. .../assets/bootstrap/css/bootstrap-reboot.min.css) with an incorrect MIME type (i.e. text/html as shown in the error messages).  Please ensure that you use the correct MIME type (i.e. "text/css" for CSS resources).

Note that a part of Fetch spec talks about blocking CSS responses with an incorrect MIME type ("If destination is "style" and mimeType (ignoring parameters) is not `text/css`, then return blocked").  Such blocking is expected even without Cross-Origin Read Blocking and I guess would have happened in other non-Chrome browsers like Firefox or Edge.

[Anne van Kesteren]

On Mon, Sep 10, 2018 at 6:47 PM Łukasz Anforowicz <luk...@chromium.org> wrote:
> Note that a part of Fetch spec talks about blocking CSS responses with an incorrect MIME type ("If destination is "style" and mimeType (ignoring parameters) is not `text/css`, then return blocked"). Such blocking is expected even without Cross-Origin Read Blocking and I guess would have happened in other non-Chrome browsers like Firefox or Edge.

That's only if you use the nosniff header. Otherwise the HTML Standard
ends up requiring it, but it doesn't require it for same-origin
resources in quirks mode. CORB might end up being stricter in that
case, but I'm not sure if that's applicable here as there isn't
sufficient context.


--
https://annevankesteren.nl/