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:
- Re: HTTP REFERER not set in Internet Explorer, (continued)
- Re: HTTP REFERER not set in Internet Explorer Chris Varenhorst (Nov 17)
- Re: HTTP REFERER not set in Internet Explorer Todd Hendricks (Nov 17)
- Re: HTTP REFERER not set in Internet Explorer Dean H. Saxe (Nov 17)
- Re: HTTP REFERER not set in Internet Explorer Greg Skouby (Nov 17)
- RE: HTTP REFERER not set in Internet Explorer Richard M. Smith (Nov 17)
- Re: HTTP REFERER not set in Internet Explorer Oleg Lecinski (Nov 17)
- RE: HTTP REFERER not set in Internet Explorer Amichai Shulman (Nov 17)
- RE: HTTP REFERER not set in Internet Explorer Jeff Robertson (Nov 17)
- RE: HTTP REFERER not set in Internet Explorer Einecker, Leah (Nov 17)
- RE: HTTP REFERER not set in Internet Explorer Ory Segal (Nov 17)
- Re: HTTP REFERER not set in Internet Explorer Yutaka OIWA (Nov 17)
- Re: HTTP REFERER not set in Internet Explorer Saqib Ali (Nov 17)
- Re: HTTP REFERER not set in Internet Explorer Yutaka OIWA (Nov 18)
- RE: HTTP REFERER not set in Internet Explorer drm (Nov 17)
- Re: HTTP REFERER not set in Internet Explorer Yutaka OIWA (Nov 17)
- Re: Re: HTTP REFERER not set in Internet Explorer mike (Nov 18)
- Re: Re: HTTP REFERER not set in Internet Explorer Saqib Ali (Nov 21)