Re: Referer Spoofing

+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
>
>
>