Welcome to WebmasterWorld Guest from 188.8.131.52
Forum Moderators: phranque
As one part of an overall security plan when someone tries to access a page/script that should only be accessed from another page on the website I check the HTTP_REFERER to be sure it's what I am expecting. If not I redirect them to an error page.
This is starting to cause a lot of problems for people with NIS, AOL8, Opera and other solutions that are able to block or modify the HTTP_REFERER.
So I am wondering what you all think about using the HTTP_REFERER as one part of an overall security plan.
I use encrypted cookies for login, and you have to be a member to access certain pages, but even still, is it worth the hassle, and some would say privacy violation of checking the HTTP_REFERER?
Thanks for your opinions.
You can also use it to ban calls of your images or other resources from other sites. Not 100% effective, but get's the job done.
But for security and banning things, probably not all that reliable... stick with IP's and UA's!
UAs are also easily forged. IPs have to be known in advance. I need better protection for stuff that happens in real time. But validating the HTTP_REFERER just seems like a lot of hassle considering how many people seem to block or modify it.
What type of attacks are you trying to block? If the attack is a targeted attack at a dynamic page/form on your server, blocking based on Referer won't really help. Most tools that attackers use will get it right by default (don't forget that a browser is the easiest way to perform most of these attacks), and the attackers that are capable of coding their own exploit are certainly capable of including that header.
If the attack is not targeted, but is a scan or worm attacking IIS, checking Referer's won't help - IIS will process the request before it even hits your check.
Are you using canned ASP or CGI pages that you feel may have some insecurities which are being exploited en masse? This is the only scenario in which I see Referrer checking being of any use - and even then, it would be quite limited. The way to secure a site is to secure it (!), not to try to thinly hide its vulnerabilities - the disguise won't last very long.
Make sure your core IIS is secure - up to patch, minimal functionality (this is a key!), strong privilleges, and URL lockdown. Make sure all your ASP's and CGI's etc use secure practices (not trusting user input, filtering all external data, etc.) and have been audited. If you eliminate the insecurities, there is no need for surface annoyances.
Note: Referrer checking can be very useful to stop certain types of cross-site scripting attacks (XSS), if that is what you are afraid of. These don't target your server directly, they target users who are currently logged in to your server.
All the code on the site was written by me. I know that's secure although it has not been audited; I've been coding for decades. The web server itself, along with the various other servers are well patched. There is intrusion detection monitoring software running on the server. Users have to be logged in, accepting both the session id cookie and the login cookie in order to access any sensitive scripts/pages. While users are logged in I track them via an entry in the database so their session id and the one on file have to match plus the session object I use to hold info about a logged in user has to be valid. So the HTTP_REFERER seems like the only place I'm unacceptably vulnerable and it is those cross-site scripting attacks which try to "steal" sessions that have been abandoned but not expired I am concerned about since I've seen evidence of them in my log files. But if the referer can be easily forged I'm thinking what's the use of even bothering to check it. I mean, sort of like what you said, if everything else I've done has failed, will this really help in any meaningful way? It doesn't sound like it. Especially given the problems it's causing for my members who cannot control whether the referrer is blocked or modified. Sorry for rambling. Thanks again.
A few alternate solutions:
1) Make the ID's unique per IP address. Of course, you'll have problems with AOL, and with other proxy servers. But there are solutions to this - many proxies transmit a X-Forwarded-For header, and you can treat all subnets as the same IP. You can also monitor the first let's say five requests - if they are from the same IP, assume no proxy is being used, and restrict furthe requests to the same IP.
2) Make the ID's unique to the User-Agent header. Of course, this can be trivially forged as well. But it is one more piece of information that the attacker will need - what is the UA of his victim. (Note that if the attacker can send his victim to a server he controls, he can easily learn this.)
3) How are attackers learning the ID's? Are they predicting them? If so, you need to work on your crypto/PRNG. Are they stealing them through attacks on your user's browsers? If so, depending on the dialogue you have with them, you may want to urge them to patch their browsers. Are they embedding scripts in your site? Then you need to make sure you catch and eliminate them. Also note that Microsoft has introduced the httponly field in cookies, which guards against script-based cookie theft.
If you need clarification on all this, sticky me.
I must add that you should recheck your analysis of your logs. Mass exploitation of XSS is very rare, primarily since it requires the interaction of the legitmate user as well. Is it possible that you have misdiagnosed what you're finding in your logs?
A caveat: You mentioned that you know that your pages are secure since you have been coding so long. The needs of security are related to, but not identical, to the needs of solid programming in general.
Jamie, I do not enforce these restrictions on most pages. It's the pages/scripts where someone could do something malicious that I take great security precautions, including checking the referrer. :-)