CODEWITHSUNDEEP
ruby-on-railssecuritycsrf
fibono
fibono

Reputation: 783

CSRF Clarification (Rails)

I just wanted to clarify my understanding of CSRF attacks in Rails.

Say we have a user Peter who is signed into mainsite.com. When he comes across a like button to "like" a page (implemented as a form), then Rails generates an auth-token that is stored in the session (server-side) and also stored in the form itself. Peter presses "like", and everything works fine because the tokens match.

Now Peter, still signed in to mainsite.com, goes to evilsite.com and comes across a form that (unbeknownst to Peter) actually sends a request to mainsite.com/deleteAccount to delete Peter's account. When Peter runs into this form, there is no auth-token, so it does not match with the auth-token stored in Rails. Even if there were a hidden form to generate an auth-token, the new token would be different (hopefully) from the one already stored in Rails.

Are there any errors in my knowledge? Would love to know if there are any gaps in my understanding or what I could do to improve my understanding of CSRF attacks? Thanks!

Upvotes: 0

Views: 38

Answers (1)

Brad Werth
Brad Werth

Reputation: 17647

The Rails guides on CSRF cover this pretty well. You're pretty much correct about how it all works, except for:

Even if there were a hidden form to generate an auth-token, the new token would be different (hopefully) from the one already stored in Rails.

The rails guides specify that:

Note that cross-site scripting (XSS) vulnerabilities bypass all CSRF protections. XSS gives the attacker access to all elements on a page, so they can read the CSRF security token from a form or directly submit the form.

So basically, as long as the request comes in with a valid auth-token from the page, the default protection does not really help.

Upvotes: 1

Related Questions