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

Re: Referer Spoofing

From: Jeffrey Goldberg <jeff@agilebits.com>
Date: Sun, 29 Jul 2018 20:40:06 -0600
Message-Id: <6256CCA5-0B30-4093-9708-D78E5C4B961A@agilebits.com>
Cc: WebAppSec WG <public-webappsec@w3.org>
To: Ricardo Iramar dos Santos <riramar@gmail.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 Monday, 30 July 2018 02:40:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 30 July 2018 02:40:49 UTC