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 |
m |
||
Line 18: | Line 18: | ||
==Related [[Attacks]]== | ==Related [[Attacks]]== | ||
+ | |||
+ | [https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)] | ||
+ | [https://en.wikipedia.org/wiki/Cross-site_request_forgery] | ||
+ | [https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)] | ||
==Related [[Vulnerabilities]]== | ==Related [[Vulnerabilities]]== | ||
+ | |||
+ | [https://www.owasp.org/index.php/Cross_Site_Scripting_Flaw] | ||
+ | [https://www.owasp.org/index.php/Failure_of_true_random_number_generator] | ||
+ | [https://www.owasp.org/index.php/Insecure_Randomness] | ||
+ | [https://www.owasp.org/index.php/Insecure_Third_Party_Domain_Access] | ||
+ | [https://www.owasp.org/index.php/Non-cryptographic_pseudo-random_number_generator] | ||
==Related [[Controls]]== | ==Related [[Controls]]== | ||
+ | [https://www.owasp.org/index.php/.Net_CSRF_Guard] | ||
==Related [[Technical Impacts]]== | ==Related [[Technical Impacts]]== | ||
+ | [https://www.owasp.org/index.php/Loss_of_accountability] | ||
+ | [https://www.owasp.org/index.php/Loss_of_confidentiality] | ||
==References== | ==References== | ||
− | + | [http://www.asp.net/mvc/overview/security/xsrfcsrf-prevention-in-aspnet-mvc-and-web-pages] | |
+ | [http://stackoverflow.com/questions/8253396/anti-csrf-cookie] | ||
[[Category:OWASP .NET Project]][[Category:Stub]] | [[Category:OWASP .NET Project]][[Category:Stub]] |
Revision as of 18:32, 15 August 2014
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 (most often cookies, but also HTTP or even 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 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
Coming soon...
Related Attacks
Related Vulnerabilities
Related Controls
Related Technical Impacts