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.
--
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.
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.
Intent to Implement and Ship: Web Platform Changes for CORB
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.)
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.
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?
--
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.
LGTM3Thanks for the great and clear description of impact. (Please also update the chromestatus.com entry to match.)
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.