WebApp Sec mailing list archives

Re: HTTP REFERER not set in Internet Explorer


From: Yutaka OIWA <yutaka.oiwa () gmail com>
Date: Thu, 17 Nov 2005 22:10:31 +0900

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



Current thread: