Cross Domain Referrer Header Leakage

Referrer Header is a request header used to obtain information about what is the previous URL or link from which the current website is reached. This information is used in many typical business use cases. The referrer header as the name implies is used to obtain information about the URL that refers to the current URL.

For security reasons, Referrer Header is not sent by the browser if the URL that links to a certain page is a file system URL like file:/// or data:///. This may leak local machine details to the website administrator.

Use Cases

1. Data Analytics: It is common for websites to place advertisements on multiple other websites and provide a link to their website. The business might then need to track the referrer domains based on the traffic they generate. To obtain this, the website may use the referrer header to know the website from which the user is coming.
2. Site Map and navigation based analytics: To understand what is the most commonly visited page and what is the source page that links to the current page.
3. Logging: To Log tracking details in application logs. This data might be used to identify data patterns.

Cross-Domain Referrer Header Leakage and Impact

The URL consists of multiple parts. The Scheme, Domain, Path, and Request Data. These data might contain some critical information. A path may contain a password reset token. Ideally, the password token is used to authenticate a user who has forgotten his/her credentials on a website. Once the user requests the site to generate a password reset link, the website creates a reset link (typically, one time usable) and sends it back to the user via email. This token URL is critical since anyone with this URL can actually reset the password of a user and can take over a user account.

This becomes even more critical when the account involved is related to monetary transactions like Internet Banking account, Payment wallets or privileged access accounts like Site Administrator, etc.,

Below is a representation of a scenario where this can occur.

Example 

Scenario: When a password reset link leak happens.

1) User clicks forgot the password button on the trusted.com website.

2) trusted.com generates a one-time password reset link and sends it back to the user.

3) The request is similar to below,

https://trusted.com/reset-password/abcaa2ss-asd2s-23412aasdzla

4) The user opens the link, and after this call is made in the user browser, trusted.com may also make calls to other third party domains for analytics or static domains or other third party services like maps.

5) If the user just opens the reset link and closes it without resetting the password, the calls made to the third party domain will have reset token with one time hash in the referrer header.

https://google.com/analytics.js
Referrer : https://trusted.com/reset-password/abcaa2ss-asd2s-23412aasdzla

6) The third-party domain from its application logs may access this data and reset the password.

Some cases where Referrer Leakage is a serious vulnerability:

1. URL containing Password reset token.
2. URL containing access token of a user being passed in a referrer.
3. URL containing an inter-service token that is used to communicate between different web services.

Protecting from Referrer Leakage Vulnerability

Referrer headers must not be set on all URLs and all domains. It is possible to specify when to send and when not to send referrer headers. This is defined by what is called a referrer policy. Common policies include-

1. Referrer-Policy: no-referrer- Disables referrer information being sent on Request Headers.
2. Referrer-Policy: Origin- Sends only host domain in the referrer, not the entire URL path.
3. Referrer-Policy: Same-Origin- Send header information only if both parties (Source link and Destination Link) are in the same domain.