4 ms·

Thanks for pointing out what CSRF protection is meant for and I certainly agree that I should have used better wording. However, aren't the attacks mentioned (u

by heynk 13y ago

Thanks for pointing out what CSRF protection is meant for and I certainly agree that I should have used better wording. However, aren't the attacks mentioned (upvoting or similar from another site) protected by same-origin and http-only cookies? Otherwise, a malicious site could use the same techniques mentioned in this post to first obtain an fnid token and then make the same requests.

etc_passwd 13y ago
Your browser will automatically send any cookies it has for a domain when it is instructed to send a request to that domain HttpOnly cookies included. The thing preventing the malicious site from getting knowledge of your SID or your fnid token is the Same Origin Policy: https://en.wikipedia.org/wiki/Same_origin_policy https://en.wikipedia.org/wiki/Same_origin_policy. If it wasn't for the same origin policy, I could just grab your HN sid from any website with plain JS on the malicious domain. A CSRF attack is the equivalent of blind-firing a gun at a domain, and the browser "helps" you by automatically attaching your cookies to that bullet. Depending on the situation, you usually don't get a response back. Here is a good preso from when CSRF was hot back then which explains the attack scenarios: https://www.blackhat.com/presentations/bh-dc-08/Willis/Presentation/bh-dc-08-willis.pdf https://www.blackhat.com/presentations/bh-dc-08/Willis/Prese... Throwing CORS into the mix complicates things a bit but that relies on the site that is being attacked to explicitly allow calls from the malicious site or use an Access-Control-Allow-Origin: * which in itself is a security vulnerability. More details on CORS: https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS https://developer.mozilla.org/en-US/docs/HTTP/Access_control...
ejcampbell 13y ago
More specifically, it guards against another site (bad.com) building a form that submits a valid request to modify data on another site (good.com) since it's impossible for the bad.com to know the value of the token associated with the user's cookies on good.com

by heynk 13y ago

etc_passwd 13y ago

Your browser will automatically send any cookies it has for a domain when it is instructed to send a request to that domain HttpOnly cookies included. The thing preventing the malicious site from getting knowledge of your SID or your fnid token is the Same Origin Policy: https://en.wikipedia.org/wiki/Same_origin_policy https://en.wikipedia.org/wiki/Same_origin_policy. If it wasn't for the same origin policy, I could just grab your HN sid from any website with plain JS on the malicious domain. A CSRF attack is the equivalent of blind-firing a gun at a domain, and the browser "helps" you by automatically attaching your cookies to that bullet. Depending on the situation, you usually don't get a response back. Here is a good preso from when CSRF was hot back then which explains the attack scenarios: https://www.blackhat.com/presentations/bh-dc-08/Willis/Presentation/bh-dc-08-willis.pdf https://www.blackhat.com/presentations/bh-dc-08/Willis/Prese... Throwing CORS into the mix complicates things a bit but that relies on the site that is being attacked to explicitly allow calls from the malicious site or use an Access-Control-Allow-Origin: * which in itself is a security vulnerability. More details on CORS: https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS https://developer.mozilla.org/en-US/docs/HTTP/Access_control...

ejcampbell 13y ago

More specifically, it guards against another site (bad.com) building a form that submits a valid request to modify data on another site (good.com) since it's impossible for the bad.com to know the value of the token associated with the user's cookies on good.com