22

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?

8
  • 2
  • @justice Also iFrame Buster Buster. I wonder should we have both? Oct 7, 2011 at 15:16
  • 1
    The web is moving forward. The X-Frame-Options header is forward, with apparently the latest versions of all modern browsers supporting it, while the "iFrame Buster" types are at the losing end of an arms race.
    – yfeldblum
    Oct 7, 2011 at 15:34
  • Can you define more precisely what you mean by a "referral"?
    – D.W.
    Oct 8, 2011 at 19:09
  • 2
    @makerofthings Slightly more difficult, but only a bit. I've just tried to play with it today and already found ways to lose referer header in IE and Chrome (attacker.kotowicz.net/lose-referer/test.php) and there are probably many more ways. Oct 10, 2011 at 16:23

1 Answer 1

27

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:

  1. 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.

  2. 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.

4
  • Thanks for the great information! I noticed that Verisign's OpenID provider doesn't allow referrals when the high security mode is enabled. That unique feature made me wonder about the benefits, or simply limiting what pages can be "referred" to. What are your thoughts about Verisign's approach? Is anyone else implementing it as an IDP, RP? Oct 9, 2011 at 6:58
  • 3
    @makerofthings, I don't know. You'd probably have to ask specifically a question about just OpenID, and you might get better answers on an OpenID forum/mailing list. (P.S. If you do ask elsewhere, a little bit of feedback about how to ask a more precise question-- I find the phrase "allow referrals" vague, and I encourage you to try to be more precise about exactly what you mean, in terms of HTTP headers and what situations are/aren't allowed, such as I tried to do in my post -- I think that might help think others more clearly about the issues.)
    – D.W.
    Oct 9, 2011 at 18:51
  • 2
    The "prevent deep linking/bookmarking" point is moot if the Referer header check is done only for actions (POSTs).
    – ysdx
    Jul 19, 2012 at 23:42
  • Security for the site would not be enhanced by checking Referer, but I would think it could improve security for clients against things like cross-site scripting attacks if their browser would send a Referer: tag when performing certain scripted actions (regardless of whether the script wants the tag sent).
    – supercat
    Oct 8, 2014 at 17:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .