0

I have a pretty basic understanding of both approaches but just looking for a better explanation I guess.

I have seen some examples of CSRF attacks, using CSRF tokens, how frameworks like Ruby on Rails, Symfony2 etc have built in CSRF protection in forms. Still I somehow fail to explain someone how an attacker might inject malicious data into scripts, how would the token based approach will prevent that.

Also, even after all this an attack is possible, I read. So, how would you make it fully secure?

Ignore obscurity in my question if you notice it.

1

I think you might be misunderstanding a little. Injecting malicious data into scripts isn't really relevant to CSRF. Its sometimes used in conjunction with it, but that would more accurately describe XSS. A CSRF token wouldn't prevent something like this.

A CSRF vulnerability is when you are able to trick a user to perform some action that only they are authorized to perform, without their knowledge.

Lets say you are logged in to your banking website and there is a form to transfer money to somebody where you enter the persons account number and the amount you want to send them and then push submit.

That form will be POSTed to a particular url and the request will look something like this.

POST /transfer

Host: bankingsite.com

Cookie: xxxxxxxxx

Sendto=12345678&amount=1000

Now the application will look at your cookie to determine which account to pull the money from.

Now imagine on my website I create a form that posts to bankingsite.com/transfer that sends 1000 to my personal account and I overlay it with a "Click here to win a free iPad"

Now if you were to click on it, it would generate the same exact post request if you were logged into the banking site because your browser would determine that you have an active session with bankingsite.com and it would add your session cookie to the request.

Bankingsite.com has no idea that you didnt fill out that form on their website. They think it is a legitimate request and they proceed to transfer your money to me without your knowledge.

The problem here is that the session cookie is sent along with the request. A CSRF token is different than a session cookie because the CSRF token wont be sent along just because the destination domain matches.

So lets say you code up your banking application to send a csrf token back using a custom header when the user loads the transfer money form. Then when the user submits the transfer form, you pass along the csrf token as a hidden field and validate it on the backend before you authorize the transaction.

Now you have just made it impossible to execute the attack scenario above. If somebody clicked on that free ipad button, the request would contain the cookie and post data, but no valid csrf token because the attacker doesn't have access to it and the request would be denied.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.