Browser Referrer Insecurities
HTTP is the application-layer protocol that most web pages are transferred with. As part of HTTP, requests can include a “Referer” (sic) header that tells the server which page the user was on that initiated the request. Servers use this information to track users’ paths through the site and possibly provide additional features. This preference controls when to send the Referer header - kb.mozillazine.org
Many web applications and frameworks rely on referrer information for statistics and some (unwisely) even rely on it for security.
An example of an HTTP request including the referrer field can be seen in the following example:
Cache-Control: private Date: Thu, 23 Nov 2006 15:47:01 GMT Server: GWS/2.1 Content-Type: text/html Content-Type: text/html; charset=ISO-8859-1 Client-Date: Thu, 23 Nov 2006 15:47:01 GMT Proxy-Connection: close Set-Cookie: Removed Title: Google Referer=http://google.co.uk/
Some other examples:
Referer: http://www.google.com.br/search?q=*Hidden for privacy*&hl=pt-BR Referer: http://mail.google.com/mail/?ik=*Hidden for privacy*&view=cv&search=cat&cat=hacking&th=*Hidden for privacy*
Privacy is the most obvious security concern here. Anonymous proxies can obviously be used to mask the source IP address of the user, however, information in the URL (i.e. base64 encoded information etc) in some cases may still create a privacy breech.
Additional information disclosure such as internal hostnames, intranet server names etc can also be leaked. Could you imagine this on an enterprise level? Who knows what information your internal users are leaking out to the Internet? I bet Google has loads of infinite information regarding user’s internal networks.
I remember previous versions of PHPBB use to use session IDs in the URL - I think this has changed now. Web applications still using session IDs in the URL are putting user accounts in danger.
In an interesting way, this issue is the original history hack.
Moral of the story? I think developers are using alternate forms of session management now (i.e. cookies, hidden form fields), however, I am still very surprised that browsers have not implemented a, “disable referrer for external sites.” We know that disabling the referrer altogether can cause problems for some web applications, so why not meet half way?
Currently, Firefox supports the following:
0 - Never send the Referer header.
1 - Send the Referer header when clicking on a link.
2 - Send the Referer header when clicking on a link or loading an image. (Default)
(These settings can be found at: about:config for Firefox users)
As for Internet Explorer users… who knows. I would think another solution would be to restrict the Referrer field at the proxy or firewall which I think a number of security solutions now support.
You’re right you shouldn’t use the referrer for security, but i still think it’s worth to use it for defense in depth. If i have a webapp, i *never* want serve an internal page when the referrer is another site. Maybe it would be better to show only the site to external sites as referrere? So in your example instead of:
Referer: http://www.google.com.br/search?q=*Hidden for privacy*&hl=pt-BR
send the following header:
Referer: http://www.google.com.br/
Or maybe even
Referer: http://not-your-site.example.org/
But why make it blank, i don’t see the use of that…
Mark its an interesting point to only send the base URL as part of the referrer rather then the entire base URL + query string.
My concern and reason for the original post is that of privacy. Why should anyone else on the Internet know where you have been? A number of firewalling products already filter out the referrer header.
As to your point regarding security. The referrer field can be spoofed anyways, so it doesn’t provide the level of security you would expect. Also, you may be limiting alot of your site visitors by using it in this way.