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"
Bill Sempf (talk | contribs) |
m |
||
| Line 3: | Line 3: | ||
==Description== | ==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... | ||
Revision as of 18:01, 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...
