Is there any benefit for a security-paranoid website to disallow HTTP requests that have a Referer: from 3rd party sites?
The pitch is that if such a HTTP request were to come in, then certain XSS attacks would be prevented, and certain OpenID iFrame threats as well.
The user experience would have all users in that case be redirected to a landing page. That landing page would then direct them to either manually type in the URL, or to click a hyperlink.
Is this a good idea?
Short answer. Yes, blocking requests with an off-site Referer: header might have some security benefits, but I do not recommend that you implement it. The usability costs are significant and outweigh any security benefits.
I feel that, as security professionals, our job is not just to recommend defenses that people should implement -- it is also to identify defenses that people should not implement. This is one, in my personal opinion.
Background. Based on the original question, it sounds like it might be helpful to provide a review of the relevant background and articulate more precisely the specific defenses that you are likely considering.
You seem to be considering examining the Referer: header in incoming requests. Most modern browsers set the Referer: header on most requests to list the URL of the previous page that triggered this request or that contained this link. Some requests do not carry a Referer: header; one example is the prior page is over HTTPS, then browsers will not set the Referer: header.
It is important to know that the Referer: header was not designed for security, and cannot be trusted. There are many attacks to cause a browser to omit the Referer: header. There are also attacks that can be used against some browsers to forge the Referer: header (to cause the browser to send a request with a spoofed Referer: header of the attacker's choice). Therefore, most security folks recommend that it is not a good idea to rely upon the Referer: header as your main line of security.
It is also important to know that the Referer: header is not guaranteed to be included, and sometimes it is blocked. The Referer: header has privacy implications: it can be used to track people on the web. Some people feel that it is a violation of their privacy for their browser to routinely tell site B that they were just at some specific page on site A. Therefore, some people configure their browsers to block transmission of the Referer: header. Also, some corporate firewalls and proxies strip out the Referer: header, to avoid leaking confidential or proprietary information to external web sites.
The original RFC (RFC 2068) states that the Referer: header is not mandatory, and explicitly recommends that browsers should provide a way for users to disable transmission of Referer: headers.
For all of those reasons, some fraction of legitimate requests just don't include a Referer: header.
Now, I suspect you are proposing one of two possible defenses:
Strict Referer checking. You designate a specified landing page on your site. If your site receives a request with a Referer: header that refers to any URL not on your site, or receives a request with no Referer: header, then the server immediately responds with a redirect to your landing page.
Loose Referer checking. Same as the above, except that requests with no Referer: header are permitted (they don't trigger the redirect).
Loose Referer checking makes no sense, from a security perspective: there are too many ways that an attacker can trigger a victim's browser to make a request and suppress the Referer:. So I will presume that you are considering whether to implement strict Referer checking.
Security benefits. So, does strict Referer checking have potential security benefits? Yes. They include:
CSRF defense. Strict referer checking makes it harder to mount cross-site request forgery attacks, because other sites cannot direct the user anywhere other than the landing page.
XSS defense. Strict referer checking can make reflective XSS attacks harder, because other sites can't trick the victim's browser into visiting the vulnerable URL.
Clickjacking and framing. I don't know whether strict referer checking helps against clickjacking or being framed. I'll have to leave that to others.
There are some caveats, though. For each of these risks, there are better defenses known. For instance, for CSRF defense, use anti-CSRF tokens. For XSS defense, don't introduce XSS bugs into your software; use template systems with context-sensitive automatic escaping; etc. For clickjacking and framing, use time-tested frame-busting techniques.
Usability costs. There are some major usability costs to enabling strict referer checking throughout your site. These include:
It prevents deep linking. It prevents people from linking to pages on your web site. This means you won't get traffic that others send you, because they link to something great on your site.
It prevents deep bookmarking. It prevents your users from bookmarking anything other than the landing page. That's just annoying, from a user's standpoint.
It blocks some users. Some users won't be able to use your site, either because they use privacy mechanisms that block Referer: headers, or because they're behind a corporate firewall that strips Referer: headers, or the like. This reduces your potential user base. Also, some of the folks who block Referer: headers are the most tech-savvy users, who are potentially your early adopters who might evangelize your site to others; you don't want to unnecessarily block them from using your site.
Overall. So, when I look at this, I see some dubious security benefits, and major usability costs. Moreover, all of those security benefits can be obtained in other ways that don't damage usability, simply by using standard security mechanisms. Therefore, I don't recommend that you adopt strict referer checking.
