This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Anti CSRF Tokens ASP.NET"
m |
(→References) |
||
| Line 50: | Line 50: | ||
==References== | ==References== | ||
| + | [http://security.stackexchange.com/questions/22903/why-refresh-csrf-token-per-form-request Why refresh CSRF token per form request?]<br> | ||
[http://www.asp.net/mvc/overview/security/xsrfcsrf-prevention-in-aspnet-mvc-and-web-pages CSRF Prevention (official ASP.NET blog)]<br> | [http://www.asp.net/mvc/overview/security/xsrfcsrf-prevention-in-aspnet-mvc-and-web-pages CSRF Prevention (official ASP.NET blog)]<br> | ||
[http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-%28csrf%29-attacks Preventing CSRF Attacks (official ASP.NET blog)]<br> | [http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-%28csrf%29-attacks Preventing CSRF Attacks (official ASP.NET blog)]<br> | ||
Revision as of 15:50, 20 January 2015
DRAFT DOCUMENT - WORK IN PROGRESS
Description
In short, CSRF abuses the trust relationship between browser and server. This means that anything that a server uses in order to establish trust with a browser (e.g., cookies, but also HTTP/Windows Authentication) is exactly what allows CSRF to take place - but this only the first piece for a successful CSRF attack.
The second piece is a web form or request which contains parameters predictable enough that an attacker could craft his own malicious form/request which, in turn, would be successfully accepted by the target service. Then, usually through social engineering or XSS, the victim would trigger that malicious form/request submission while authenticated to the legitimate service. This is where the browser/server trust is exploited.
In order to prevent CSRF in ASP.NET, anti-forgery tokens (also known as request verification tokens) must be utilized.
These tokens are simply randomly-generated values included in any form/request that warrants protection. Note that, ideally, this value should be unique for every actual form/request, not just for every type of form/request. This guarantees that every form/request is unique and, therefore, protected from CSRF.
Mitigation Examples
Please note that the following examples may not (some certainly don't) entail a complete anti-CSRF solution for any given Web application. Specific requirements may call for adjustments and/or combinations of different strategies.
Anti-CSRF Token
ViewState
ViewState + Token
AJAX
Related Attacks
CSRF (Attack)
CSRF (Full Wikipedia Article)
XSS (Attack)
Related Vulnerabilities
XSS
Insecure Randomness
Insecure Third-Party Domain Access
Non-Cryptographic Pseudo-Random Number Generator
Related Controls
Related Technical Impacts
Accountability
Confidentiality
References
Why refresh CSRF token per form request?
CSRF Prevention (official ASP.NET blog)
Preventing CSRF Attacks (official ASP.NET blog)
Anti-CSRF and Cookies
How to protect against CSRF by default in ASP.NET MVC 4?
How does ViewState protect against CSRF?
How To Fix CSRF using Microsoft .Net ViewStateUserKey and Double Submit Cookie, by Eric Johnson and James Jardine
MSDN - Securing ViewState
MSDN - ViewStateUserKey
MSDN - HtmlHelper.AntiForgeryToken
MSDN - ValidateAntiForgeryTokenAttribute
