Breaking Hacker News's CSRF Protections | Hacker News Reader

Breaking Hacker News's CSRF Protections

hankstoever.com

13 pointsheynk10 comments

CSRF protection is not about preventing bots from interacting with your site - it's about protecting your site from other sites (hence the name - cross site request forgery).

Without the hidden 'fnid' input, it would be possible for other sites to vote on and post content to Hacker News on your behalf without your consent.

More specifically, it's protecting your site from other sites taking advantage of the fact that you're already logged in. For example, in the absence of CSRF, if you're logged into HN, any other site could just embed a form element using the right input IDs, and make submissions on your behalf (clicked on this link? just made a post on your behalf. moved your mouse a little to the left? just upvoted this post).

The "hack" outlined in the article requires knowing the username and password of the person you want to "hack". Of course CSRF tokens don't protect you when your credentials are lost.

CSRF tokens are designed to protect users from CSRF attacks from other sites. The example you posted requires the username and password, which renders the token anyways. A cross-domain post to HN from a rogue site will not be able to know the CSRF token since it does not have knowledge of your SID, rendering this attack not viable in practice.

More Info: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(...

You're misunderstanding how CSRF works. Say a user is logged in to the site JoeNotProtectedByCSRF.tld with a session cookie or similar authentication token. SpammySite.tld comes along with a form to POST some change some value on JoeNotProtectedByCSRF.tld such as a password field. Because your browser always sends along the cookies to the end domain, your session cookie will be abused. With a check against a unique-to-the-user CSRF token as a hidden input on the form this doesn't happen.

I think you misunderstand what csrf is. Here it is in layman terms http://crazyviraj.blogspot.com/2009/10/xsrfcsrf-attacks-in-n...

Hopefully the author is reading this. And please spare the downvotes, I'm trying to help without laying any judgement.

Please fix the spelling in the sidebar.

Recieve a digest of my best content every month about software, startups, and life.

"Recieve" should be "Receive"

Since this is in the sidebar of your site, it stands out and puts a negative spin on the rest of what you have to say. Unfair? Maybe, but this is such a basic error that people will judge you based on such a basic mistake, simply because it will be easily caught by any spell-checker.

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.

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

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

You've completely misunderstood what CSRF tokens do.

Reply on news.ycombinator.com