Re: Referer Spoofing

IMHO Content Security Policy could help you

https://www.owasp.org/index.php/Content_Security_Policy_Cheat_Sheet#Basic_CSP_Policy

by frame ancestor you also avoid an attacker to iframe you


On Wed, 1 Aug 2018, 23:04 Ricardo Iramar dos Santos, <riramar@gmail.com>
wrote:

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