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:49:03 -0300
Message-ID: <CAE5Wca0hx=morvaMkRUVtnxC=QCgs1A+BcNpF7pKwAni5tsyDQ@mail.gmail.com>
To: jeff@agilebits.com
Cc: WebAppSec WG <public-webappsec@w3.org>
Thanks for your replay!
I was just thinking about if the application does not trust in anything
from the client side but what about the other request headers like Cookies
and Origin? Like Daniel said some cases do not apply for any header
like  Referrer

On Sun, Jul 29, 2018 at 11:40 PM Jeffrey Goldberg <jeff@agilebits.com>

> On Jul 29, 2018, at 4:45 PM, Ricardo Iramar dos Santos <riramar@gmail.com>
> wrote:
> > Can we rely on referer request header?
> The referrer header is completely under the control of the client (just
> like the User-agent header). They provide you useful information in those
> cases where the client has no reason to be deceptive. So these are
> reasonably trustworthy exactly when the client has no reason to lie.
> If, however, the client can gain certain access to resources or additional
> privileges by lying about its referer then you absolutely cannot trust it.
> > 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).
> I don’t know whether a typical browser makes it easy or hard to spoof the
> header, but using (or building) atypical browsers certainly would. So
> again, if the client may be malicious then you cannot trust the referer
> header.
> > In the past IE/Edge had some issues (
> https://www.brokenbrowser.com/referer-spoofing-defeating-xss-filter/) but
> this was fixed long time ago.
> Using the referer header as an XSS defense or for access control is asking
> for trouble. Don’t do that. Really, don’t do that.
> Cheers,
> -j
> –-
> Jeffrey Goldberg
> Chief Defender Against the Dark Arts @ 1Password
> https://1password.com
Received on Wednesday, 1 August 2018 12:50:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:04 UTC