Most Websites Don't Need to Vibrate: a Cost–Benefit Approach To
Total Page：16
File Type：pdf, Size：1020Kb
Most Websites Don’t Need to Vibrate: A Cost–Benefit Approach to Improving Browser Security Peter Snyder Cynthia Taylor Chris Kanich University Of Illinois at Chicago University Of Illinois at Chicago University Of Illinois at Chicago [email protected] [email protected] [email protected] ABSTRACT Firefox OS, have expanded the Web API tremendously. Modern Modern web browsers have accrued an incredibly broad set of browsers have, for example, gained the ability to detect changes features since being invented for hypermedia dissemination in in ambient light levels [58], perform complex audio synthesis [14], 1990. Many of these features benefit users by enabling new types enforce digital rights management systems [25], cause vibrations of web applications. However, some features also bring risk to in enabled devices [36], and create peer to peer networks [11]. users’ privacy and security, whether through implementation error, While the web has picked up new capabilities, the security model unexpected composition, or unintended use. Currently there is underlying the Web API has remained largely unchanged. All web- no general methodology for weighing these costs and benefits. sites have access to nearly all browser capabilities. Unintended in- Restricting access to only the features which are necessary for formation leaks caused by these capabilities have been leveraged by delivering desired functionality on a given website would allow attackers in several ways: for instance, WebGL and Canvas allowed users to enforce the principle of lease privilege on use of the myriad Cao et al. to construct resilient cross-browser fingerprints [21], and APIs present in the modern web browser. Gras et al. were able to defeat ASLR in the browser [30] using the 1 However, security benefits gained by increasing restrictions must Web Workers and High Resolution Timing APIs. One purported be balanced against the risk of breaking existing websites. This benefit of deploying applications via JavaScript in the browser is work addresses this problem with a methodology for weighing that the runtime is sandboxed, so that websites can execute any the costs and benefits of giving websites default access toeach code it likes, even if the user had never visited that site before. The browser feature. We model the benefit as the number of websites above attacks, and many more, have subverted that assumption to that require the feature for some user-visible benefit, and the cost great effect. as the number of CVEs, lines of code, and academic attacks related These attacks notwithstanding, allowing websites to quickly pro- to the functionality. We then apply this methodology to 74 Web vide new experiences is a killer feature that enables rapid delivery API standards implemented in modern browsers. We find that al- of innovative new applications. Even though some sites take ad- lowing websites default access to large parts of the Web API poses vantage of these capabilities to deliver novel applications, a large significant security and privacy risks, with little corresponding portion of the web still provides its primary value through rich me- benefit. dia content dissemination. We show in this work that most websites We also introduce a configurable browser extension that allows can deliver their beneficial functionality to users with only a limited users to selectively restrict access to low-benefit, high-risk features number of JavaScript APIs. Additionally, when websites need ac- on a per site basis. We evaluated our extension with two hardened cess to less common functionality, we demonstrate a mechanism to browser configurations, and found that blocking 15 of the 74stan- enable fine-grained access to JavaScript features on a case-by-case dards avoids 52.0% of code paths related to previous CVEs, and basis. 50.0% of implementation code identified by our metric, without An understanding of the benefits and risks of each JavaScript affecting the functionality of 94.7% of measured websites. feature is necessary to make sound decisions about which features need to be enabled by default to create the modern web experience. KEYWORDS With this knowledge, a set of highly beneficial features can be exposed by default to all websites, while only trusted sites that arXiv:1708.08510v2 [cs.CR] 5 Sep 2017 Network security, Software security, Web security and privacy need additional features are given the ability to access the full set ACM Reference format: of capabilities in the browser, thus enforcing the principle of least Peter Snyder, Cynthia Taylor, and Chris Kanich. 2017. Most Websites Don’t privilege on the Web API. Need to Vibrate: A Cost–Benefit Approach to Improving Browser Secu- This work applies a systematic cost-benefit analysis to the por- rity. In Proceedings of ACM Conference, Washington, DC, USA, July 2017 tions of the Web API implemented in all popular browsers. We (Conference’17), 16 pages. present a method to quantitatively evaluate both the cost of a fea- https://doi.org/10.1145/nnnnnnn.nnnnnnn ture (the added security risk of making a feature available) and the benefit of a feature (the number of websites that require the 1 INTRODUCTION feature to function properly). We then build a browser extension which blocks selected JavaScript functions to generate the results Since its beginnings as a hypermedia dissemination platform, the discussed in this paper. In this work we specifically consider the web has evolved extensively and impressively, becoming part com- munication medium and part software distribution platform. More 1We present a more extensive overview of academic attacks and the JavaScript APIs recently, the move from browser plugins to native HTML5 capa- that enable them in Section 5.2.1, and further enumerate the attack to enabling feature bilities, along with efforts like Chrome OS and the now defunct mapping in Table 4 in the Appendix. open web accessed via a desktop browser, but the same approach number of previously reported CVEs in a feature, on the intuition could be expanded to any website viewed via any browser. that features which are difficult to code correctly are more likely to Using these cost-benefit measurements, we create two hardened have further undiscovered vulnerabilities. browser configurations by identifying high-cost standards that Second, we model security cost as the number of attacks intro- could be blocked in the browser without affecting the browsing duced in academic papers which have been enabled by each Web experience on most websites. We present a browser extension that API standard. enforces these hardened browser configurations, and compare the Third, we model security cost as a function of code complex- usability of these hardened browser configurations against other ity. We attribute entry points in the browser’s C++ codebase to popular browser-security tools, NoScript and the Tor Browser Bun- JavaScript exposed features, and then quantify complexity as the dle (TBB). We find that our hardened browser configurations offer number of lines of code used solely to implement access to each substantial security benefits for users, while breaking fewer web- feature. sites than either NoScript or the default configuration of the TBB during our evaluation on both the 200 most popular sites in the 2 RELATED WORK Alexa 10k, and a random sampling of the rest of the Alexa 10k. Our browser-hardening extension is highly configurable, allow- In this section we discuss the current state of browser features, as ing functionality to be blocked or allowed on a per-site basis. The well as existing user level security defenses. set of standards blocked can be updated to reflect changes in the popularity or security costs of each standard. 2.1 Browser Feature Inclusion This work presents the following technical contributions: Browsers compete on performance, security, and compatibility. This final point introduces two security related challenges: first, ven- • ES6 Proxy based feature firewall. (Section 3) We lever- dors are very wary of removing features from the browser, even if age the ES6 proxy object to build a feature firewall which they are used by a very small fraction of all websites [5, 8]. Second, dynamically disables JavaScript API features without break- because the web is evolving and even competing with native appli- ing most code that expects those features to exist. cations (especially on mobile devices), browser vendors are incen- • Code complexity as cost. (Section 4.5.2) We perform a tivized to continue to add new features to the web browser and not static analysis of the Firefox codebase to identify and count remove old features. Browsers using the same code base across all lines of code exclusively used to enable each web standard. devices, including mobile, browser OS devices (e.g., Google Chrome- We find a moderate, statistically significant relationship books), and traditional PCs also increases the amount of code in between this code complexity metric and previously dis- the browser. The addition of support for this variety of devices covered vulnerabilities attributed to these standards. means that JavaScript features that support hardware features (we- • Contextual protection extension. (Section 7) We pack- bcams, rotation sensors, vibration motors, or ambient light sensors, age the feature firewall in an open source browser exten- etc. [36, 37, 39, 58]) are included in the browser for all devices, re- sion that allows the deployment of pre-defined conserva- gardless of whether they include such hardware.