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?
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.
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.
来源：https://stackoverflow.com/questions/518313/csrf-validation-token-session-id-safe