25 ms·

Breaking Hacker News's CSRF Protections

13 points by heynk 13y ago

charliesome 13y ago
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.
- shuzchen 13y ago
  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.
etc_passwd 13y ago
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_(CSRF) https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(...
c4urself 13y ago
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.
psychotik 13y ago
I think you misunderstand what csrf is. Here it is in layman terms http://crazyviraj.blogspot.com/2009/10/xsrfcsrf-attacks-in-non-geek-speak.html http://crazyviraj.blogspot.com/2009/10/xsrfcsrf-attacks-in-n...
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
typicalrunt 13y ago
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.
tshadwell 13y ago
You've completely misunderstood what CSRF tokens do.

13 points by heynk 13y ago

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.

shuzchen 13y ago
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.

etc_passwd 13y ago

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_(CSRF) https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(...

c4urself 13y ago

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.

psychotik 13y ago

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

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

typicalrunt 13y ago

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.

tshadwell 13y ago

You've completely misunderstood what CSRF tokens do.