Link Search Menu Expand Document

Incorrect Referrer Policy

Play SecureFlag Play Labs on this vulnerability with SecureFlag!

  1. Incorrect Referrer Policy
    1. Description
    2. Impact
    3. Prevention
    4. Testing
    5. References

Description

When opening a link in a new tab with target="_blank", unless otherwise specified, the target is passed some information about the originating webpage. Often this does not pose any security risk, but in cases where the URL in question is somewhat untrusted, it could be wise to enforce some protection in this regard. Or at least, this used to happen, nowadays most browsers changed this default behavior and do not pass any information regarding the opener by default, yet the previous behavior still applies when a new tab is opened using window.open.

The two main vectors of compromise are:

  • The Referer header: it informs the target web server of the URL of the page that initiated the loading of the present resource;

  • The window.opener JavaScript property: it allows (to a certain extent - the SOP (Same-Origin Policy) is in place here) access to the Window object of the page that initiated the navigation in the new tab.

The former is critical if the originating page holds some sensitive data in the URL (which it shouldn’t) and can be abused to perform a subtle yet nasty phishing attack. The rel HTTP attribute of the a elements can be used to alter these default behaviors.

Impact

The Referer header might disclose unwanted sensitive information about the originating webpage to external servers.

Allowing the next origin to interact with window.opener can be used to set up the following phishing scenario. Suppose that some legitimate web application allows untrusted users to add external links in one of its pages, for example:

<a href="http://attacker.com/trigger.html" target="_blank">Click me!</a>

When a user clicks on the above link, the http://attacker.com/trigger.html is loaded in a new tab. Now, assume that this target page contains the following HTML:

<script>
    window.opener.location = 'http://attacker.com';
</script>
<a href="#" onclick="window.close()">Close this tab</a>.

What happens upon loading is that the malicious page trigger.html uses the window.opener property to load a different URL (http://attacker.com) which, for the sake of the narrative, represents a phishing page that mimics the original legitimate page. Inattentive users may simply click Close this tab to return to the malicious web page and continue to use the web site as if it were the legitimate one.

Prevention

Prevention is achieved courtesy of two rel attribute values that control what is passed to the next origin, respectively: noreferrer and noopener. In older browsers, noreferrer was also used to prevent the next origin from accessing window.opener, so it is advisable to employ both:

<a href="http://attacker.com/trigger.html" target="_blank" rel="noreferrer noopener">Click me!</a>

In the case of window.open(), if it is really needed, we can still pass such attributes with:

window.open('http://attacker.com/trigger.html', '_blank', 'noreferrer noopener')

Testing

Verify that the application enforces the correct referrer policy instructions.

References

MDN - HTML attribute: rel

OWASP - Reverse Tabnabbing