Hacker News Reader

Comment by zacharyvoase | Hacker News Reader

An idea: when using session-based authentication and returning JSON, check that the Referer [sic] matches your domain. I think I'm missing something major, though.

View on HN

One elegant solution mentioned at a DNSSEC talk was to simply include your crsf token in the header of all get/post requests and have the server reject anything without said token. Assuming you'd be using some js library to do your ajax, you could make that modification in there so that you'd transparently use it without needing to modify any existing code. Only the urls that send html will not need the crsf header token.

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

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.

You cannot assume a request is coming from a browser.

curl --referer http://www.example.come http://www.example.com

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

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.

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.

Reply on news.ycombinator.com