The Referer HTTP request header contains the URL of the page from which the user followed the link and came to a web resource (web page, image, etc). This header can be used for page analytics, logging, etc.
Possible Attacks
Sensitive information might be present in query string parameters or the path of a URL. If these are passed in the Referer HTTP request header, then it becomes a possible vulnerability. Let’s try to understand this using example use cases.
Example use case 1
On the reset password page, there is an external image loaded. When loading the image, the Referer HTTP request header is passed and the whole page URL can go in it. The whole page URL will have sensitive information like the password reset token. An attacker can use this information to get access to the user account.
Example use case 2
On the reset password page, there is a link that takes the user to a social share flow. Referer HTTP request header is passed to the social network site and the whole page URL can go in it. This has the same risks as the example use case 1.
Defense Against Above Attacks
To mitigate the risk of exposing sensitive information via the Referer HTTP request header, we need to set the referrer policy correctly. Referrer Policy can be set at the whole page level OR at each link level. Let’s explore all the possible ways of setting this referrer policy.
Referrer-Policy HTTP response header
We can set the Referrer-Policy HTTP response header to avoid sending the full URL or even totally avoid sending any value in the Referer HTTP request header. If the Referrer-Policy HTTP response header is not set, then the browser takes the default value. This default is based on the browser version. To avoid browser version dependency, we should always set this header.
strict-origin-when-cross-origin is the preferable value and the default in the current browser versions. If the URL is of the same origin, then the full URL is passed in the Referer HTTP request header. Otherwise, only the domain is passed. If there is a switch from HTTPS to HTTP, then nothing is passed.
meta tag
A meta tag with name referrer and content the value of the policy can be set. This effects the whole page. All the Referrer-Policy HTTP response header values are allowed in the content value of this meta tag.
referrerpolicy attribute
We can even set referrerpolicy attribute for <a>, <area>, <img>, <iframe>, <script> or <link>. This gives control of setting the referral policy at an element level. All the Referrer-Policy HTTP response header values are allowed here.
rel attribute
noreferrer value can be set for rel attribute in <a>, <area> or <link> elements for avoiding sending of Referer HTTP request header.
Exit page technique
Instead of sending user to external links directly, we can take the user to a common exit page, which then redirects to the external link. This way, the Referer HTTP request header contains the URL of the exit page. This technique is not dependent on the browser version and will work in all cases.
Conclusion
In this blog, we saw the vulnerability of exposing sensitive information via the Referer HTTP request header. Also, we discussed the possible defense mechanisms. If you want help in eliminating this vulnerability, you can get in touch with True Sparrow, that’s us.
