Hmm... We should consider this issue more deeply...
1. If your security concern is to disallow your users to
generate a false request, do not rely on any Referer value.
It is easily forged by browser extensions and other HTTP clients
such as wget.
2. However, if your concern is to protect users from being affected from
externally-generated forged requests, such as CSRF, it may be
partially useful. This is because an attacking pages itself
cannot make a false Referer value sent from victim's browsers.
However, you should aware of the following issues:
0) In many cases there are much better, reliable ways to prevent such
cross-site attacks. You should consider such alternatives as
long as possible.
1) As shown in the original article, there are many ways to
"prevent" browsers to
send Referer headers. If you rely on Referer values, you must
consider any
requests without Referer headers as FALSE requests. However,
2) Many users have configured there browsers or firewalls to strip
off Referers.
Checking the Referer: value (in a correct way shown in 1)) will prevent
such users from using your services.
3) In Mozilla browser, javascripts can send a request with any
Referer value using
XMLHTTP object, as long as the target page is in the same host
as the originating
page. The Mozilla team members state this as a "feature".
However, this feature should not open any new security holes,
because if this makes
any problem, the site is already XSS-vulnerable even without
the XMLHTTP "feature".
The pages in the same host can open a "victim" page into
iframes, emit (or fill out) a
web form into that victim page and then submit it.
4) So, if your application is XSS-vulnerable, there is no way to
prevent CSRF attacks,
unless that you request your customers to input a password with
every requests.
5) Amit's case is obviously a problem, but it is a "bug", not a "spec".
It is a critical consequence of two buggy behaviours on IE and Apache.
It is good idea to prevent those bugs from making your
application exploitable,
but it is a "bug-avoidance" for IE's bug, basically not your fault.
Again, it is a very good idea to avoid that IE's bug.
2005/11/17, Ory Segal <osegal@watchfire.com>:
While we're at it - I'll join the mob, by saying:
Don't rely on the HTTP REFERER for security. :-)
-Ory
