

Breaking Hacker News's CSRF Protections - heynk
http://hankstoever.com/posts/9-Breaking-Hacker-Newss-CSRF-Protections

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

------
c4urself
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
I think you misunderstand what csrf is. Here it is in layman terms
[http://crazyviraj.blogspot.com/2009/10/xsrfcsrf-attacks-
in-n...](http://crazyviraj.blogspot.com/2009/10/xsrfcsrf-attacks-in-non-geek-
speak.html)

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

------
heynk
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
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/Prese...](https://www.blackhat.com/presentations/bh-
dc-08/Willis/Presentation/bh-dc-08-willis.pdf)

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...](https://developer.mozilla.org/en-
US/docs/HTTP/Access_control_CORS)

------
tshadwell
You've completely misunderstood what CSRF tokens do.

