Fencing sites access to localhost in Brave

This is the twenty-seventh post in our series on the new privacy and privacy protections in the Brave browser. We are talking about a new technology that restricts websites’ access to localhost resources.

Starting with version 1.54, Brave on desktops and Android is launching a new technology for controlling which sites get access to local network resources and for how long. Most popular browsers allow sites to access local network resources without any security measures or restrictions, which compromises the security and privacy of users. Many popular sites poll your local network for the purpose of fingerprinting, while others do it in order to obtain and exploit information about other software running on the device.

Brave is the first popular browser to use permission requests to control how websites access localhost resources. Our implementation of this mechanism will allow advanced users to allow any site to access localhost while avoiding annoying notifications that a request to localhost can be malicious. We also used our already implemented developments to improve work with network permissions.

What are localhost resources, and why might websites need access to them?

Localhost resources is a broad term that describes resources (images, web pages, etc.) that a site can access but that do not come from the network: these are local resources that other software places on the device, when often without even realizing it.

It may sound strange, but most browsers give sites access to such local resources just as easily and simply as they give them access to resources on the web. This happens for a number of reasons, but the two main ones are historical legacy (“it’s always been like this”‎) and backwards compatibility. Previously, browsers did not care much about user privacy and, accordingly, did not make efforts to distinguish between three categories of resources: first-party (resources hosted by the site visited), third-party (resources hosted on other public sites) and local resources.

For this reason, a small but significant group of software has been designed with the expectation that it will be freely available to websites, often hidden from the user. Many of these cases are quite harmless: for example, some crypto wallets, Bank security software and security-related companies, as well as hardware that uses web interfaces for configuration. In some cases, browsers also allow public sites to access local resources so that developers can test their software.

Unfortunately, widespread Malicious network software that uses access to localhost resources to harm the user. For example, some scripts may try to install unique software patterns on your device for fingerprinting and re-identification purposes, while others may try to detect unreliable or vulnerable software on your device and try to exploit the discovered vulnerabilities.

How will this innovation affect the access of sites to localhost resources in Brave?

Brave is the only popular browser that provides comprehensive protection against sites that try to maliciously access localhost resources. Brave currently uses filter list rules to:

• Blocking scripts that are known to be engaged in malicious scanning of localhost resources;

• Blocking requests from public sites to localhost resources.

With a few exceptions, which are discussed below, Brave is an exception among browsers in this regard, since for the most part they do not provide protection mechanisms from sites requesting access to local resources.

The system to combat sites that maliciously use local network resources, which we are implementing, will work as follows:

• Requests for local resources from the local context will be automatically resolved; Brave allows a locally hosted page to access other locally hosted resources (this does not include aliases that the user may have set for localhost, such as /etc/hosts).

• Brave will continue to enforce filter list rules to block scripts and sites that maliciously request access to localhost resources.

• Brave adds a new localhost permission. Only sites with this permission will be able to subrequest local resources. By default, no site will have this permission, and importantly, most sites won’t even be able to prompt the user for this permission. However, advanced users will be able to use the existing site setup interface to grant sites this permission (on desktop go to brave://settings/content/localhostAccess; on Android Settings > Site settings > Localhost Access).

• Brave will also include a list of trusted sites that are known to request access to localhost resources in good faith and in the interests of the user. When a site in this list initiates a subrequest to the localhost resource for the first time, it will trigger a request to allow access to the localhost resources. This list publicly available and will be supported by Brave.

We decided to implement the localhost permission system in this multi-stage manner for several reasons; the main one is that we assume that malicious access to localhost resources occurs much more often than cases in which the user benefits from such access; in doing so, we want to avoid a situation in which we redundantly show users dialogs with the ability to grant permissions for requests that we believe will only harm users.

In addition, we purposefully resort to requesting localhost permissions in situations where sites don’t expect it or even know that third-party scripts are trying to access localhost resources, so we also want to reduce the number of permission requests in situations that, we assume will be guaranteed to be useful to users or sites.

How do other browsers deal with requests to localhost resources?

As we’ve said, most other browsers don’t make any meaningful effort to limit the ability of sites to access local resources. The desktop versions of Firefox and Chrome allow both secure and non-secure public sites to access localhost resources, and seem to intend to allow secure public sites to access local resources indefinitely.

Safari, like other WebKit-based browsers, currently blocks requests to localhost resources from secure public sites.but if we understand correctly, this is just a side effect of the general security restrictions policy, and not a targeted Safari policy to block such requests.

To the best of our knowledge, Brave is the only browser that blocks requests to localhost resources from both protected and unprotected public sites while maintaining compatibility paths with sites that the user trusts (using the localhost permissions method above).

What will we do next when working with localhost resources?

We are proud that our users will be able to take advantage of this development, and we believe that it will make the Brave browser even better without compromising user privacy. However, our work doesn’t stop there: there is still a lot to be done in the area of ​​how browsers handle requests for localhost resources.

First, we continue to look for opportunities to further explain to users what localhost resources are. When we are convinced that even non-advanced users understand enough how our mechanism for managing access to local resources works, we plan to implement it for all sites, and not just for sites from our list.

Second, you’re embedding these safeguards deeper into the networking stack so that Brave can protect users from other, less common methods of querying localhost resources by sites (such as DNS records addressing localhost), and we hope to tell you soon. more about our achievements in this direction.

Third, we are interested in unifying and deepening our approach to applying permissions and similar mechanisms to network requests in general. We already apply permissions when working with Google logins that use third-party cookies, and we want to understand in what other similar cases we can apply this model. The main difficulty here is that we will need to apply the asynchronous permission model to requests that are usually made with synchronous waits. We are currently developing several possible approaches both within Brave and in collaboration with outside researchers, and we hope to share updates in this area with you soon.