I used to validate the HTTP referer header to verify that users were accessing certain pages from certain other pages. For example, users accessing
sampleapp/edit.cfm should be getting there from
sampleapp/index.cfm. Anyone accessing
sampleapp/edit.cfm without coming from
sampleapp/index.cfm was probably monkeying around and should be send back to the index page, or possibly even logged out.
However, it is fairly trivial to modify your referer header, so anyone who wants to monkey around with
sampleapp/edit.cfm can make it look like they are coming from
sampleapp/index.cfm. (If you’re interested in modifying your HTTP headers, I suggest checking out the Tamper Data Firefox plugin.) The check provides absolutely no assurance that the user is really coming from the page. Therefore, I decided the check was useless.
I’ve been attending a weekly web application security study group with some of my colleagues for the past several weeks, where we’ve been reading and discussing The Web Application Hacker’s Handbook. The past couple sessions have been about cross-site scripting (XSS). Justin Klein Keane brought up a good point at today’s session: checking the referer may not keep a malicious user from altering his or her referer string, but could help identify victims of XSS attacks who were possibly directed to submit malicious data from a third-party site.
Checking the referer isn’t a sufficient protection against malicious users, by any means, but it could still be helpful. What do you think?