views:

869

answers:

3

In asp.net I am implementing an IHttpModule to mitigate CSRF attacks. It injects into the response html a hidden form parameter with the asp.net SessionID on GETs. On POSTs it then checks to make sure that hidden parameter's value matches the current SessionID. As far as I know, the only way to get the SessionID value is from the cookie, which couldn't be read or determined by the malicious site. Is there anything I am overlooking?

+3  A: 

Ideally you would want to use something other than session id, but basically that's it. OWASP suggests using a random form element name that is stored in the user's session. This way an attacker wouldn't even be able to forge the correct hidden field.

http://www.owasp.org/index.php/Top_10_2007-A5#Protection

Andy
Randomizing the form element name is an interesting idea. Thanks for the link.
ironsam
+3  A: 

This approach is correct. You need to make sure that all of the actions available via a GET operation are "safe" (which is best practice anyway), since you're applying your XSRF protection to POSTs only.

For extra insurance, you could use it on GETs too (by adding a URL parameter to all of your links, and checking for it in every GET request), but it's cumbersome.

If you are extra paranoid, you can choose a different random number for the alternate ID. This would protect you even if a browser incorrectly makes your session cookie accessible to some hostile Javascript on another site. When a session is created, choose another big random number and store it in your session.

erickson
I probably won't worry about the GETs for now, since it's not valid (but obviously possible) for http to change state with them. As long as we keep that convention/standard, we should be fine. I may look into using a value other than the SessionID for extra security like you mentioned - thanks.
ironsam
+1  A: 

I haven't tried it, but this module seems to do what you want.

http://www.codeplex.com/AntiCSRF

Greg
Thanks, I'll check out how they went about it.
ironsam