- From: Jeffrey Goldberg <jeff@agilebits.com>
- Date: Sun, 29 Jul 2018 20:40:06 -0600
- To: Ricardo Iramar dos Santos <riramar@gmail.com>
- Cc: WebAppSec WG <public-webappsec@w3.org>
- Message-Id: <6256CCA5-0B30-4093-9708-D78E5C4B961A@agilebits.com>
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
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 30 July 2018 02:40:48 UTC