- From: Ricardo Iramar dos Santos <riramar@gmail.com>
- Date: Wed, 1 Aug 2018 19:01:26 -0300
- To: dveditz@mozilla.com
- Cc: Jeff Goldberg <jeff@agilebits.com>, WebAppSec WG <public-webappsec@w3.org>
- Message-ID: <CAE5Wca2YvHO0-N+bJenrJzU-y2mcseFTFVi14nUK6JXvDMEv_w@mail.gmail.com>
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 >>> >>> >>> >
Received on Wednesday, 1 August 2018 22:02:08 UTC