Anti CSRF Tokens ASP.NET - Revision history

Bill Sempf: Promoted to production

2015-02-16T15:47:47Z

Promoted to production

Marion Nepomuceno at 20:59, 22 January 2015

2015-01-22T20:59:43Z

Marion Nepomuceno: /* AJAX */

2015-01-21T22:29:18Z

‎AJAX

Marion Nepomuceno: /* AJAX */

2015-01-21T22:28:52Z

‎AJAX

Marion Nepomuceno: /* AJAX */

2015-01-21T22:28:38Z

‎AJAX

Marion Nepomuceno: /* AJAX */

2015-01-21T22:27:43Z

‎AJAX

Marion Nepomuceno: /* References */

2015-01-21T21:48:37Z

‎References

Marion Nepomuceno: /* ViewState + Token */

2015-01-21T18:55:12Z

‎ViewState + Token

Marion Nepomuceno: /* ViewState + Token */

2015-01-21T18:54:00Z

‎ViewState + Token

Marion Nepomuceno: /* ViewState */

2015-01-21T18:42:24Z

‎ViewState

@@ Line 1: / Line 1: @@
-= 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.
@@ Line 14: / Line 12: @@
-==Mitigation Examples==
+=Mitigation Examples=
 Please note that the following examples may not entail a complete anti-CSRF solution for any given Web application. Specific requirements may call for adjustments and/or combinations of different strategies.
-===Solutions NOT considered secure===
+==Solutions NOT considered secure==
 - All of the solutions provided in this article are not designed to work with GET requests that change the server state (e.g., /example/delete.aspx?id=1). GET requests should be [https://www.wordnik.com/words/idempotent idempotent] so that CSRF cannot take place.
@@ Line 30: / Line 28: @@
 - Any CSRF protection is null and void given the presence of XSS, for several reasons. The main and obvious reason is that, through XSS, the attacker can hijack the session and spoof the user, not even having to worry about performing CSRF.
-===ASP.NET MVC and Web API: Anti-CSRF Token===
+==ASP.NET MVC and Web API: Anti-CSRF Token==
 ASP.NET has the capability to generate anti-CSRF security tokens for consumption by your application, as such:
@@ Line 50: / Line 48: @@
 [http://security.stackexchange.com/questions/22903/why-refresh-csrf-token-per-form-request Why refresh CSRF token per form request?]<br>
-===WebForms: ViewState===
+==WebForms: ViewState==
 '''Requirement:'''<br>
@@ Line 70: / Line 68: @@
 [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2 MSDN - ViewStateUserKey]<br>
-===Considerations for AJAX===
+==Considerations for AJAX==
 Depending on your application, you'll likely have to choose between using HTTP Headers or POST data to carry your anti-CSRF tokens.
@@ Line 81: / Line 79: @@
 [http://security.stackexchange.com/questions/23371/csrf-protection-with-custom-headers-and-without-validating-token CSRF Protection With Custom Headers]<br>
-==Related [[Attacks]]==
+=Related [[Attacks]]=
 [https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) CSRF (Attack)]<br>
@@ Line 88: / Line 86: @@
-==Related [[Vulnerabilities]]==
+=Related [[Vulnerabilities]]=
 [https://www.owasp.org/index.php/Cross_Site_Scripting_Flaw XSS]<br>
@@ Line 96: / Line 94: @@
-==Related [[Controls]]==
+=Related [[Controls]]=
 [https://www.owasp.org/index.php/.Net_CSRF_Guard .NET CSRF Guard]
-==Related [[Technical Impacts]]==
+=Related [[Technical Impacts]]=
 [https://www.owasp.org/index.php/Loss_of_accountability Accountability]<br>
 [https://www.owasp.org/index.php/Loss_of_confidentiality Confidentiality]
-==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>
@@ Line 119: / Line 117: @@
 [http://msdn.microsoft.com/en-us/library/system.web.mvc.validateantiforgerytokenattribute%28v=vs.100%29.aspx MSDN - ValidateAntiForgeryTokenAttribute]<br>
-[[Category:OWASP .NET Project]][[Category:Stub]]
+[[Category:OWASP .NET Project]]

@@ Line 9: / Line 9: @@
 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.
+These tokens are simply randomly-generated values included in any form/request that warrants protection. Note that this value should be unique for every individual session. This guarantees that every form/request is tied to the authenticated user and, therefore, protected from CSRF.
@@ Line 17: / Line 19: @@
 ===Solutions NOT considered secure===
 - Assuming that SSL/TLS will thwart CSRF attacks just because the cookie is marked "Secure" and/or "HTTPOnly". The problem lies in the trust between legitimate browser and server. Therefore, the browser will just send its current cookies when the forged request is triggered. The attacker never has to touch any cookies.
@@ Line 26: / Line 30: @@
 - Any CSRF protection is null and void given the presence of XSS, for several reasons. The main and obvious reason is that, through XSS, the attacker can hijack the session and spoof the user, not even having to worry about performing CSRF.
-===Anti-CSRF Token===
+===ASP.NET MVC and Web API: Anti-CSRF Token===
 ASP.NET has the capability to generate anti-CSRF security tokens for consumption by your application, as such:
@@ Line 39: / Line 43: @@
 For implementation details, see:<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 MVC 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 Web API CSRF Prevention (official ASP.NET blog)]<br>
-You may consider making a new security token for every new request, rather than session:<br>
+The standard frequency of token generation is '''per-session''', so make sure your sessions have a reasonable/configurable '''time-out'''.
 [http://security.stackexchange.com/questions/22903/why-refresh-csrf-token-per-form-request Why refresh CSRF token per form request?]<br>
-===ViewState===
+===WebForms: ViewState===
 '''Requirement:'''<br>
 [https://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic5 EnableViewStateMac] must be set.<br>
-The ASP.NET ViewState contains a property, [https://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2 ViewStateUserKey], which can offer protection against CSRF.
+The ASP.NET ViewState contains a property, [https://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2 ViewStateUserKey], which offers protection against CSRF by adding uniqueness to the ViewState MAC as long as you set it to a new value for every session.
-When enabling CSRF protection through the ViewState, the aim is to make the ViewState always unique per user session, serving as a kind of CSRF token. That's where MAC and the ViewStateUserKey come together.
+Note that ViewStateUserKey will not actually add a new value to the ViewState, but rather simply influence the MAC process so as to make every MAC unique per user session. Therefore, setting ViewStateUserKey to the current Session ID is acceptable.
-EnableViewStateMac, when off, obviously performs no checks. When enabled, it will only perform tampering checks. Therefore, an attacker could obtain a valid (but unchanging) ViewState and still perform CSRF.
+Since Visual Studio 2012, the anti-CSRF mechanism has been improved.
-The ViewStateUserKey can add uniqueness to the equation if you set it to a new value for every session.
+The new strategy still uses the ViewState as the main entity for CSRF protection but also makes use of tokens (which you can generate as GUIDs) so that you can set the ViewStateUserKey to the token rather than the Session ID, and then validate it against the cookie.
-Setting ViewStateUserKey to the current Session ID is acceptable (again, when EnableViewStateMac is on).
+Here's a [http://software-security.sans.org/developer-how-to/developer-guide-csrf blog post by Eric Johnson and James Jardine] with an example of this implementation.
-For implementation details, see:<br>
+For more implementation details, see:<br>
 [http://msdn.microsoft.com/en-us/library/ms178199%28v=vs.85%29.aspx MSDN - Securing ViewState]<br>
 [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2 MSDN - ViewStateUserKey]<br>
-For an extra secure approach when using ViewState, see the section below.
+===Considerations for AJAX===
-===ViewState + Token===
+Depending on your application, you'll likely have to choose between using HTTP Headers or POST data to carry your anti-CSRF tokens.
 Whatever you choose, the optimal validation method is indeed through tokens.
-This means you can follow the strategy outlined in the first section, "Anti-CSRF Token", while creating either a '''custom''' header to hold the token value or just sending the token with the rest of the POST data.
+This means you can follow the token strategy while creating either a '''custom''' header to hold the token value or just sending the token with the rest of the POST data.
 For more guidance, see the '''answers''' given to the following questions:<br>
 [http://stackoverflow.com/questions/8253396/anti-csrf-cookie Anti-CSRF Cookie]<br>
 [http://security.stackexchange.com/questions/23371/csrf-protection-with-custom-headers-and-without-validating-token CSRF Protection With Custom Headers]<br>
 ==Related [[Attacks]]==

@@ Line 83: / Line 83: @@
 Whatever you choose, the optimal validation method is indeed through tokens.
-This means you can follow the strategy outlined in the first section, "Anti-CSRF Token", while creating either a custom header to hold the token value or just sending the token with the rest of the POST data.
+This means you can follow the strategy outlined in the first section, "Anti-CSRF Token", while creating either a '''custom''' header to hold the token value or just sending the token with the rest of the POST data.
 For more guidance, see the '''answers''' given to the following questions:<br>

@@ Line 83: / Line 83: @@
 Whatever you choose, the optimal validation method is indeed through tokens.
-This means you can follow the strategy outlined in the first section, "Anti-CSRT Token", while creating either a custom header to hold the token value or just sending the token with the rest of the POST data.
+This means you can follow the strategy outlined in the first section, "Anti-CSRF Token", while creating either a custom header to hold the token value or just sending the token with the rest of the POST data.
 For more guidance, see the '''answers''' given to the following questions:<br>

@@ Line 83: / Line 83: @@
 Whatever you choose, the optimal validation method is indeed through tokens.
-This means you can follow the strategy outlined in the first section, "ASP.NET Tokens", while creating either a custom header to hold the token value or just sending the token with the rest of the POST data.
+This means you can follow the strategy outlined in the first section, "Anti-CSRT Token", while creating either a custom header to hold the token value or just sending the token with the rest of the POST data.
 For more guidance, see the '''answers''' given to the following questions:<br>

← Older revision		Revision as of 22:27, 21 January 2015
Line 79:		Line 79:

	===AJAX===		===AJAX===
		+
		+	Depending on your application, you'll likely have to choose between using HTTP Headers or POST data (or both!) to carry your anti-CSRF tokens.
		+
		+	Whatever you choose, the optimal validation method is indeed through tokens.
		+	This means you can follow the strategy outlined in the first section, "ASP.NET Tokens", while creating either a custom header to hold the token value or just sending the token with the rest of the POST data.
		+
		+	For more guidance, see the '''answers''' given to the following questions:<br>
		+	[http://stackoverflow.com/questions/8253396/anti-csrf-cookie Anti-CSRF Cookie]<br>
		+	[http://security.stackexchange.com/questions/23371/csrf-protection-with-custom-headers-and-without-validating-token CSRF Protection With Custom Headers]<br>
		+
		+	<MN: it seems to me that using the ViewState (rather than tokens) with XHRs is not optimal, but could probably be done. Should I mention anything about that? I doubt anyone even does that.>

	==Related [[Attacks]]==		==Related [[Attacks]]==

@@ Line 112: / Line 112: @@
 [http://security.stackexchange.com/questions/19152/how-does-viewstate-protect-against-csrf How does ViewState protect against CSRF?]<br>
 [http://software-security.sans.org/developer-how-to/developer-guide-csrf How To Fix CSRF using Microsoft .Net ViewStateUserKey and Double Submit Cookie, by Eric Johnson and James Jardine]<br>
 [http://msdn.microsoft.com/en-us/library/ms178199%28v=vs.85%29.aspx MSDN - Securing ViewState]<br>
 [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2 MSDN - ViewStateUserKey]<br>

← Older revision		Revision as of 18:55, 21 January 2015
Line 75:		Line 75:

	This gives you the flexibility to choose whether to refresh tokens per request or per session while adding additional defensive layers to your strategy.		This gives you the flexibility to choose whether to refresh tokens per request or per session while adding additional defensive layers to your strategy.
		+
		+	Here's a [http://software-security.sans.org/developer-how-to/developer-guide-csrf blog post by Eric Johnson and James Jardine] with an example of this implementation.

	===AJAX===		===AJAX===

← Older revision		Revision as of 18:54, 21 January 2015
Line 67:		Line 67:

	===ViewState + Token===		===ViewState + Token===
		+
		+	The Token approach and the ViewState approach are not mutually exclusive.
		+
		+	This hybrid strategy still uses the ViewState as the main entity for CSRF protection. Keep in mind, however, that you're not constrained to setting [http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2 ViewStateUserKey] to the current Session ID.
		+
		+	By generating and validating tokens with [http://msdn.microsoft.com/en-us/library/dd470175%28v=vs.100%29.aspx HtmlHelper.AntiForgeryToken] and [http://msdn.microsoft.com/en-us/library/system.web.mvc.validateantiforgerytokenattribute%28v=vs.100%29.aspx ValidateAntiForgeryTokenAttribute] (see [http://www.asp.net/mvc/overview/security/xsrfcsrf-prevention-in-aspnet-mvc-and-web-pages CSRF Prevention]), you can set the ViewStateUserKey to the token rather than the Session ID.
		+
		+	This gives you the flexibility to choose whether to refresh tokens per request or per session while adding additional defensive layers to your strategy.

	===AJAX===		===AJAX===

← Older revision		Revision as of 18:42, 21 January 2015
Line 46:		Line 46:

	===ViewState===		===ViewState===
		+
		+	'''Requirement:'''<br>
		+	[https://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic5 EnableViewStateMac] must be set.<br>
		+
		+	The ASP.NET ViewState contains a property, [https://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2 ViewStateUserKey], which can offer protection against CSRF.
		+
		+	When enabling CSRF protection through the ViewState, the aim is to make the ViewState always unique per user session, serving as a kind of CSRF token. That's where MAC and the ViewStateUserKey come together.
		+
		+	EnableViewStateMac, when off, obviously performs no checks. When enabled, it will only perform tampering checks. Therefore, an attacker could obtain a valid (but unchanging) ViewState and still perform CSRF.
		+
		+	The ViewStateUserKey can add uniqueness to the equation if you set it to a new value for every session.
		+
		+	Setting ViewStateUserKey to the current Session ID is acceptable (again, when EnableViewStateMac is on).
		+
		+	For implementation details, see:<br>
		+	[http://msdn.microsoft.com/en-us/library/ms178199%28v=vs.85%29.aspx MSDN - Securing ViewState]<br>
		+	[http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2 MSDN - ViewStateUserKey]<br>
		+
		+	For an extra secure approach when using ViewState, see the section below.

	===ViewState + Token===		===ViewState + Token===