Poster: UserCSP- User Specified Content Security Policies Kailas Patil Tanvi Vyas Frederik Braun National University of Mozilla Corporation Mozilla Corporation Singapore [email protected] [email protected] [email protected] Mark Goodwin Zhenkai Liang Mozilla Corporation National University of [email protected] Singapore [email protected] ABSTRACT developers. UserCSP, on the other hand, is an open-source project Content Security Policy (CSP) is a browser security mechanism available for download on the Mozilla Add-on gallery [4] as well that aims to protect websites from content injection attacks. To as on GitHub [5]. adopt CSP, website developers need to manually compile a list of The goals of UserCSP are two-fold: i) to allow security savvy allowed content sources. Nearly all websites require modifications users to specify their own CSP policies, and ii) to allow developers to comply with CSP’s default behavior, which blocks inline scripts to experiment with CSP policies on their production pages. More- and the use of the eval() function. Alternatively, websites could over, UserCSP assists users and developers in constructing com- adopt a policy that allows the use of this unsafe functionality, but prehensive CSP policies by providing them automatically inferred this opens up potential attack vectors. When websites do not im- Content Security Policies that they can use as a starting point for plement CSP, security savvy users do not have the control to proac- experimenting with CSP on a website. tively protect themselves. To make adoption of CSP easier, we In summary, this paper makes the following contributions: propose UserCSP, a Firefox extension that uses dynamic analysis • We design and prototype UserCSP to automatically generate to automatically infer CSP policies, facilitates testing, and gives Content Security Policies and then we evaluate compatibility savvy users the authority to enforce client-side policies on web- of the inferred security policies on websites. sites. • We propose an approach for applying security policies on the 1. INTRODUCTION client-side. Our approach allows savvy users to specify their The root cause of code injection problem on websites is that own custom Content Security Policies. browsers are unable to distinguish between legitimate and mali- ciously injected content in a web application. Content Security Our experiments show a lack of Content Security Policy imple- Policy (CSP) [1] aims to solve this problem by providing a declar- mentations and the necessity for a tool like UserCSP to help pro- ative content restriction policy in an HTTP header that the browser mote adoption. UserCSP provides developers with an easy mech- can enforce. CSP defines directives associated with various types of anism to create an effective, comprehensive, and strict Content Se- content that allow developers to create whitelists of content sources curity Policy that secures their users and does not break website and instruct client browsers to only load, execute, or render con- functionality. tent from those trusted sources. However, writing an effective and comprehensive CSP policy for websites is laborious. A policy can 2. UserCSP DESIGN break website functionality if legitimate content is overlooked dur- UserCSP helps developers and users write comprehensive poli- ing policy generation. Web developers at large technology compa- cies for websites by providing them with a GUI to add and mod- nies may not have direct access to change the CSP header on web ify CSP policies. UserCSP monitors the browser’s internal events servers, making it difficult to iterate over policies. (including HTML parsing, HTTP requests, and XHR requests trig- Developers are primarily focused on user experience and provid- gered by scripts running in the JS engine). It then dynamically ing rich functionality to end users. The reluctance of developers to analyzes the content type loaded by a webpage and the source of adopt CSP, as seen in our experiments, shows that they are unwill- that content. This information is useful to automatically infer the ing to sacrifice functionality for security because they are worried policy for a webpage. about losing customers. However, security savvy users may prefer When users visit a website, UserCSP performs one of the fol- security over rich functionality. Since browsers do not currently ex- lowing actions: pose a policy enforcement mechanism directly to users, users lack • If the website has defined a CSP policy, but the user hasn’t, control over their own security when websites do not implement then UserCSP does not interfere with the website defined CSP. If developers and users do not experiment with CSP, it is dif- policy. However, it does allow the user the option to amend ficult for the community to iterate on the CSP specification [2] to the website’s policy. come to a more usable solution. • If a user has specified a CSP policy for a website, but the To assist website administrators in constructing Content Security website administrator hasn’t, then the user’s policy is en- Policies, CSP AiDer [3] uses crawler to crawl all the pages asso- forced. ciated with a website and recommends a CSP policy based on the types of content found and the sources of that content. However, • If both a user specified CSP policy and a website defined pol- CSP AiDer is not open-source and hence not available to most web icy exist, then the user has a choice to either apply their own 1 policy or adopt the website defined policy. Moreover, users Our tests show that none of the Alexa Top 100 websites have can choose to combine their custom policy with an exist- implemented CSP. A recent study revealed that only 79 out of the ing website policy by selecting a strict (intersection) or loose Alexa Top 1,000,000 websites implement CSP, showing that CSP (union) combination policy. has a very low adoption rate [6]. After applying UserCSP’s inferred policies, all the Alexa Top • If neither the user nor the website specify a CSP policy, but 100 websites generated CSP violation reports that showed viola- the user has specified a global policy that can be used for tions for the inline script default restriction. In addition, 11 web- websites that do not have site-specific policies defined, then sites generated CSP violation reports for using eval()3. This exper- UserCSP will apply the global policy. imental survey implies that websites commonly use inline scripts. • If neither the user nor the website specify a CSP policy, and To further test this theory, we scanned the Alexa Top 25,000 there is no global policy, then UserCSP does not affect the websites using the Scrapy framework [7]. Of the 23,195 acces- content loading on the website. sible websites, 22,324 (96.2%) were using inline scripts or inline event handlers. To allow automatic policy inference for websites, UserCSP uses 4. CONCLUSION dynamic analysis to monitor content loaded by a webpage and rec- ommends a CSP policy based on the content types and content Content Security Policy has not been widely adopted because of sources included in the webpage. It also monitors the resources the challenges involved in creating a comprehensive and functional dynamically added to the webpage by JavaScript. policy. Since adoption is controlled by developers, users lack con- trol over their own security. Users do not have a mechanism to 3. ANALYSIS & RESULTS apply Content Security Policies on the websites that they visit and We tested UserCSP’s user defined CSP feature and automatically cannot protect themselves from Cross-Site Scripting and Clickjack- infer CSP feature with the Alexa Top 100 websites1. Manually de- ing attacks. fined CSP policies are harder to evaluate since they require several UserCSP helps break down the challenges involved in adopt- rounds of refinement and HTML source code inspection to record ing Content Security Policy with its feature to automatically in- content sources. We initially seeded the policies with same-origin fer policies. It also puts control into the users hands by providing restrictions and then expanded them since many websites require them a mechanism to protect themselves with custom policies that content from CDN’s and sub-domains. they can create and modify. Our analysis and results show that an- To test compatibility of the automatically infer CSP feature of other barrier to Content Security Policy adoption is the use of inline UserCSP, the extension inferred policies for each of the Alexa Top JavaScript. To overcome this, we would like to experiment further 100 websites and then applied the policies onto their respective with the proposed script-nonce and script-hash directives that are website home pages (Figure 1 includes an example of automati- under discussion for inclusion in the CSP 1.1 specification [8]. cally inferred policy). Reports were created for each website and Acknowledgments examined for CSP violations2. We thank Sid Stamm for his help on the implementation of UserCSP. default-src ’self’; We thank the anonymous reviewers for their valuable comments. script-src http://ads1.msads.net http://kaw.stj.s-msn.com; 5. REFERENCES img-src http://udc.msn.com http://kaw.stb.s-msn.com [1] Sid Stamm, Brandon Sterne, and Gervase Markham. Reining http://b.scorecardresearch.com in the web with content security policy. In Proceedings of the http://c.in.msn.com 19th International Conference on World Wide Web, 2010. http://www.bing.com [2] W3C Candidate Recommendation. Content security policy http://kaw.stb01.s-msn.com 1.0. http://www.w3.org/TR/CSP/. http://kaw.stc.s-msn.com http://kaw.stb00.s-msn.com; [3] Ashar Javed. Csp aider: An automated recommendation of style-src http://kaw.stc.s-msn.com; content security policy for web applications. In IEEE Oakland frame-ancestors *; Web 2.0 Security and Privacy (W2SP 2012), 2012.