2016 IEEE Cybersecurity Development Enforcing Content Security by Default within Web Browsers Christoph Kerschbaumer Mozilla Corporation [email protected] Abstract—Web browsers were initially designed to retrieve side redirect to prevent a malicious page from circumventing resources on the world wide web in a static manner such that the initial security checks by performing a redirect. adding security checks in select locations throughout the codebase Instead of continuing current practice where developers sufficiently provided the necessary security guarantees of the web. have to opt-in to security checks whenever implementing a Even though systematic security checks were always performed, those security checks were sprinkled throughout the codebase. new standard for loading resources, we present an approach Over time, various specifications for dynamically loading content where content security is applied by default. Adding a central have proven that such a scattered security model is error-prone. API that relies on an opt-out mechanism provides the needed Instead of opting into security checks wherever resource loads infrastructure to prevent less security minded engineers from are initiated throughout the codebase, we present an approach accidentally introducing vulnerabilities. where security checks are performed by default. By equipping every resource load with a loading context (which includes We first provide background on the different content secu- information about who initiated the load, the load type, etc.), rity checks a browser performs before loading a URI (Sec- our approach enforces an opt-out security mechanism performing tion II) and contribute the following: security checks by default by consulting a centralized security manager. In addition, the added load context allows to provide We survey content security mechanisms before instan- • the same security guarantees for resource loads which encounter tiating a load request and after a server-side redirect, a server-side redirect. and provide the ratio of redirected URIs on the web (Section III). I. MOTIVATION We examine how Firefox has performed content security • Web browsers have become complex software applications checks historically (Section IV) and present design and that need to be capable of providing security guarantees when implementation details for enforcing content security by loading URIs from the web. For example, a browser needs to default within Firefox (v.50.0) (Section V). We provide an assessment of the engineering needed ensure that a web page can not access local resources on a • user’s computer. While web browsers were initially designed to retroactively provide an API for enforcing content for retrieving and displaying information resources on the security by default within a browser (Section VI). world wide web in static HTML, modern web browsers need to support the latest and constantly evolving web standards II. CONTENT SECURITY BACKGROUND capable of loading resources, like e.g. the fetch specifica- As of today, all major web browsers (Chrome, Edge, Fire- tion [WHATWG, 2015]. fox, Internet Explorer, Opera, Safari) are committed to imple- Before loading a URI, web browsers have to perform nu- ment most (if not all) of the security specifications defined by merous content security checks, such as evaluating that a script the World Wide Web Consortium (W3C) to improve security does not violate the same origin policy (SOP) [W3C, 2010b], in web browsers. The most important of those specifications or ensuring that the requested URI complies with the page’s are: Content Security Policy [W3C, 2014a]. At first, performing security checks in selective locations (SOP) [W3C, 2010b] The same • Same Origin Policy throughout the codebase sufficed to provide the required origin policy prevents malicious script on one page security. However, the abundance of new web standards for from obtaining access to sensitive data on another retrieving resources on the web caused such sprinkled security web page through that page’s Document Object Model checks to be error-prone. Even though systematic security (DOM) [W3C, 2004]. The SOP defines an origin as a checks are performed, a modern browser requires a central combination of scheme, host and port number. API to provide the same security guarantees for the different More recently, the W3C started discussions specifications capable of loading resources. about standardizing the concept of Subori- To complicate things further, the web evolved over time gins [Joel Weinberger, Devdatta Akhawe, 2016]. such that almost 12% of resource loads result in a server-side Suborigins define a mechanism for programmatically redirect (see Table I). To ensure the required security, browsers defining origins to isolate different applications running have to enforce the same security checks again after a server- in the same physical origin. User agents can extend the © 2016, Christoph Kerschbaumer. Under license to IEEE. 10183 DOI 10.1109/SecDev.2016.8 same-origin policy with this new namespace plus an In addition to these specifications major browsers also im- origin tuple to create a security boundary between this plement security standards defined by the Internet Engineering resource and resources in other namespaces. Task Force (IETF): (CORS) [W3C, 2010a] • Cross Origin Resource Sharing HTTP Strict Transport Security (HSTS) [IETF, 2012] To relax the same origin policy, the W3C specified CORS, HSTS protects against protocol downgrade attacks by provid- which creates a whitelist of trusted domains by extending ing a mechanism for web servers to declare that web browsers HTTP with a new origin request header. Hence CORS should only interact with it using secure HTTPS connections provides a mechanism which allows restricted resources and never allow connecting via the insecure HTTP protocol. (e.g., fonts) on a web page to be requested from a domain [Mike West, Richard Barnes, 2016] HSTS outside of the originating domain. HSTS Priming priming proposes modifications to the behavior of HSTS to [W3C, 2014b] The Mixed • Mixed Content Blocking mitigate the risk that mixed content blocking will prevent Content Blocker blocks insecure content on web pages migration from HTTP to HTTPS. Before blocking a third that are supposed to be secure. HTTP [W3C, 2016] itself party subresource as mixed content, HSTS priming would is not secure, which means connections are open for perform an anonymous ’preflight’ request to the subresource eavesdropping and man-in-the-middle attacks. If the main in question to check if the subresource is marked HSTS. If the page is served over HTTPS but includes HTTP content, subresource isn’t available over HSTS it would be blocked by then the HTTP portion can be read and modified by the mixed content blocker attackers, even though the main page is served over HTTPS. When an HTTPS page has HTTP content, then Ultimately, browsers need to enforce Access Permis- the mixed content blocker can block such ’mixed’ con- sion Checks to guarantee a webpage can not access lo- tent. cal files. For example, a browser needs to block requests trying to load an image from the local file system, e.g. (SRI) [W3C, 2014c] SRI pro- • Subresource Integrity file://home/secdev/conf.png. vides a mechanism for website authors to provide a cryp- tographic hash to a resource in addition to the location of III. PERFORMING CONTENT SECURITY CHECKS the resource. Web browsers compare the hash provided Whenever a browser fetches a resource from the web, the by the website author with the computed hash from the browser has to perform all, or at least a subset of the security fetched resource and load the resource only if the hashes checks described in Section II. match. (CSP) [W3C, 2014a] The Con- • Content Security Policy Content Security Policy: script-src good.com tent Security Policy allows web authors to define a whitelist in a HTTP header (or HTML meta element) GET good.com/library.js to specify trusted sources for delivering content. For ex- good.com ample, a CSP of script-src https://good.com permits the user agent to load script only when it is response (redirect) sourced from https://good.com. Three CSP direc- GET evil.com/attack.js tives are particularly important and should be highlighted: evil.com – Upgrade Insecure Requests [W3C, 2015b] The CSP directive upgrade-insecure-requests Security1 Checks instructs user agents to upgrade all insecure HTTP URIs to their secure HTTPS equivalent. The directive Fig. 1: Browser performing Content Security Checks (includ- targets web sites with large numbers of insecure ing checks after redirects). legacy URIs that would otherwise need to be rewrit- ten to secure links. Figure 1 shows a web browser that performs a GET request of the URI good.com/library.js. Before the browser [W3C, 2015a] – Strict Mixed Content Blocking actually initiates the network load, it performs at least an The CSP directive block-all-mixed-content access permission check, or applies (if applicable) the more provides a stricter variant of mixed content checking restrictive same origin policy. Additionally, the browser con- which will block optionally-blockable mixed content strains mixed content and also enforces the page’s Content in addition to blockable mixed content and prevents Security Policy. As illustrated in Figure 1, the web page ships a users from overruling the browsers decision. Content Security Policy of script-src good.com, which – Require SRI for [W3C, 2016] This CSP direc- instructs the browser to only load scripts originating from tive require-sri-for provides a mechanism for good.com. The browser now checks if the host portion of the website authors to load resources only when SRI is resource matches the host defined in the CSP. In the example, defined for the resource load. the host of the URI matches the whitelisted host in the CSP, 10284 hence the browser initiates the GET request for the given Start Resouce Load resource. GECKO The server good.com responds with a server-side URI redirect (e.g., 301 Moved Permanently)indicatingthat Security Checks the URI will be redirected to evil.com/attack.js.