HTTP_REFERER as Secondary security?

exnet

Hey!
I am writing code which is served by a freeBSD/Apache machine. The code will not be moved to another server, so I am not concerned with ever running it in another environment or another machine.

A couple of the pages require data to be passed via the query string as opposed to through a form, so one of my concerns is protecting the integrity of that data. I have some security measures in place, but was wondering if anyone sees any harm in using the $_SERVER['HTTP_REFERER'] variable as a secondary security check.

For example, whenever someone clicks on a link, the referer value is my server that the code is running on, which is what I want. However, if the user messes with the query string in any way (inserts variables, changes values, etc), the referer value is no longer reported as my server. So, if the referer variable I get back is not my server, I can tell that the query string was modified and I don't accept that data.

I have tested this with IE, Netscape, and Mozilla and it works fine. PHP.net however, says: "HTTP_REFERER--The address of the page (if any) which referred the user agent to the current page. This is set by the user agent. Not all user agents will set this, and some provide the ability to modify HTTP_REFERER as a feature. In short, it cannot really be trusted." Again, as a person that wants to code securely, I've added this as a secondary measure--not the only thing I am relying on.

So, can anyone tell me if, for some reason, this is a bad idea? I've tested and tested it and it seems to work fine, but someone out there may know of some reasons not to use this. The PHP.net quote keeps haunting me! Sounds like a browser issue (user agent), but the three main browsers I tested on worked fine...
Thanks in advance!

swr

Some browsers can be configured (sometimes with add-on software) to not send referrers. Some proxy servers can strip referrers. This may be becoming more common due to privacy concerns.

It doesn't hurt to do the check, as long as you allow blank referrer. This will help block certain types of cross-site scripting attacks, or at least make them more difficult. It can also be used to prevent other sites from consuming your bandwidth by using "img src=" images pointing to your site (most will have referrer from the remote site).

It will not prevent the user from sending you modified form variables. It is not difficult for someone with a little know-how to do HTTP directly with no browser, and bypass all checks that trust the client (referrer, cookies, POST form variables (including hidden), javascript, etc). There are also tools to allow people who don't know anything about HTTP to do it. Some are as simple as a bookmark: http://www.squarefree.com/bookmarklets/forms.html#show_hiddens

AstroTeg

I believe with Mozilla's Preference Toolbar (its a plugin) there's a checkbox which lets you toggle the sending of the referer. I haven't tried this, but you could also do (in Mozilla and probably Firebird):

about:config (in the URL bar)

look for:
network.http.sendRefererHeader

Mine's set at 2 which I believe sends the referer. I'm not sure if all you need to do is set it to zero or not (the Preference toolbar makes this much easier to toggle).

I might recommend checking it out and playing with it with your site for testing. You'll need to figure out what you want to do with blank referers which may come from browsers which do not send referers.

If you've looked at Curl, its very possible (and somewhat easy) to forge header information including the referer. Checking the referrer may prevent your casual hacker but by itself is not hack proof (sounds like you may have some other tricks in use which will probably help).

exnet

Yup, that's what I was looking for. Since the referer was my server, I was hoping that the browser wasn't part of the equation (I knew this wasn't the case, I just didn't want to admit it).
Now I've got the proof and can proceed accordingly. Thanks for the insight!