W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2018

Re: Referer Spoofing

From: Ricardo Iramar dos Santos <riramar@gmail.com>
Date: Wed, 1 Aug 2018 09:45:30 -0300
Message-ID: <CAE5Wca1mpmTwxyqj-OPKYMPP9np5CWQ2MQ_8RC0ZBE2Wh_2skQ@mail.gmail.com>
To: dveditz@mozilla.com
Cc: WebAppSec WG <public-webappsec@w3.org>
Got it! Thanks for the replay. I was thinking like if the application trust
on the other request headers like Cookies and Origin why not trust on
Referer. I didn't think in terms of history or Referrer Policy and this is
a really good point.

On Sun, Jul 29, 2018 at 9:43 PM Daniel Veditz <dveditz@mozilla.com> wrote:

> The referrer header from a legit stock browser is not going to lie but it
> might be missing or truncated for various reasons (for example because of a
> Referrer Policy). Also doesn't show the redirect history so it might be
> misleading (the originating page might have been hacked to link through a
> redirector).
>
> -Dan Veditz
>
> On Sun, Jul 29, 2018 at 3:45 PM, Ricardo Iramar dos Santos <
> riramar@gmail.com> wrote:
>
>> Hi All,
>>
>> Can we rely on referer request header?
>> Not sure if here is the right place to ask such question but searching
>> over the web I couldn't find any official documentation from any modern
>> browser explicitly saying that referer request header cannot be spoofed
>> without using internal API (e.g. browser extensions).
>> In the past IE/Edge had some issues (
>> https://www.brokenbrowser.com/referer-spoofing-defeating-xss-filter/)
>> but this was fixed long time ago.
>> If you google about it most of documentation available over the web are
>> saying do not trust on referer request header but if officially there is
>> no methods to change it why not?
>>
>> Thanks!
>> Ricardo Iramar
>>
>
>
Received on Wednesday, 1 August 2018 12:46:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 1 August 2018 12:46:12 UTC