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 19:01:26 -0300
Message-ID: <CAE5Wca2YvHO0-N+bJenrJzU-y2mcseFTFVi14nUK6JXvDMEv_w@mail.gmail.com>
To: dveditz@mozilla.com
Cc: Jeff Goldberg <jeff@agilebits.com>, WebAppSec WG <public-webappsec@w3.org>
I got your point. Thanks!

On Wed, Aug 1, 2018 at 2:46 PM Daniel Veditz <dveditz@mozilla.com> wrote:

> Jeff and I were emphasizing two different attack scenarios. If the
> resources need to be protected from your customer then you can't trust
> anything: the customer could have all manner of browser modifications if
> that's what's required to get at what they want. For example, Firefox has a
> buried setting that will spoof the referrer to match the site of every
> resource it loads, and some extensions turn this on. You can't trust
> cookies in this scenario, either.
> If you're mostly worried about a CSRF-like situation where a malicious
> sites is trying to abuse the credentials of an innocent victim, in that
> case you could trust the referrer if it's present (assuming the user hasn't
> hacked themselves by turning on the hidden Firefox referrer spoofing). If
> there's no referrer it could be an attack because it's easy to suppress the
> referrer.
> -Dan Veditz
> On Wed, Aug 1, 2018 at 5:49 AM, Ricardo Iramar dos Santos <
> riramar@gmail.com> wrote:
>> 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
>> Policy.
>> On Sun, Jul 29, 2018 at 11:40 PM Jeffrey Goldberg <jeff@agilebits.com>
>> wrote:
>>> 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 22:02:08 UTC

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