Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T14:02:19Z

Point to the official site

Thunder-Son: Migration to GitHub

2019-02-14T10:58:50Z

Migration to GitHub

Show changes

Manideepk: /* Content-Type Header Validation */ adding riyaz article

2019-02-08T01:16:04Z

‎Content-Type Header Validation: adding riyaz article

Manideepk: Reverting back changes

2019-02-07T23:37:36Z

Reverting back changes

Wichers: /* Not a Simple HTTP Request Verification */

2019-02-07T23:28:10Z

‎Not a Simple HTTP Request Verification

Wichers at 22:52, 6 February 2019

2019-02-06T22:52:16Z

Wichers: Eliminate some unnecessary content, move some later in the article.

2019-02-06T21:36:24Z

Eliminate some unnecessary content, move some later in the article.

Wichers: /* Triple Submit Cookie */

2019-01-23T23:24:23Z

‎Triple Submit Cookie

Wichers at 23:18, 23 January 2019

2019-01-23T23:18:31Z

Wichers at 23:01, 23 January 2019

2019-01-23T23:01:47Z

Show changes

← Older revision		Revision as of 14:02, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://~~github~~.~~com/OWASP/CheatSheetSeries/blob/master~~/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet] to see the latest version of the cheat sheet.	+	Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet] to see the latest version of the cheat sheet.

← Older revision		Revision as of 01:16, 8 February 2019
Line 240:		Line 240:

	This approach has two main problems. One that it would mandate all requests to have a header value that would force pre-flight despite the real use case and the other that this technique is relying on a feature that is not designed for security, to mitigate a security vulnerability. When a bug was discovered in the Chrome API, browser architects even considered to removing this pre-flighting behavior. Because this header was not designed as a security control, architects can re-design it to better cater its primary purpose. In the future, there’s a possibility that new content-type header types can be included (to better support various use-cases), which can put systems relying on this header for CSRF mitigation in trouble. For more information, see [https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2017/september/common-csrf-prevention-misconceptions/ Common CSRF Prevention Misconceptions].		This approach has two main problems. One that it would mandate all requests to have a header value that would force pre-flight despite the real use case and the other that this technique is relying on a feature that is not designed for security, to mitigate a security vulnerability. When a bug was discovered in the Chrome API, browser architects even considered to removing this pre-flighting behavior. Because this header was not designed as a security control, architects can re-design it to better cater its primary purpose. In the future, there’s a possibility that new content-type header types can be included (to better support various use-cases), which can put systems relying on this header for CSRF mitigation in trouble. For more information, see [https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2017/september/common-csrf-prevention-misconceptions/ Common CSRF Prevention Misconceptions].
		+
		+	[https://blog.appsecco.com/exploiting-csrf-on-json-endpoints-with-flash-and-redirects-681d4ad6b31b This] article by Riyaz Walikar also talks about how this type of content-type header validation can be vulnerable to FLASH based re-direct attacks (as discussed in section 5.7, use of custom request headers)

	== CSRF Mitigation Myths ==		== CSRF Mitigation Myths ==

@@ Line 112: / Line 112: @@
 We recommend researching if the framework you are using has an option to achieve CSRF protection by default before trying to build your custom auto tokening system. For example, .NET has an [https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-2.1 in-built protection] that adds token to CSRF vulnerable resources. You are responsible for proper configuration (such as key management and token management) before using these in-built CSRF protections that do auto tokening to CSRF vulnerable resources.
-=== Stateless/Tokenless Defense Techniques ===
+=== Defense-In-Depth Techniques ===
 === Verifying origin with standard headers ===

@@ Line 129: / Line 129: @@
 ==== Not a Simple HTTP Request Verification ====
-A Simple HTTP Request is described, but not given this actual name, in the W3C CORS spec: [https://www.w3.org/TR/cors/#terminology]. We define a Simple HTTP Request to be a request that uses both a 'simple method' and has a 'simple header'. This W3C article defines a simple method as any of these three: GET, HEAD, POST, and also defines a simple header as one of these four: Accept, Accept-Language, Content-Language, Content-Type. However, the Content-Type header, if present, must also have a value of: application/x-www-form-urlencoded, multipart/form-data, or text/plain. It further defines, not very succinctly, at the beginning of section 7.5.1 Cross-Origin Request with Preflight - Step 1. [https://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0] that a CORS preflight request is required for cross-origin requests UNLESS the request uses a simple method with simple headers. Meaning, that the ONLY cross-origin requests allowed by browsers (without requesting permission using CORS) are 'Simple HTTP Requests'.
+A Simple HTTP Request is described, but not given this actual name, in the [https://www.w3.org/TR/cors/#terminology W3C CORS spec]. We define a Simple HTTP Request to be a request that uses both a 'simple method' and has a 'simple header'. This W3C article defines a simple method as any of these three: GET, HEAD, POST, and also defines a simple header as one of these four: Accept, Accept-Language, Content-Language, Content-Type. However, the Content-Type header, if present, must also have a value of: application/x-www-form-urlencoded, multipart/form-data, or text/plain. It further defines, not very succinctly, at the beginning of [https://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0 section 7.5.1 Cross-Origin Request with Preflight - Step 1] that a CORS preflight request is required for cross-origin requests UNLESS the request uses a simple method with simple headers. Meaning, that the ONLY cross-origin requests allowed by browsers (without requesting permission using CORS) are 'Simple HTTP Requests'.
 We can take advantage of this knowledge by simply verifying that all state changing requests to our application are NOT Simple HTTP Requests. And if they are not, then they can't be a CSRF attack. If you've built your application properly, then GET and HEAD requests cannot change state, so that leaves us with POSTs. If you then verify that all POST requests include a Content-Type header, whose value is either NOT any of the three allowed to go cross origin (application/x-www-form-urlencoded, multipart/form-data, or text/plain), or is an explicitly required Content-Type that is NOT one of those three, then you are all set.
@@ Line 135: / Line 135: @@
 For example, if have a pure AJAX app that submits all of it's POST requests with Content-Types of application/xml or application/json, and you verify on the server side that all POSTs include a Content-Type with one of those two values, your app is completely defended against CSRF attacks. If your application also happens to accept other HTTP methods that do state changing things, like PUT, DELETE, etc. you don't have to do anything to defend those endpoints because browsers can't generate anything but Simple HTTP Requests cross-origin (i.e., GET, HEAD, or POST only). If you need to accept the uploading of files (multipart/form-data), explicit CSRF protection is still needed for those endpoints.
-Acknowledgement: This Simple HTTP Request verification technique was found in: [https://blog.jdriven.com/2014/10/stateless-spring-security-part-1-stateless-csrf-protection/], where it explicitly stated "Stateless approach 1: SWITCH TO A FULL AND PROPERLY DESIGNED JSON BASED REST API. - Single-Origin Policy only allows cross-site HEAD/GET and POSTs. POSTs may only be one of the following mime-types: application/x-www-form-urlencoded, multipart/form-data, or text/plain. Indeed no JSON! Now considering GETs should never ever trigger side-effects in any properly designed HTTP based API, this leaves it up to you to simply disallow any non-JSON POST/PUT/DELETEs and all is well."
+Acknowledgement: This Simple HTTP Request verification technique was found in this [https://blog.jdriven.com/2014/10/stateless-spring-security-part-1-stateless-csrf-protection/ Stateless CSRF Protection blog post], where it explicitly stated "Stateless approach 1: SWITCH TO A FULL AND PROPERLY DESIGNED JSON BASED REST API. - Single-Origin Policy only allows cross-site HEAD/GET and POSTs. POSTs may only be one of the following mime-types: application/x-www-form-urlencoded, multipart/form-data, or text/plain. Indeed no JSON! Now considering GETs should never ever trigger side-effects in any properly designed HTTP based API, this leaves it up to you to simply disallow any non-JSON POST/PUT/DELETEs and all is well."
 == Defense-In-Depth Techniques ==

@@ Line 29: / Line 29: @@
 == CSRF Defense Recommendations Summary ==
-We recommend token based CSRF defense (either stateful/stateless) as a primary defense to mitigate CSRF in your applications. For highly sensitive operations, we also recommend user interaction based protection (either re-authentication/one-time token, detailed in sectio 6.5) along with token based mitigation.
+We recommend token based CSRF defense (either stateful/stateless) as a primary defense to mitigate CSRF in your applications. For highly sensitive operations, we also recommend user interaction based protection (either re-authentication/one-time token, detailed in section 6.5) along with token based mitigation.
 As a defense-in-depth measure, consider implementing one mitigation from the Defense-in-Depth Techniques section (you can choose the mitigation that fits your ecosystem considering the issues mentioned under them). These defense-in-depth mitigation techniques are not recommended to be used by themselves (without token based mitigation) for mitigating CSRF in your applications.
@@ Line 111: / Line 111: @@
 * Get the tokens automatically added on the client side when the page is being rendered in user’s browser, with help of a client side script (this approach is used by [[CSRF Guard]]). You need to consider any possible JavaScript hijacking attacks.
 We recommend researching if the framework you are using has an option to achieve CSRF protection by default before trying to build your custom auto tokening system. For example, .NET has an [https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-2.1 in-built protection] that adds token to CSRF vulnerable resources. You are responsible for proper configuration (such as key management and token management) before using these in-built CSRF protections that do auto tokening to CSRF vulnerable resources.
 == Defense-In-Depth Techniques ==

@@ Line 14: / Line 14: @@
 Impacts of successful CSRF exploits vary greatly based on the privileges of each victim. When targeting a normal user, a successful CSRF attack can compromise end-user data and their associated functions. If the targeted end user is an administrator account, a CSRF attack can compromise the entire web application. Using social engineering, an attacker can embed malicious HTML or JavaScript code into an email or website to request a specific 'task URL'. The task then executes with or without the user's knowledge, either directly or by using a Cross-Site Scripting flaw. For example, see [https://en.wikipedia.org/wiki/Samy_(computer_worm) Samy MySpace Worm].
 ==Warning: No Cross-Site Scripting (XSS) Vulnerabilities ==
@@ Line 23: / Line 20: @@
 It is imperative that no XSS vulnerabilities are present to ensure that CSRF defenses can't be circumvented. Please see the OWASP [[XSS (Cross Site Scripting) Prevention Cheat Sheet|XSS Prevention Cheat Sheet]] for detailed guidance on how to prevent XSS flaws.
-== Resources that need to be protected from CSRF vulnerability ==
+== Resources that need to be protected from CSRF attacks ==
 The following list assumes that you are not violating [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 RFC2616], section 9.1.1, by using GET requests for state changing operations.
@@ Line 32: / Line 29: @@
 == CSRF Defense Recommendations Summary ==
-We recommend token based CSRF defense (either stateful/stateless) as a primary defense to mitigate CSRF in your applications. Only for highly sensitive operations, we also recommend a user interaction based protection (either re-authentication/one-time token, detailed in section 7.5) along with token based mitigation.
+We recommend token based CSRF defense (either stateful/stateless) as a primary defense to mitigate CSRF in your applications. For highly sensitive operations, we also recommend user interaction based protection (either re-authentication/one-time token, detailed in sectio 6.5) along with token based mitigation.
 As a defense-in-depth measure, consider implementing one mitigation from the Defense-in-Depth Techniques section (you can choose the mitigation that fits your ecosystem considering the issues mentioned under them). These defense-in-depth mitigation techniques are not recommended to be used by themselves (without token based mitigation) for mitigating CSRF in your applications.
@@ Line 39: / Line 36: @@
 === Token Based Mitigation ===
-This defense is one the most popular and recommended methods to mitigate CSRF. It can be achieved either with state (synchronizer token pattern) or stateless (encrypted/hash based token pattern). See section 6.3 on how to mitigate login CSRF in your applications. For all the mitigation's, it is implicit that general security principles should be adhered
+This defense is one the most popular and recommended methods to mitigate CSRF. It can be achieved either with state (synchronizer token pattern) or stateless (encrypted/hash based token pattern). For all the mitigation's, it is implicit that general security principles should be adhered.
-* Strong encryption/HMAC functions should be adhered to.
+* Strict key rotation and token lifetime policies should be maintained. Policies can be set according to your organizational needs. Generic key management guidance from OWASP can be found in the [[Key Management Cheat Sheet]].
 ==== Synchronizer Token Pattern ====
@@ Line 94: / Line 89: @@
 On successful token-decryption, the server has access to parsed values, ideally in the form of [http://en.wikipedia.org/wiki/Claims-based_identity claims]. These claims are processed by comparing the UserId claim to any potentially stored UserId (in a Cookie or Session variable, if the site already contains a means of authentication). The Timestamp is validated against the current time, preventing replay attacks. Alternatively, in the case of a CSRF attack, the server will be unable to decrypt the poisoned token, and can block and log the attack.
-This technique addresses some of the shortfalls in other stateless approaches, such as the need to store data in a Cookie, circumventing the Cookie-subdomain and [[HttpOnly]] issues.
+This technique addresses some of the shortfalls in other stateless approaches, such as the need to store data in a Cookie, circumventing the Cookie-subdomain and [[HttpOnly]] issues. Your solution should use a strong encryption function. We recommend AES256-GCM or stronger.
 ==== HMAC Based Token Pattern ====
-[https://en.wikipedia.org/wiki/HMAC HMAC (hash-based message authentication code)] is a cryptographic function that helps to guarantee integrity and authentication of a message. It is another way that CSRF mitigation can be achieved without maintaining any state at the server and is similar to an encryption token-based pattern with two main differences:
+[https://en.wikipedia.org/wiki/HMAC HMAC (hash-based message authentication code)] is a cryptographic function that helps to guarantee integrity and authentication of a message. HMAC Tokens can be used as a CSRF mitigation technique without requiring server side state. It is similar to the encryption token-based pattern with two main differences:
 * Uses a strong HMAC function instead of an encryption function to generate the token
 * Includes an additional field called ‘operation’ that would indicate the purpose of the operation for which you are including the CSRF token (may it be form tag/ajax call)
@@ Line 107: / Line 102: @@
 Generate the token using HMAC including all four fields mentioned previously (user's ID, a timestamp value, nonce, and operation) and then include it in hidden fields for form tags, headers/parameters for ajax calls. Once you receive the HMAC from the client in the requests, re-generate HMAC with the same fields that you used to generate it, and then verify that the HMAC you re-generated matches the HMAC received from the client. If it does, it is a legitimate user request and if it does not, flag it as a CSRF intrusion and alert your incident response teams. Because an attacker has no visibility into the key used for generating the hash fields used in generating it, there is no way for them to re-generate it to use in forged request.
 === Auto CSRF Mitigation Techniques ===
@@ Line 114: / Line 111: @@
 * Get the tokens automatically added on the client side when the page is being rendered in user’s browser, with help of a client side script (this approach is used by [[CSRF Guard]]). You need to consider any possible JavaScript hijacking attacks.
 We recommend researching if the framework you are using has an option to achieve CSRF protection by default before trying to build your custom auto tokening system. For example, .NET has an [https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-2.1 in-built protection] that adds token to CSRF vulnerable resources. You are responsible for proper configuration (such as key management and token management) before using these in-built CSRF protections that do auto tokening to CSRF vulnerable resources.
 == Defense-In-Depth Techniques ==
@@ Line 233: / Line 221: @@
 * CAPTCHA
 While these are a very strong CSRF defense, it does create a huge impact on the user experience. For applications that are in need of high security for some operations (password change, money transfer etc.), these techniques should be used along with token based mitigation. Please note that tokens by themselves can mitigate CSRF, developers should use these techniques only to achieve additional security for their high sensitive operations.
 == Not So Popular CSRF Mitigations ==
@@ Line 250: / Line 247: @@
 * More myths can be found [[Cross-Site Request Forgery (CSRF)|here]]
 == Implementation reference example  ==
 The following JEE web filter provides an example reference for some of the concepts described in this cheat sheet. It implements the following stateless mitigations ([https://github.com/aramrami/OWASP-CSRFGuard OWASP CSRFGuard], cover a stateful approach).

@@ Line 237: / Line 237: @@
 === Triple Submit Cookie ===
-This mitigation is proposed by John Wilander in 2012 at OWASP Appsec Research. This technique adds an additional step to double submit cookie approach by verifying if the request contains two cookies with same name (please note, attacker need to write an additional cookie to bypass double submit cookie mitigation). Though it mitigates the issues discussed in bypass of double submit cookie, it introduces new problems such as cookie jar overflow (in-details and more issue details [https://media.blackhat.com/eu-13/briefings/Lundeen/bh-eu-13-deputies-still-confused-lundeen-wp.pdf here] and [https://webstersprodigy.net/2012/08/03/analysis-of-john-wilanders-triple-submit-cookies/ here]). We were not able to find any real-time implementations of this mitigation so far.
+This mitigation is proposed by [https://www.owasp.org/images/e/e6/AppSecEU2012_Wilander.pdf John Wilander in 2012 at OWASP Appsec Research]. This technique adds an additional step to double submit cookie approach by verifying if the request contains two cookies with same name (please note, attacker need to write an additional cookie to bypass double submit cookie mitigation). Though it mitigates the issues discussed in bypass of double submit cookie, it introduces new problems such as cookie jar overflow (in-details and more issue details [https://media.blackhat.com/eu-13/briefings/Lundeen/bh-eu-13-deputies-still-confused-lundeen-wp.pdf here] and [https://webstersprodigy.net/2012/08/03/analysis-of-john-wilanders-triple-submit-cookies/ here]). We were not able to find any real-time implementations of this mitigation so far.
 === Content-Type Header Validation ===

@@ Line 16: / Line 16: @@
 == What's new? ==
-If you have seen OWASP [https://www.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&action=history old CSRF prevention cheat sheets], you can observe that a lot has changed in this newer version. One of the major changes is that the “Verifying same origin with standard headers” CSRF defense has been moved to the Defense in Depth section, whereas token based mitigation moved to the Primary Defense section (technical reasons for this switch were added under respective sections). Multiple new sections (HMAC based token protection, auto CSRF mitigation techniques, login CSRF, not so popular CSRF mitigations and CSRF mitigation myths) were added besides adding new content, removing obsolete content to the existing sections. Security issues/caveats associated with each mitigation were also included.
+If you have seen OWASP [https://www.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&action=history old CSRF prevention cheat sheets], you can observe that a lot has changed in this newer version. One of the major changes is that the “Verifying same origin with standard headers” CSRF defense has been moved to the Defense-in-Depth section, whereas token based mitigation moved to the Primary Defenses section (technical reasons for this switch were added under respective sections). Multiple new sections (HMAC based token protection, auto CSRF mitigation techniques, login CSRF, not so popular CSRF mitigations and CSRF mitigation myths) were added besides adding new content, removing obsolete content to the existing sections. Security issues/caveats associated with each mitigation were also included.
 ==Warning: No Cross-Site Scripting (XSS) Vulnerabilities ==
@@ Line 34: / Line 34: @@
 We recommend token based CSRF defense (either stateful/stateless) as a primary defense to mitigate CSRF in your applications. Only for highly sensitive operations, we also recommend a user interaction based protection (either re-authentication/one-time token, detailed in section 7.5) along with token based mitigation.
-As a defense-in-depth measure, consider implementing one mitigation from Defense in Depth Mitigations section (you can choose the mitigation that fits your ecosystem considering the issues mentioned under them). These defense-in-depth mitigation techniques are not recommended to be used by themselves (without token based mitigation) for mitigating CSRF in your applications.
+As a defense-in-depth measure, consider implementing one mitigation from the Defense-in-Depth Techniques section (you can choose the mitigation that fits your ecosystem considering the issues mentioned under them). These defense-in-depth mitigation techniques are not recommended to be used by themselves (without token based mitigation) for mitigating CSRF in your applications.
-== Primary Defense Technique ==
+== Primary Defense Techniques ==
 === Token Based Mitigation ===
-This defense is one the most popular and recommended methods to mitigate CSRF. It can be achieved either with state (synchronizer token pattern) or stateless (encrypted/hash based token pattern). See section 4.3 on how to mitigate login CSRF in your applications. For all the mitigation's, it is implicit that general security principles should be adhered
+This defense is one the most popular and recommended methods to mitigate CSRF. It can be achieved either with state (synchronizer token pattern) or stateless (encrypted/hash based token pattern). See section 6.3 on how to mitigate login CSRF in your applications. For all the mitigation's, it is implicit that general security principles should be adhered
 * Strong encryption/HMAC functions should be adhered to.
 '''Note:''' You can select any algorithm per your organizational needs. We recommend AES256-GCM for encryption and SHA256/512 for HMAC.
@@ Line 122: / Line 122: @@
 Login CSRF can be mitigated by creating pre-sessions (sessions before a user is authenticated) and including tokens in login form. You can use any of the techniques mentioned above to generate tokens. Pre-sessions can be transitioned to real sessions once the user is authenticated. This technique is described in [https://seclab.stanford.edu/websec/csrf/csrf.pdf Robust Defenses for Cross-Site Request Forgery section 4.1].
-If sub-domains under your master domain are treated as not trusty in your threat model, it is difficult to mitigate login CSRF. A strict subdomain and path level referer header (because most login pages are served on HTTPS - no stripping of referer - and are also linked from home pages) validation (detailed in section 6.1) can be used in these cases for mitigating CSRF on login forms to an extent.
+If sub-domains under your master domain are treated as not trusted in your threat model, it is difficult to mitigate login CSRF. A strict subdomain and path level referer header (because most login pages are served on HTTPS - no stripping of referer - and are also linked from home pages) validation (detailed in section 7.1) can be used in these cases for mitigating CSRF on login forms to an extent.
-== Defense In Depth Techniques ==
+== Defense-In-Depth Techniques ==
 === Verifying origin with standard headers ===
@@ Line 188: / Line 188: @@
 ''a) While it's true that hellokitty.marketing.example.com cannot read cookies or access the DOM from secure.example.com because of the same origin policy, hellokitty.marketing.example.com can write cookies to the parent domain (example.com), and these cookies are then consumed by secure.example.com (secure.example.com has no good way to distinguish which site set the cookie). Additionally, there are methods of forcing secure.example.com to always accept your cookie first. What this means is that XSS in hellokitty.marketing.example.com is able to overwrite cookies in secure.example.com.''
-''b) If an attacker is in the middle, they can usually force a request to the same domain over HTTP. If an application is hosted at <nowiki>https://secure.example.com</nowiki>, even if the cookies are set with the secure flag, a man in the middle can force connections to <nowiki>http://secure.example.com</nowiki> and set (overwrite) any arbitrary cookies (even though the secure flag prevents the attacker from reading those cookies). Even if the HSTS header is set on the server and the browser visiting the site supports HSTS (this would prevent a man in the middle from forcing plaintext HTTP requests) unless the HSTS header is set in a way that includes all subdomains, a man in the middle can simply force a request to a separate subdomain and overwrite cookies similar to 1. In other words, as long as <nowiki>http://hellokitty.marketing.example.com</nowiki> doesn't force HTTPS, then an attacker can overwrite cookies on any example.com subdomain.''"
+''b) If an attacker is in the middle, they can usually force a request to the same domain over HTTP. If an application is hosted at <nowiki>https://secure.example.com</nowiki>, even if the cookies are set with the secure flag, a man in the middle can force connections to <nowiki>http://secure.example.com</nowiki> and set (overwrite) any arbitrary cookies (even though the secure flag prevents the attacker from reading those cookies). Even if the HSTS header is set on the server and the browser visiting the site supports HSTS (this would prevent a man in the middle from forcing plain text HTTP requests) unless the HSTS header is set in a way that includes all subdomains, a man in the middle can simply force a request to a separate subdomain and overwrite cookies similar to 1. In other words, as long as <nowiki>http://hellokitty.marketing.example.com</nowiki> doesn't force HTTPS, then an attacker can overwrite cookies on any example.com subdomain.''"
 So, unless you are sure that your subdomains are fully secured and only accept HTTPS connections (we believe it’s difficult to guarantee at large enterprises), you should not rely on the Double Submit Cookie technique as a primary mitigation for CSRF.
-A variant of double submit cookie that can mitigate both the risks mentioned above is including the token in an encrypted cookie - often within the authentication cookie - and then at the server side matching it (after decrypting authentication cookie) with the token in hidden form field or parameter/header for ajax calls.  This works because a sub domain has no way to over-write an properly crafted encrypted cookie without the necessary information such as encryption key.
+A variant of double submit cookie that can mitigate both the risks mentioned above is including the token in an encrypted cookie - often within the authentication cookie - and then at the server side matching it (after decrypting the authentication cookie) with the token in hidden form field or parameter/header for ajax calls.  This works because a sub domain has no way to over-write an properly crafted encrypted cookie without the necessary information such as encryption key.
-=== Samesite Cookie Attribute ===
+=== SameSite Cookie Attribute ===
 SameSite is a cookie attribute (similar to [[HttpOnly]], Secure etc.) introduced by Google to mitigate CSRF attacks. It is defined in [https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-5.3.7 this] Internet Draft. This attribute helps in preventing the browser from sending cookies along with cross-site requests. Possible values for this attribute are lax or strict.
@@ Line 224: / Line 224: @@
 This defense technique is specifically discussed in section 4.3 of [https://seclab.stanford.edu/websec/csrf/csrf.pdf Robust Defenses for Cross-Site Request Forgery]. However, bypasses of this defense using Flash were documented as early as 2008 and again as recently as 2015 by Mathias Karlsson to [https://hackerone.com/reports/44146 exploit a CSRF flaw in Vimeo]. A Flash attack can't spoof the Origin or Referer headers, so by checking both of them we believe this combination of checks should prevent Flash bypass CSRF attacks (if any comes up in future).
-Besides any possible future bypasses such as Flash, using a static header will make it easy to exploit other state changing operations in the application (similar to the previous explanation on why ease of exploitation is easier in origin/referer header check than token based mitigation). Including a random token instead of static header value is more or less equal to the token based approach described in the primary defense section. Developers also need to consider that if you are using this approach in an application with both Ajax calls and form tags, this technique would only help Ajax calls in protecting from CSRF and you would still need protect <form> tags with approaches described in this document such as tokens. Setting custom headers on form tags is not possible directly. Also, CORS configuration should also be robust to make this solution work effectively (as custom headers for requests coming from other domains trigger a pre-flight CORS check).
+Besides any possible future bypasses such as Flash, using a static header will make it easy to exploit other state changing operations in the application (similar to the previous explanation on why ease of exploitation is easier in origin/referer header check than token based mitigation). Including a random token instead of static header value is more or less equal to the token based approach described in the Primary Defenses section. Developers also need to consider that if you are using this approach in an application with both Ajax calls and form tags, this technique would only help Ajax calls in protecting from CSRF and you would still need protect <form> tags with approaches described in this document such as tokens. Setting custom headers on form tags is not possible directly. Also, CORS configuration should also be robust to make this solution work effectively (as custom headers for requests coming from other domains trigger a pre-flight CORS check).
 === User Interaction Based CSRF Defense ===