CHROME-2012-0001

Content Security Policy headers are ignored in certain circumstances.

n/a

This vulnerability concerns the failure to enforce Content Security Policy headers; no special access is required to exploit this.

variable

Only web sites with a particular design can be targeted; once such a site is identified, it may be attacked as though the Content Security Policy functionality were not in place.

variable

Content Security Policy headers are intended to allow web site administrators to protect visitors using modern browsers from various cross-site attacks; this vulnerability, however, means that such protections are not in place in all cases, making users vulnerable to poor coding practices of the site designer. What bad behavior this allows will necessarily vary from site to site.

The original design of the web included no client-side controls over the inclusion of third-party content in a page. The need for such controls has been shown, however, by a variety of content injection attacks: for example, an attacker might craft a malicious link that, thanks to a lack in sufficient sanitation on either the client or server side, inserts new JavaScript into a page.

Content Security Policy (CSP) headers - currently X-WebKit-CSP for browsers based on webkit and X-Content-Security-Policy for Mozilla-based browsers, but soon to be standardized as Content-Security-Policy - are meant to prevent many of these attacks by specifying exactly where different sorts of remote content may come from. For example, if a CSP-aware WebKit-based browser sees the header

    X-WebKit-CSP: default-src 'none'; img-src imgs.example.com;
                  script-src scripts.example.com
  

while loading a page, it will load no external resources except images from imgs.example.com and scripts from scripts.example.com. Videos, off-site images, or scripts uploaded by users to imgs.example.com will all be ignored by the browser.

Of course, for CSP to truly protext against cross-site scripting attacks, it must also disallow inline scripts. By default every Content Security Policy header also forbids scripts literal scripts from appearing within a page and prohibit JavaScript's eval and related functionality that allows arbitrary strings to be interpreted as JavaScript code.

Meanwhile, HTML5 Web Workers were introduced to address another deficiency of the web: while much JavaScript functionality is asynchronous, there was until now no mechanism for true parallelism within a page. The Web Worker design is fairly straightforward, allowing workers to be created by

    var worker = new Worker('script_file.js');
  

Communication between a worker and the main page is then done by message passing. The worker cannot directly interact with the DOM and thus cannot observe or alter the structure of the page. Workers do retain access to some web functionality, including XMLHttpRequest, which allows them to communicate with other servers.

Much of CSP does not concern Web Workers, as without access to the DOM they are unable to load any images, Adobe Flash objects, or subframes. Workers may, however, use eval and similar functionality, and the current W3C working draft on CSP specifies that any policy applying to the parent page of a worker should also be in effect within the worker.

Unfortunately, this is not the case in Chrome. Because of this, a script injection attack that relies on eval will still affect Chrome users, even if the site serving the page in question uses CSP, as long as the point of attack happens within a Web Worker.

lack of checks

The code for JavaScript within Web Workers seems to have been written before Content Security Policy support was added and to not have been updated subsequently. Compare, for example, SetTimeoutOrInterval in V8WorkerContextCustom.cpp, which is unaware of CSP, to WindowSetTimeoutImpl in V8DomWindowCustom.cpp, which correctly prevents eval-like behavior in setTimeout and setInterval outside of Web Workers.

Add the same CSP checks that are present when executing code in a traditional DOM window for code executed in a Web Worker.

Since Web Worker code is always downloaded as a separate JavaScript file, it is unclear exactly how to proceed if CSP headers accompany this file and differ from those that accompanied the parent page. The CSP spec requires only that the headers of the parent page be obeyed and does not discuss headers served with the worker JavaScript file itself; an argument might be made for, e.g., allowing policies to be strengthened (but not weakened) by headers accompanying JavaScript files.

This research funded in part by Department of Homeland Security grant FA8750-10-2-0030 (funded through AFRL) and NATO grant ICS.MD.CLG 984138.