Re: Referer Spoofing

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