9

At work we use a central portal that provides basic SSO functionality to other applications. In addition to verifying the SSO data sent, all of our existing in-house applications (used by the public) also check the referrer header to make sure that the user is actually coming from our central portal. However, we just experienced an issue where a JavaScript code change in the central portal caused Internet Explorer to stop forwarding the referrer header, which brought down all the apps that check that header.

My question is whether checking the referrer header provides any real world security improvement over just checking the basic SSO information (encrypted user ID contained in a cookie)? If it doesn't, is there any documentation/research/etc. that I could use to prove this to management?

I should also mention that unfortunately the central portal is a third party app which we don't have much control over ... so basic SSO information in the form of an encrypted cookie and referrer header information is all we have to help secure things.

Harry Muscle
  • 283
  • 1
  • 3
  • 6

4 Answers4

5

Short answer: no.

Long answer: it depends.

Referer is a header sent and controlled by the client. You cannot trust any data coming unchecked from the client. As others pointed out, it can be easily manipulated. It can contain anything the attacker wants, so don't rely on it.

If your URL contain any crypto token(http://site.com/x.php?op=1&token=-random-data-), it could be marginally useful. You would have to check the token with a session variable to determine if the header was not tampered.

But even with a token, referer checking will only work until a new browser/plugin/extension/proxy begins stripping Referer header for privacy reasons.

If possible, you can try to use the IP address of the client tied to browser fingerprinting headers (User-Agent, Accept, Accept-Language) to get more layers of security. Keeping those headers on a sesssion variable, you can detect if someone stole the credentials of your user, if someone is trying to bypass authentication, and other attacks.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
4

It will pick off the low hanging fruit, but in general, it is not hard to spoof a header. I would say that if it has caused issues in the past, it is more than likely not worth the risk to your business apps.

nrduren
  • 143
  • 1
  • 7
2

The best way, probably, would be to demonstrate to the management how easy this security measure can be circumvented.

You can use e.g., the Burp Proxy (http://portswigger.net/burp/download.html) to intercept and modify/add referer header.

  1. Download and install the Burp proxy (there is a Free Edition).
  2. Configure your browser to use the Burp proxy.
  3. Use the browser to authenticate to your application.
  4. Look at requests/responses in the Burp Proxy, i.e., Proxy tab -> Intercept tab
  5. Use a Forward button to send a request (you can add/modify any line including the referer header).
sta
  • 136
  • 3
0

As others have already explained, referrers can be easily spoofed. Also, according to the HTTP standard, they are entirely optional. There are privacy settings and addons for some browser which always suppress referrers and there is nothing malicious about that.

For that reason I would recommend you to consider no referrer a correct referrer and only reject the request when the referrer explicitly points to a website you don't control.

Philipp
  • 48,867
  • 8
  • 127
  • 157