Studying the Privacy Issues of the Incorrect Use of the Feature Policy Beliz Kaleli Manuel Egele Gianluca Stringhini Boston University Boston University Boston University [email protected] [email protected] [email protected] Abstract—In addition to rendering HTML and providing Web parts of a website can access what features, pending user- access, Web browsers offer auxiliary features (e.g., camera, geolo- approval. The Feature Policy is analogous to the Same Origin cation, microphone etc.) that can be used while browsing. Some of Policy [7], in the sense that the website developer and the these features access sensitive information such as camera image, browser developer both need to work together to achieve the microphone, and location data. The common behavior of modern desired protections. browsers when a website tries to access one of these features is to prompt a permission dialog for the user to allow or deny this request. The user’s response may be recorded by the Web In this paper, we show that the use of Web browser features browser and remembered for that website. However, websites may may lead to sensitive data leakage if not handled carefully. include third party resources in the form of HTML iframes. Specifically, embedded iframes in a website can also request Recently, the W3C introduced the Feature Policy to restrict which a feature access through the main website. The sources of these origins contained in a website get access to which features. To iframes may be untrusted third-parties. The responsibility prevent the leakage of sensitive information, both Web developers of the Web browser is to inform users of feature requests and browser developers have to handle feature usage carefully. and what it means to “allow/deny” those requests, whereas the Web developers need to ensure that permissions are only given website developer should limit feature access to third parties to trustworthy websites and Web browser developers have to by using Feature Policy correctly. If the chosen Feature Policy implement the Feature Policy correctly. A wrong implementation from either one of these parties could cause privacy leaks, such is overly-permissive, sensitive user data may also be accessed as an untrusted iframe getting access to the user’s webcam. by untrusted iframe origins. In this paper, we present a study of nine Web browsers Previous studies focused on the adoption of response head- and their behavior regarding feature usage in websites, and ers and their security and privacy implications [8], [9], [10], show that five of them (Chromium based browsers) are open to [11], [12], [13]. In other work [14], [15], researchers proposed social engineering attacks that may lead to sensitive information sandboxing scripts as a countermeasure to data leakage. To the disclosure to untrusted parties. We identify the root causes of this problem as two-fold: Web browsers prompting misleading dialogs best of our knowledge, we are the first to study the adoption when asking for permissions and the wrong use of Feature Policy of the Feature Policy in the wild, and to look at the risks by websites. arising from its incorrect implementation by Web browsers and websites. I. INTRODUCTION To study the extent of the problem, we developed three As technology evolves, new requirements emerge for web- test cases, applied them to 9 different Web browsers, and sites and applications to serve users. While location based ser- observed their behavior. We find that 5 out of 9 Web browsers vices have long enjoyed popularity among mobile applications (Chromium based browsers) are open to social engineering at- (e.g., [1], [2], [3], [4]), commodity browsers started to support tacks that can result in a third party to access sensitive informa- iframes similar APIs and hence allow users to take advantage of the tion from untrusted without the user’s knowledge. location based functionalities on their Web browser. Similarly, We also note that this partial-vulnerability is known by the since most social media apps/websites such as Facebook [5] Chromium developers and was a design choice in response to require camera and microphone access for some functionalities publicly unavailable surveys. (e.g., video-calling), browsers also added support for those features. In summary, the contributions of this paper are as follows: To ensure the privacy of user-data, the W3C recently • We present potential security issues arising from an in- proposed the so-called Feature Policy [6] HTTP response correct deployment of the Feature Policy, and develop header, which allows webmasters to precisely control which three use cases that allow us to identify vulnerable Web browsers and websites. Workshop on Measurements, Attacks, and Defenses for the Web (MADWeb) 2020 • We evaluate 9 Web browsers, finding that 5 of the 23 February 2020, San Diego, CA, USA ISBN 1-891562-63-0 browsers (including Google Chrome) are open to https://dx.doi.org/10.14722/madweb.2020.23xxx social engineering attacks which may lead to sensitive www.ndss-symposium.org data leakage. II. BACKGROUND In this section, we provide the pertinent background infor- mation that the remainder of the paper relies upon. First, we introduce browser features and how permissions can be granted to Web origins. Then, we present the recently proposed Feature Policy, which regulates the feature usage by Web browsers. Finally, we present our threat model of how a malicious party could obtain sensitive information from a victim with an example scenario. A. Browser Features Most modern Web browsers offer several features such Fig. 1: A Simple Attack Scenario: 1. Alice serves a website in as geolocation, camera, and microphone, to enable which Feature-Policy is set as a wildcard for camera feature, several functionalities on websites (e.g., video-calling, ge- 2. Eve serves malicious advertisements, 3. Alice publishes olocation). To use these features, websites ask the user for Eve’s ads on alice.com by embedding an iframe, 4. permission to access every feature they need. When a website Bob visits alice.com. Browser prompts a permission dialog tries to access a feature, the Web browser prompts a permission that contains misleading information which says feature re- dialog box to the user. The purpose of this dialog box is to quest is coming from alice.com whereas it originates from inform the user of the access request, and it typically contains eve.com. Bob clicks “allow” on the dialog box, 5. Eve uses the name of the feature and the origin of the website that the feature and steals sensitive data. requested it, together with “allow” and “block” options. The browser may then record the response to that prompt, which causes a permanent permission, or may alternatively not record the user’s decision and prompt the permission request every own origin. If a developer wants to enable the feature for time. their own website or a third-party websites, they will specify Websites may have embedded iframes in them. These the URI of that website as the value of the allowlist. The iframes may also need to use browser features. In that case “self” keyword and specific URLs can be used together. The the embedded iframes will contain a script in which they wildcard option allows the feature to be accessed in the ask the browser for permission to access one or more features. document, and all nested browsing contexts regardless of their Depending on the Feature Policy configuration, the main origin. For example, the following configuration will allow the website could prevent iframes from requesting permissions camera feature to be used by both the main website and all for features, as discussed next. nested iframes while blocking the microphone usage in all browsing contexts: “Feature-Policy: camera *; microphone ’none’. iframes B. Feature Policy ” If the website contains , the wildcard configuration can be vulnerable since third-party Website developers may want to control access to certain contexts will also be able to access the camera feature. As browser features within their websites as a security or perfor- a result, that third-party will have access to the user’s camera mance precaution. The Feature Policy addresses this issue by and hence record her and steal sensitive data. offering the ability to selectively enable/disable the access to the browser features in its own frame, and in content within C. Threat Model any iframe elements in the document. The HTTP Feature Policy header is used with a directive and an allowlist for Browser features can be requested by both benign and mali- that directive. The directive is the feature to be restricted and cious websites. An educated user will only give permission for may take the values in Table I. using their browser features to trustworthy websites. However, if the Feature Policy is not properly configured by the website The allowlist can take different values. By specifying developer, these permission requests may be coming from the “none” keyword for the list, the specified features will be third-party embedded iframes. For example, advertisements disabled for all browsing contexts, regardless of their origin. are an important constituent of the Web. Many websites publish The “self” keyword will disable the use of the specified feature ads to generate revenue. One possible way to publish an ad within all browsing contexts except for the main website’s is to embed iframes into the main website. The content of this iframe will be provided by the advertisement network “ambient-light-sensor” “autoplay” “accelerometer” or the landing page for the advertisement [16]. “camera” “display-capture” “document-domain” Figure 1 provides an example attack scenario for the type “encrypted-media” “fullscreen” “geolocation” of vulnerability studied in this paper. First, Alice sets her “gyroscope” “magnetometer” “microphone” site’s Feature Policy as a wildcard for the camera browser “midi” “payment” “picture-in-picture” “speaker” “sync-xhr” “usb” feature (Step 1).