I was recently reading on CSRF attacks and how Rails protects against them, and there's something I'm not understanding and can't find an explanation to.
From what I understand from Nvisium's blog post, The official guides' and This valuable video is that Rails protects against CSRF attacks by:
- Embedding an
authenticity_token
into each form - Upon processing a POST request, comparing the value of the submitted token with the one associated in the user's session.
What I don't understand though is:
Since the authenticity_token
is a publicly available value that can't be accessed by simply inspecting a web page, how is this protection, when the attacker can simply copy this value and insert it into the malicious form he/she is creating.
Of course my instinct is telling me it's more complicated than this, but I just can't find any explanation as to how the scenario above is avoided. IF you have an explanation or know any sources that shed light on this, I would be really grateful
CodePudding user response:
The authenticity_token
ensures that any submission your app receives matches a session that the app knows about. It doesn't help against someone who's conducting a man-in-the-middle attack, but does help against people randomly spamming your app with subimssions. It doesn't stop a legitimate but malicious user from sending data to your app, only people who've not followed your app path.
Basically, this protection is for the server, not the client. It's not by any means a total protection against attacks, but does close off one avenue of attack.
CodePudding user response:
I think the important part JohnP mentioned is it "only prevents requests which not followed your app path".
So imagine somebody sends you an email with a link to upvote a Stackoverflow post with a description like Click here for money. You click on this link and without CSRF, this link you would actually upvote this post. But this does not work with CSRF prevention because the request is lacking the random token and will get rejected.
Upvoting is of course just a harmless example but it could leak data, change of session state, or manipulation of an end user's account.