This is one of the security issues I found while investigating another security bug. This was a security misconfiguration in Firefox Quantum browsers (v56 and above) which could leak sensitive URLs through referer header.
I would like to explain this bug in details!
What are referer headers?
The Referer request-header contains the address of the previous web page from which a link to the currently requested page was followed. The Referer header allows servers to identify where people are visiting them from and may use that data for analytics, logging, or optimized caching, etc.
source (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer)
So in simple words, when we are moving across a website or navigating across webpages, the next request has a referer header which has the URL details of the previous page.
Yes, its spelled as referer. Someone in the past mistook "referrer" as referer, and we are carrying it forward :)
Abuse of referer headers!
But this functionality became security issues at certain places.
For a modern web app. It's very common to have a password reset features, which sends you a password reset token to your email with which we can reset our passwords. The URL will be something like
https://www.somewebsite.com/passreset?token=thetoken
Now ist very common for a modern web app to have images hosted over CDN, or external javascript files as well as some external links on the footer page when the password reset page is opened. When these urls are called, or any external link is clicked, the referer header is carried along
https://www.somewebsite.com/passreset?token=thetoken
Hence its leaking your password reset token, or perhaps session tokens, etc. to an external website.
So one of our 3rd party might be getting all your user's password reset tokens in their logs.
Bad right?
The fix:-
The HTML attribute
rel="noopener noreferrer"
is used to instruct the browser not to send any referer header upon clicking the external link.
So if your website has a footer which links to suppose "shashank.co" and as a website owner, you wish that your client's referer header is not leaked to "shashank.co". So you do this!
The above code will fix this issue.
Now the Firefox quantum browser was failing to act on rel="noopener noreferrer" and was still sending referer headers to external links.
I reported this bug. Unfortunately, it was duplicate of some similar report which was pointed out for pinned tabs. I still have no idea how someone spotted for pinned tabs when it was also not working for normal tabs with external links.
This bug has been fixed in Firefox v59 (Beta).
I would like to explain this bug in details!
What are referer headers?
The Referer request-header contains the address of the previous web page from which a link to the currently requested page was followed. The Referer header allows servers to identify where people are visiting them from and may use that data for analytics, logging, or optimized caching, etc.
source (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer)
So in simple words, when we are moving across a website or navigating across webpages, the next request has a referer header which has the URL details of the previous page.
Yes, its spelled as referer. Someone in the past mistook "referrer" as referer, and we are carrying it forward :)
Abuse of referer headers!
But this functionality became security issues at certain places.
For a modern web app. It's very common to have a password reset features, which sends you a password reset token to your email with which we can reset our passwords. The URL will be something like
https://www.somewebsite.com/passreset?token=thetoken
Now ist very common for a modern web app to have images hosted over CDN, or external javascript files as well as some external links on the footer page when the password reset page is opened. When these urls are called, or any external link is clicked, the referer header is carried along
https://www.somewebsite.com/passreset?token=thetoken
Hence its leaking your password reset token, or perhaps session tokens, etc. to an external website.
So one of our 3rd party might be getting all your user's password reset tokens in their logs.
Bad right?
The fix:-
The HTML attribute
rel="noopener noreferrer"
is used to instruct the browser not to send any referer header upon clicking the external link.
So if your website has a footer which links to suppose "shashank.co" and as a website owner, you wish that your client's referer header is not leaked to "shashank.co". So you do this!
<a href="https://www.shashank.co" target="_blank" rel="noopener noreferrer">', '</a>
The above code will fix this issue.
Now the Firefox quantum browser was failing to act on rel="noopener noreferrer" and was still sending referer headers to external links.
I reported this bug. Unfortunately, it was duplicate of some similar report which was pointed out for pinned tabs. I still have no idea how someone spotted for pinned tabs when it was also not working for normal tabs with external links.
This bug has been fixed in Firefox v59 (Beta).
