Blog: How-Tos
Feature and Permission Policies. Security issues
Introduction
In order to help enhance the user experience of their site, companies may ask to use features of your browser, such as geolocation or notifications to produce a more tailored experience.
Web site developers may configure the site or allow third-party content, loaded in frames, to use feature such as geolocation, notifications, and the camera. Developers can also use policies to tie down the effectiveness of Cross-Site Scripting attacks, by limiting which origins can execute JavaScript.
Requesting permission to geolocate a user may be helpful to a user looking to locate stores closer to them, however, without proper controls in place, these features could be used maliciously.
Web developers can use Permissions-Policy to control how these features are accessed. Permissions-Policy is soon to replace Feature-Policy, however, in order to understand Permissions-Policy, some understanding of Feature-Policy is required as they share many attributes.
This is be closely related to the Content-Security-Policy header, however the Feature-Policy or Permissions-Policy headers are used to control features, rather than content in the browser.
What is Feature-Policy?
Feature-Policy allows web developers to enable, disable or modify various features of the browser through HTTP Header responses or allow attributes in iframes. First introduced in June 2018, the policy outlines what types of features could be requested, when a user visits a web page.
Some of the main feature directives include:
- Geolocation
- Camera
- Microphone
- Notifications
- Background Sync
- USB
A full list of feature directives are available in this following URL:
There are two ways that a request to use a browser feature can be controlled:
- Allow attributes on iframes
- Feature-Policy HTTP Headers
An example of where Feature-Policy is useful is when you allow advertisements on your page, and you want to limit cross-origin requests from accessing the camera. You could set the policy to:
Feature-Policy: camera ‘none’
This would block any access to the devices camera and the user would not be prompted for an interactive prompt to enable it for the site.
If the developer chooses to configure the Feature-Policy wildcard for the camera:
Feature-Policy: camera *
This will allow it on all origins and iframes on the page, however, browser constraints would prompt the user to allow this feature:
Figure 1 – Browser settings prompting the user to enable camera
Default installations of the Chrome browser, for example, have certain features configured that ask the user first, as these could be used to invade the privacy of the user:
Figure 2 – Default policies when Chrome is installed on Windows10
The Safari browser on MacOS shares a similar privacy model to Chrome, seeking permission to enable browser features:
Figure 3 – Safari Geolocation settings on MacOS
Firefox on the other hand provides a more granular approach to users who want to further control access to features:
Figure 4 – Firefox geolocation user prompt
Firefox opts to the default position of allowing the user to provide access to facility once, with a selection for allowing all, via the “Remember this decision”, which is absent on all Chromium based browsers.
What are the security concerns with this?
Firefox sets a good example of how these controls should be managed by the user: by giving the user a choice, of denying access, allowing once or allowing all; then the user is made aware that there is a potential for site geolocation requests to always remain permitted, until the user specifically resets this in the Chrome settings.
In Chromium-based browsers such as Chrome, Safari and Microsoft Edge, if the user is prompted to allow a feature, they are presented with “Allow” or “Block” options, which if either are selected, they are saved to the browser for as long as the user keeps that setting.
Chromium based browsers hold two types of data on a website:
- Permissions data (Feature-policy access)
- Browsing data
Should a user decide to delete their browser cache for the website within the settings, the permissions data is retained. The user is required to also reset the permissions data that was previously allowed on the site.
When a user first browses to the following Feature-Policy demonstration website, some data is cached:
Figure 5 – Cached data and default feature-policy permissions
If the user selects that they want to allow geolocation features, the permission selection is saved to their browser for that site:
Figure 6 – Geolocation policy allowed for the site
If the user decides to clear the usage data for the site, it is only the cache that is deleted, and not the permissions. In order to reset any previously accepted features, the user also needs to “Reset permissions” to set these to default.
This presents as problematic for users who use software to delete browsing data or expect that such a process would also reset the permissions for the site.
If a third-party website, which loads an advertisement on a page, was compromised, the user would not be protected from requests for geolocation data because Chromium-based browsers require users to reset permissions when the web cache is cleared. Chromium based browsers display a popup option when clearing website data:
In order for the user to be sure that any clearance of website data is married up with a reset of any permissions, the default position should be as shown below:
What is Permissions-Policy?
A working draft is in place to discontinue Feature-Policy in favour of Permissions-Policy. The World Wide Web Consortium (W3C) will make reference to both Feature-Policy and Permissions and Permissions-Policy terminology in the transition phase, however, most browsers have moved onto referencing ‘Permissions’ in relation to ‘Features’.
At the time of writing, Permissions-Policy was not supported in any browser by default, however, it could be enabled:
Permissions-Policy will still operate in the same way that Feature-Policy does. To enable, disable or modify browser related features requested in its own frame or document or from third party iframes, however, under a different name, and some slight syntax changes.
For example, to globally set the geolocation permissions for a document in the HTTP Header:
- Feature-Policy
Feature-Policy: geolocation ‘none’
- Permissions-Policy
Permissions-Policy: geolocation=()
Using Permissions-Policy syntax, permissions, or features, can also be set in cross origin iframes as follows:
<iframe src="https://example.com/location" allow="geolocation"></iframe>
In the above case, geolocation is allowed for the source origin that is defined. Should you choose to set a site-wide deny policy on geolocation via HTTP Headers, you can use the ‘allow’ iframe attribute to selectively allow geolocation for that iframe.
This is useful, if you have Google Maps on a page, and an advertisement banner. Any attempt to geolocate the user within the advertisement would be blocked by the HTTP Header policy, however, the Google Map request would be allowed, subject to the user selecting it in the browser pop up.
This is the essence of how Permissions-Policy works. A way to control how content is loaded in iframes from third party sites.
Misconfigurations
Not all systems are perfect, and some misconfigurations may occur that could potentially pose an issue for website users.
Developers may leave the following HTTP Header set to test a feature:
Permissions-Policy: geolocation=*
This means that geolocation would be granted to all frames within the document or page. Taking the example shown above, where Chromium browsers remember the permissions state of a site when the user clears only the browsing data, a developer could expose the location of a user with this HTTP Header, if content in a third party iframe requested it.
If a site had a large number of third-party content loaded in iframes, spread across multiple pages, they’d be required to conduct an assessment of what permissions each iframe needed. It may become common, while under pressure to set either no Permissions-Policy on the site, or a misconfigured policy under pressure.
If a site has multiple pages, and interactions, it may prove too difficult to manage. Spread that issue across the many features a browser contains and some less protected features may be exploited.
Using the browser console, we can enumerate what types of permissions state a feature is in by issuing the following queries:
navigator.permissions.query({name: “camera”})
navigator.permissions.query({name: “geolocation”})
This wouldn’t be too difficult to incorporate into a Cross-Site Scripting attack, to learn which permissions have been accepted by the user. This could be part of a chain of attacks, e.g. to check whether camera access is possible before trying to use it and not alert the user.
Figure 10 – XSS camera permissions
Allowed Features
Chrome has many features that are set to ‘Allow’ by default, when requested by the site:
- chrome://settings/content
| Feature | Default Position |
| Background Sync | Allow |
| Motion Sensors | Allow |
| Handlers | Allow |
| Payment Handlers | Allow |
The user’s browser should not be trusted as a last defence as exploits could exist to allow all permissions. Control on how a site or third-party origin requests access to features in the browser should remain with the site.
Summary
Permissions-Policy is still in its draft phase, which means that changes will likely occur forward of writing this summary.
Some companies will likely use it to narrow down the potential threat of loading malicious third-party content, however, a lack of fully understanding on how to implement it, could potentially lead to some configurations that lack proper security controls.
The user’s browser may act as a trap to misconfigured policies, however, if the policy is set correctly, this will provide the user with less options, and a lesser chance of making the wrong decision.
