Blocking Cross-Site Documents for Site Isolation
NOTE: This page represents earlier work that led to the current Cross-Origin Read Blocking (CORB) policy. Also see the CORB explainer and the relevant part of the Fetch spec.
In general, Chrome's renderer processes should not be given access to data they don't need. Our Site Isolation project is trying to make it possible to limit a renderer process to pages from only a single site. As part of this, Chrome needs to block such a process from receiving network responses that the site isn't allowed to use.
A web site is allowed to request documents from its own site (or those that have been made available using CORS), as well as resources from any site.
However, we can't always rely solely on the MIME type of the HTTP response to distinguish documents from resources, since the MIME type on network responses is frequently wrong. Content sniffing can help to confirm whether a document is what it claims to be, but using typical content sniffers would lead to overzealous blocking and create compatibility problems. Fortunately, our experiments show that we can enforce a policy that blocks most cross-site documents without breaking existing sites, using a combination of MIME type and custom content sniffers.
Our proposed cross-site document blocking policy prevents a renderer process from receiving cross-site documents that (1) have a HTML, XML, or JSON MIME type, and (2) are confirmed to be that type by a custom content sniffer (or are marked NoSniff). It does not currently protect files that have other MIME types. Documents that are blocked appear as empty to the process that requested them.
While implementing versions of this policy, we made several observations about how the content sniffing logic must behave:
- For HTML and XML, we cannot block "<?xml" unless we can confirm it isn't an SVG. Cross-site SVG files are permitted.
To preserve compatibility, we are aiming to avoid disrupting the behavior of existing web sites when blocking responses, within reasonable limits. We consider certain behavior changes acceptable, though. For example, we prevent actual HTML, XML, or JSON files from being parsed as CSS. CSS parsers were originally very lenient and could discover "rules" from almost any content, which was used by security researchers for attacks . CSS now requires a valid MIME type, though, so it should be unaffected by the proposed blocking behavior.
When measuring the potential impact of the policy, we discovered several "non-disruptive" cases in which cross-site documents were blocked but that cause no behavior change to the page. These include:
- Responses with error status codes in any context except images. (Images continue to render regardless of status code, and this is sometimes used in practice for 404 images.)
We consider it harmless to block such network responses.
We only plan to enforce the policy on web renderer processes. Extension processes in Chrome are allowed to request more documents (based on the host permissions in the extension's manifest), and we could later enforce a similar policy that accounts for their permissions. Plugin processes currently have an exception as well since their requests currently go through the renderer process, but this will be changed in https://crbug.com/778711.
Unfortunately, we do have to give up some security properties when extensions with content scripts are installed. Such extensions can request permission in their manifest to make XmlHttpRequests to other sites from within the renderer process. We cannot block such documents from the renderer process, which would allow an exploited renderer to also access such documents. We are investigating how to update the content script security model to make this less of a concern in practice.
To measure compatibility, we ran an experiment that collected user metrics on how many network responses would be blocked using our policy. Our experiment followed the policy described above, with two caveats. First, it incorrectly blocks cross-site SVG files. Second, it incorrectly blocks cross-site requests made by extension content scripts. Using one week of data collected from Chrome Beta users (using Chrome's opt-in UMA system), we found that 0.16% of network responses were blocked overall, but more than half of these we could prove to be non-disruptive (e.g., error status code). Only 0.075% of network responses were potentially disruptive.
We intend to refine our experiment to avoid blocking content scripts and SVG files. Based on the data we collected, we found that content scripts could account for up to 0.009% of responses. Accounting for SVG files could let us conclude that up to another 0.063% of responses were not disruptive. This suggests that our updated policy could be disruptive for as few as 0.003% of network responses.
Using these results, we have started to deploy the policy to users who have Site Isolation enabled in Chrome 63. In combination with our other Site Isolation work, this can help protect confidential documents from leaking to other sites.
The current document blocking policy protects HTTP responses for URLs labeled with one of these MIME types in the "Content-Type" HTTP response header:
The HTTP response should also have a "X-Content-Type-Options: nosniff" HTTP response header, which ensures that the protection will not depend on what the contents of the file look like.
Note that we recommend not supporting multipart range requests for sensitive documents, because this changes the MIME type to multipart/byteranges and makes it harder for Chrome to protect.
 Huang, Lin-Shung, et al. "Protecting browsers from cross-origin CSS attacks." Proceedings of the 17th ACM conference on Computer and communications security. ACM, 2010.