Reining in the Web with Content Security Policy

Sid Stamm Brandon Sterne Gervase Markham Mozilla Mozilla Mozilla [email protected] [email protected] [email protected]

ABSTRACT exploiting browser or site-specific vulnerabilities to steal or The last three years have seen a dramatic increase in both inject information. awareness and exploitation of Web Application Vulnerabili- Additionally, browser and web application providers are ties. 2008 and 2009 saw dozens of high-profile attacks against having a hard time deciding what exactly should be a “do- websites using Cross Site Scripting (XSS) and Cross Site Re- main” or “origin” when referring to web traffic. With the ad- quest Forgery (CSRF) for the purposes of information steal- vent of DNS rebinding [8] and with the gray area regarding ing, website defacement, malware planting, clickjacking, etc. ownership of sibling sub-domains (like user1.webhost.com While an ideal solution may be to develop web applications versus user2.webhost.com), it may be ideal to allow the free from any exploitable vulnerabilities, real world security service providers who write web applications the opportu- is usually provided in layers. nity to specify, or fence-in, what they consider to be their We present content restrictions, and a content restrictions domain. enforcement scheme called Content Security Policy (CSP), 1.1 Uncontrolled Web Platform which intends to be one such layer. Content restrictions al- Web sites currently execute in a mostly uncontrolled web low site designers or server administrators to specify how browser environment. The sole protection currently afforded content interacts on their web sites—a security mechanism to websites with regards to policies restricting content is desperately needed by the untamed Web. These content the same–origin policy (SOP) [20]. Although this policy is restrictions rules are activated and enforced by supporting deployed in browsers, attackers are still able to subvert the web browsers when a policy is provided for a site via HTTP, policy by directly attacking the site and injecting their own and we show how a system such as CSP can be effective to script into the content. For example, an attacker may post a lock down sites and provide an early alert system for vulner- message to messageboard.com that is rendered for all future abilities on a web site. Our scheme is also easily deployed, visitors to the site. In his message, he includes some HTML which is made evident by our prototype implementation in that loads a script from evil.com, his website. Suddenly Firefox and on the Mozilla Add-Ons web site. all visitors to the message board site are running arbitrary evil.com code within the messageboard.com domain. Categories and Subject Descriptors More generally, the attacker could also insert references H.4.3 [Communications Applications]: Information to arbitrary images or style sheets to alter the appearance Browsers; H.3.5 [Online Information Services]: Web- of the web site; though this is often considered as a less based Services; D.4.6 [Security and Protection]: Infor- significant attack, it is yet more evidence that a vulnerability mation Flow Controls in a web site can lead to significant changes to its appearance or operation. General Terms This lack of control is exemplified by iframe injections used to poison search engine rankings of some popular sites [5]. Design, Security In this attack, some popular sites’ validation input is cir- cumvented to inject an iframe onto a site’s search results Keywords page. After the injection, all browsers that render the page inadvertently load an iframe that points to data served by content restrictions, web security, security policy, http the attacker. That page then attacks the visitor’s browser through a browser vulnerability like codec installation, Ac- 1. INTRODUCTION tiveX objects or other drive-by downloading techniques, and In the shadow of all the problems stemming from web search engines reduce the ranking of these victim sites since mash-ups and content injection attacks on the web, it seems they may be classified as malware. This problem exploited attractive to tighten control on the domains. Web “hack- by the attackers has two parts: (1) the web application does ers” are often able to use Cross–Site Request Forgeries [14] not properly validate input and (2) after the data is injected, or Cross–Site Scripting [2] to move data between domains, a visit to victimsite.com causes a browser to load the at- tack page on evilsite.com. We argue that although the Copyright is held by the International World Wide Web Conference Com- mittee (IW3C2). Distribution of these papers is limited to classroom use, input validation is important, it is never perfect; the vic- and personal use by others. tim site should be able to specify which sites are trusted WWW 2010, April 26–30, 2010, Raleigh, North Carolina, USA. and then rely on the visitors’ browsers to forbid loading re- ACM 978-1-60558-799-8/10/04. sources from untrusted sites like evilsite.com, reducing the loading rules for their web site that will be enforced by the abilities an attacker gains through a successful XSS hack. browser. When enforced, these rules limit what types of con- A way for a web site designer to dictate the behavior of tent may be requested for inclusion on the site, as well as the site is needed, and with assistance from web browsers, where the content may be loaded from. We show how CSP such a feature should limit the site’s behavior to what is can be employed as a mechanism to help discover and thwart expected. Any other content loads, requests, or abnormal cross-site scripting (XSS), data leak attacks, and other types behavior should be blocked as deviation from what is ex- of currently unknown attacks that lead to an unpredictable pected. Such a content restrictions feature would give web web site experience. authors more control over data on their site—even as third Even if the web developers lose control over the page’s party content is used. We argue that content restrictions content, such as in the case of cross-site scripting and SQL- should be used to control sites and propose an implemen- injection attacks, the attacker will have limited ability to tation of content restrictions called Content Security Policy affect the site’s behavior since he will be unable to (1) im- (CSP), that does exactly this. port third party content onto the site and (2) make requests to third party URIs to extract content from the site. Our Cross-Site Scripting Attacks. In 2008 and 2009, cross-site solution is implemented in the HTTP protocol—outside the scripting (XSS) attacks have remained the most wide-spread scope of any code running in a browser document—so that and frequently occuring vulnerability on web sites [6]. While the security controls can be erected outside of the sandbox it may not be clear why XSS is so common, this evidence is where web content is rendered. an incentive to find a new way to block XSS. While many We also contribute a proof-of-concept implementation that vendors and framework providers have helped with XSS fil- provides a prototype implementation of our scheme on both ters, attackers regularly find new ways to inject and run a complex web site and in a popular web browser, showing script on a victim page. Perhaps it is time to approach that it is practical. We also compare our solution to others in the problem from a different angle: instead of only filtering the field and show how ours provides an early-warning sys- scripts from being inserted into a page, we can also disable tem not present in others, does not create a large amount invading scripts as they attempt to run. of network overhead, and cannot be used to reduce the se- curity of a web site. Finally, we show our scheme is gradu- Data Leak Attacks. Currently, web sites are at liberty to ally deployable — it does not rely on complete adoption to embed content from wherever else they wish. For example, work, and can be rolled out gradually onto web servers and mysite.com/index.html can embed images from mysite. browsers, increasing the general security of the web as it is com, or it may contain references to images anywhere else on deployed. the Internet like webcounter.com/images/count.cgi. The 1.2.1 Goals of our Scheme effects of this embedding policy are twofold: data is loaded from a third party site, and (less obviously) information is Our proposed scheme is intended to provide a site’s ad- transmitted to that third party site in the form of the HTTP ministrators control over behavior and appearance of their request. Not always is it the case that an adversary wants to site S with a rule set that dictates what may load onto the embed malicious code on a site—it may be success enough site and into what contexts (image, script, etc). Addition- for them to simply see HTTP requests. ally, our scheme will help protect visitors of a web site S Modern web browsers don’t strongly enforce any rules on such that the information they provide the site will only be what can be embedded or referenced by a web site, opening transmitted to S or other hosts authorized by S, preventing up many vulnerabilities, especially considering the mash-up aforementioned data leak attacks. This policy will hold even culture of Web 2.0. As a result, web applications may be if S is attacked by a web-based adversary who attacks the leaking data back to one of the contributors, or an un-trusted site through a web browser using some sort of data injection third party. In the case of websites that have been compro- technique to perform cross-site scripting or inject additional mised by content injection or those that contain cross-site- code onto the site. Additionally, only scripts served from request forgeries generated by site contributors, the data whitelisted origins will execute, minimizing the chance of leaked to a contributor could be as mild as IP addresses of XSS attacks on a site. Finally, our scheme will allow a site all site visitors, or as severe as passwords or bank account to specify in which frames it may be rendered; allowing a numbers for all visitors. We call these types of attack data site to specify what other sites may enframe it minimizes leak attacks. potential for clickjacking. Since there are many beneficial uses for the ability to em- Control Over Content Used on a Site: If our scheme is bed off-site resources (web counters, traffic analyzers, adver- implemented correctly, an adversary who is able to tisements), it is not in the best interest of anyone to outright augment the website with arbitrary JavaScript, HTML reject this behavior. There are, however, some cases with or CSS code will only be limited to the text he is able scripts where there is enough potential for malicious code or to inject: not only will he be unable to load third- sensitive data leak that web browsers should block certain party resources on the site, he also will not be able to requests, such as in the case of the iframe injection attack. transmit data to hosts not authorized by S. 1.2 Contribution Increased Security against XSS Attacks: A site employ- We propose content restrictions be employed on websites— ing our scheme and containing reflected or persistent restrictions that give web application authors control over XSS vulnerabilities will be protected when it is ren- the content embedded on their site. We also propose an im- dered in a browser that also supports our scheme. The plementation of this called Content Security Policy (CSP); script injected by an attacker will not execute, and the CSP will enable application developers to lay out content site owner will be warned of the vulnerability. Clickjacking Avoidance: When our scheme is implemented Base Restriction 1: No Inline Scripts Will Execute. XSS correctly, an adversary who embeds a protected site S attacks are possible because the browser has no way to dif- into his will not be able to invisibly overlay the pro- ferentiate between content the server intended to send and tected content of S in order to “force clicks” that a user content injected by an attacker. Content Security Policy intends for the attacker’s site to pass through invisi- forces the separation of code from content and requires au- bly to S. In essence, a site protected by CSP cannot thors to be explicit about the code they intend to execute by be used as an unintended target for clicks stolen and placing such code in externally referenced files. The result redirected by an attacker. of disabling inline scripts renders any script injected into a document inoperable. Specifically, features disabled by this Only Tightened Security: Additionally, our scheme will restriction are: not introduce new ways for an adversary to glean in- • Text content of