3 ms·

From http://www.codinghorror.com/blog/2008/09/cross-site-request-forgeries-and-you.html http://www.codinghorror.com/blog/2008/09/cross-site-request-... The HTT

by sonnym 15y ago

From http://www.codinghorror.com/blog/2008/09/cross-site-request-forgeries-and-you.html http://www.codinghorror.com/blog/2008/09/cross-site-request-... The HTTP referrer, or HTTP "referer" as it is now permanently misspelled, should always come from your own domain. You could reject any form posts from alien referrers. However, this is risky, as some corporate proxies strip the referrer from all HTTP requests as an anonymization feature. You would end up potentially blocking legitimate users. Furthermore, spoofing the referrer value is extremely easy. All in all, a waste of time. Don't even bother with referrer checks.

personalcompute 15y ago
How is spoofing the referer extremely easy? I can think of no way for an attack site to do this, short of having control over the entire user machine (or a significant browser exploit anyways), at which point all of your webapp security is irrelevant.
- sonnym 15y ago
  You cannot assume a request is coming from a browser. curl --referer http://www.example.come http://www.example.come http://www.example.com http://www.example.com
  - personalcompute 15y ago
    Yes, but if the user wishes to avoid their own security like this, they can already do it a thousand other ways (and to no adverse affect, there is no opportunity for an attacker to exploit this, I don't know what you're getting at).
    - sonnym 15y ago
      I was merely pointing out how easy it is to fake, although you are correct a third party site could not do this. Atwood's point is that checking the "referer" will both be unreliable and, more importantly, lead to false positives; there are better alternatives, namely, double submitting cookies as I have pointed out elsewhere with regard to this article.
      - personalcompute 15y ago
        He's definitely correct about the false positives and that nonces and/or double submitted cookies are superior, I'm not arguing that, just the 'furthermore, spoofing is extremely easy,' which makes no sense there.

by sonnym 15y ago

personalcompute 15y ago

How is spoofing the referer extremely easy? I can think of no way for an attack site to do this, short of having control over the entire user machine (or a significant browser exploit anyways), at which point all of your webapp security is irrelevant.

sonnym 15y ago
You cannot assume a request is coming from a browser. curl --referer http://www.example.come http://www.example.come http://www.example.com http://www.example.com
- personalcompute 15y ago
  Yes, but if the user wishes to avoid their own security like this, they can already do it a thousand other ways (and to no adverse affect, there is no opportunity for an attacker to exploit this, I don't know what you're getting at).
  - sonnym 15y ago
    I was merely pointing out how easy it is to fake, although you are correct a third party site could not do this. Atwood's point is that checking the "referer" will both be unreliable and, more importantly, lead to false positives; there are better alternatives, namely, double submitting cookies as I have pointed out elsewhere with regard to this article.
    - personalcompute 15y ago
      He's definitely correct about the false positives and that nonces and/or double submitted cookies are superior, I'm not arguing that, just the 'furthermore, spoofing is extremely easy,' which makes no sense there.