Opera's Cross Network Protection

Background

The way the Web is built, any page can request any resource from any other server. This is commonly used, and an essential building block of most modern web pages. Such third party requests will be sent from the user's browser, being indistinguishable from the user loading the resource as a first party request (going straight to the page). This has many benefits, for instance mashups and ads require this, but there are also security issues, the best known is CSRF. The background for the security issue is that the third party server might not anticipate all kinds of requests, or might believe that the requests (e.g. to change security settings or delete data) were manually submitted by the user. To combat this, most servers implement CSRF tokens, to verify which page the request was sent from, and rejects requests not sent from approved pages. It is generally thought that protection agains CSRF is the responsibility of the server.

The harsh and often malicious environment on the internet, where any security bugs can and will be abused, requires hardening of the security of servers and applications available on it. There is a large class of applications which are assumed to be behind a firewall, and thus are lacking this hardening, including intranets, home routers, developer environments and more. Such applications might even not require a login. The problem occurs when an internet page asks for an unsecured resource from behind the firewall, and the browser then requests this on behalf of the user. Thanks to the same origin policy, an attacker does not have direct access to such intranets, and it is hard to attack them. But if an attacker can make enough requests, he can attempt to either slowly collect enough indirect information to find holes in the intranet, or to use known issues in a number of different applications, and hope the intranet uses one such application, sometimes referred to as vulnerability scanning.

One particularily nasty attack, is reconfiguring users' home routers. Such routers use standard setups, often without hardened security and with default passwords. If a router's DNS setting can be changed, all HTTP traffic can be hijacked without the user knowing.

There are also a few more subtle attacks possible on intranets than CSRF, for instance DNS rebinding. Let us say you visit example.com, which includes an iframe from sub-domain.example.com. Your browser will now contact example.com, asking which address to find sub-domain.example.com at, and the DNS might respond with an intranet address. The same domain policy should still protect you, these are still two different domains. However, the browser will periodically recheck the address, and if the address on the next check is pointing to a server controlled by the attacker, a new attacker-controlled page can be loaded, with full access to the iframe whose contents came from the intranet. Note that such attacks are mostly useless on the internet, as it only gets information which can be read from the server by anyone with access to the server.

The solution

Opera categorizes all server IP addresses as in one of three network types; public (internet), restricted (intranet) and personal (localhost). Pages can request resources from less secure network types, but not automatically from more secure. Links to more secure network types work as expected, and inline resources from more secure networks will need a user click past them. For the threat scenarios described above, an attacker needs to make a large number of requests to the more secure area, by requiring user interaction for each, this becomes impractical.

You can also test how your browser handles such requests from the internet.

DNS addresses are locked to the network type they first are bound to. They can be rebound to another address in the same network, but not in any other.

Disabling

Sometimes there are special setups where users want to disable this protection. Some hotspots will redirect you to an internal page when you request your first internet page, a scenario which is indistinguishable from an attack. This is normally fixed by the click-through to log in to the hotspot, and then you will not see the warning page any more.

Some might have special intranet setups, where some public servers end up redirecting to intranet servers. This can be due to having a public server with an employee-only section, special test environments, or using some kind of proxies. Web page developers often develop on localhost, and might redirect a subdomain to the localhost. For this kind of setup, there is an option on the click-through page to always allow requests to that particular server. You should use this if you know that the server is hardened against internet attacks, and you otherwise would hit the click-through page multiple times, or with background requests where you would have no other way of overriding the protection.

In some cases, one might want to disable this check entirely, that can be done in Opera's settings.

Potential questions:

Is Opera the only browser to have this particular protection?

Yes. There are other ways to achieve similar things, some browsers may have some similar restrictions, or add-ons, but as far as we know, no other browser has the same level of protection, though Internet Explorer 10 is planning a similar protection. We welcome information about other browsers in the comments. We consider our Cross Network Protection an additional layer of security, above and beyond what is normally expected of a browser.

Why haven't other browsers implemented this protection?

Presumably because there have been few attacks in the wild abusing this scenario, so they have not seen the need. The attack scenario is well-known, and our protection has been public since Opera 9.50.