Thursday 14 May 2009

XSRF - Thoughts on mitigation...

Having successfully manipulated a shopping cart in an unrealistic little test using a bit of jQuery and a simple Cross Site Request Forgery, it's time to discuss some of things we can do to avoid these sorts of problems in our own web applications.

The simple things

Use get and post correctly:

GET
Requests a representation of the specified resource. Note that GET should not be used for operations that cause side-effects, such as using it for taking actions in web applications. One reason for this is that GET may be used arbitrarily by robots or crawlers, which should not need to consider the side effects that a request should cause.

POST
Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both.
From wikipedia...

I figure it's best to just do what HTTP tells me to do on this one, and not think about it for too long.


Validate all your user input


Everyone has heard it all before, no doubt, but validate all user input on the server. If you're using MS MVC, check out xVal... Useful for wiring up client-side validation from your model. If you're using web forms, do whatever you have to do, but make sure you validate.


Store your user_id in the session


And accept as few details from the user as needed. You already know how much your product costs... you don't need the user to tell you.


Check the referrer


Check the referrer and ensure the request came from your domain. If you're using MS MVC, check out this post about the AntiForgeryToken.




Anyone got any other simple things we should be doing on this one?

2 comments:

James said...

1) if you're not already validating all your user input, you've got problems much worse than XSRF.

2) Storing the User ID in the session doesn't help. A XSRF attack works because the attack passes through the browser of a user who is already authenticated for the session.

3) The referrer is easy to spoof.

Jeff Atwood's suggestions are better. http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html

Paul said...

Absolutely right fella. Jeff's suggestions give good direction.