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

Re: Referer Spoofing

From: Jim Manico <jim.manico@owasp.org>
Date: Wed, 1 Aug 2018 07:51:54 -1000
To: Daniel Veditz <dveditz@mozilla.com>, Ricardo Iramar dos Santos <riramar@gmail.com>
Cc: jeff@agilebits.com, WebAppSec WG <public-webappsec@w3.org>
Message-ID: <3533e918-9cb4-ff96-0c03-3ba1f46a5c0e@owasp.org>
+1 and well said Dan

On 8/1/18 7:46 AM, Daniel Veditz 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 <mailto: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 <mailto:jeff@agilebits.com>> wrote:
>         On Jul 29, 2018, at 4:45 PM, Ricardo Iramar dos Santos
>         <riramar@gmail.com <mailto: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/
>         <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 17:52:31 UTC

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