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

Eelgheez: /* The link-presenter host with regard to the Referer/Origin check */

2018-11-13T00:00:16Z

‎The link-presenter host with regard to the Referer/Origin check

Eelgheez: /* The link-presenter host with regard to the Referer/Origin check */ limit to authenticated actions

2018-11-12T23:59:43Z

‎The link-presenter host with regard to the Referer/Origin check: limit to authenticated actions

Eelgheez: /* The link-presenter host with regard to the Referer/Origin check */

2018-11-12T22:32:13Z

‎The link-presenter host with regard to the Referer/Origin check

Eelgheez: /* The link-presenter host with regard to the Referer/Origin check */

2018-11-12T22:30:27Z

‎The link-presenter host with regard to the Referer/Origin check

Eelgheez: /* The link-presenter host with regard to the Referer/Origin check */

2018-11-12T22:29:42Z

‎The link-presenter host with regard to the Referer/Origin check

Eelgheez: /* The link host argument against the Referer/Origin check */

2018-11-12T22:28:43Z

‎The link host argument against the Referer/Origin check

Eelgheez: /* The link host argument against the Referer/Origin check */ new section

2018-11-12T22:27:35Z

‎The link host argument against the Referer/Origin check: new section

Eelgheez: /* Origin/Referrer Check doesn't Work When the URL is Entered into the Browser */

2017-05-30T16:57:21Z

‎Origin/Referrer Check doesn't Work When the URL is Entered into the Browser

Eelgheez: /* Origin/Referrer Check doesn't Work When the URL is Entered into the Browser */

2017-05-30T14:13:43Z

‎Origin/Referrer Check doesn't Work When the URL is Entered into the Browser

Eelgheez: /* Origin/Referrer Check doesn't Work When the URL is Entered into the Browser */

2017-05-30T14:11:38Z

‎Origin/Referrer Check doesn't Work When the URL is Entered into the Browser

← Older revision		Revision as of 00:00, 13 November 2018
Line 48:		Line 48:
	* send a link pointing to the UI service such as UISITE/authorize.html?id=XXXXXX Clicking it can be handled safely assuming that none of your GET request handlers implement CSRF protection. Once the user finds themselves in the unauthenticated page generated by the UI service, clicking a button in it will send a POST request to an API service such as SITE/authorize?id=XXXXX. The POST handler can safely apply the suggested Referer/Origin check, insisting on all of the received headers of these two to contain white-listed hosts. [[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 16:29, 12 November 2018 (CST)		* send a link pointing to the UI service such as UISITE/authorize.html?id=XXXXXX Clicking it can be handled safely assuming that none of your GET request handlers implement CSRF protection. Once the user finds themselves in the unauthenticated page generated by the UI service, clicking a button in it will send a POST request to an API service such as SITE/authorize?id=XXXXX. The POST handler can safely apply the suggested Referer/Origin check, insisting on all of the received headers of these two to contain white-listed hosts. [[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 16:29, 12 November 2018 (CST)

−	:: The second-factor authentication link scenario seems ~~degenrate~~ in the above scheme because it does not rely on cookies. Only authenticated actions would need to rely on their map to the UI URL in order to get around the Referer/Origin and GET limits related to passing the link via email or any other medium. [[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 17:59, 12 November 2018 (CST)	+	:: The second-factor authentication link scenario seems degenerate in the above scheme because it does not rely on cookies. Only authenticated actions would need to rely on their map to the UI URL in order to get around the Referer/Origin and GET limits related to passing the link via email or any other medium. [[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 17:59, 12 November 2018 (CST)

← Older revision		Revision as of 23:59, 12 November 2018
Line 47:		Line 47:
	I suggest to avoid implementing CSRF protection for GET requests entirely and keep actions that change user profiles to POST handlers. Therefore,		I suggest to avoid implementing CSRF protection for GET requests entirely and keep actions that change user profiles to POST handlers. Therefore,
	* send a link pointing to the UI service such as UISITE/authorize.html?id=XXXXXX Clicking it can be handled safely assuming that none of your GET request handlers implement CSRF protection. Once the user finds themselves in the unauthenticated page generated by the UI service, clicking a button in it will send a POST request to an API service such as SITE/authorize?id=XXXXX. The POST handler can safely apply the suggested Referer/Origin check, insisting on all of the received headers of these two to contain white-listed hosts. [[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 16:29, 12 November 2018 (CST)		* send a link pointing to the UI service such as UISITE/authorize.html?id=XXXXXX Clicking it can be handled safely assuming that none of your GET request handlers implement CSRF protection. Once the user finds themselves in the unauthenticated page generated by the UI service, clicking a button in it will send a POST request to an API service such as SITE/authorize?id=XXXXX. The POST handler can safely apply the suggested Referer/Origin check, insisting on all of the received headers of these two to contain white-listed hosts. [[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 16:29, 12 November 2018 (CST)
		+
		+	:: The second-factor authentication link scenario seems degenrate in the above scheme because it does not rely on cookies. Only authenticated actions would need to rely on their map to the UI URL in order to get around the Referer/Origin and GET limits related to passing the link via email or any other medium. [[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 17:59, 12 November 2018 (CST)

@@ Line 41: / Line 41: @@
 == The link-presenter host with regard to the Referer/Origin check ==
-I heard arguments for extending the whitelist to sites potentially hosting the links that point to the application that is protected with a Referer/Origin check.  This can be a slippery slope as sending a link through email may end up being hosted by a huge number of webmail providers.  Besides, the argument had a design flaw where the CSRF protection applied to both GET and POST requests.
+I heard arguments for extending the whitelist to sites potentially hosting the links that point to the application that is protected with a Referer/Origin check.  This can be a slippery slope as sending a second-factor authentication link through email may end up being hosted by a huge number of webmail providers.  Besides, the argument had a design flaw where the CSRF protection applied to both GET and POST requests.
 Instead I suggest to mention an implementation detail that relies on a common practice of separating the UI interface from the API.  That is,

@@ Line 41: / Line 41: @@
 == The link-presenter host with regard to the Referer/Origin check ==
-I heard arguments for extending the whitelist to sites potentially hosting the link to the application that is protected with a Referer/Origin check.  This can be a slippery slope as sending a link through email may end up being hosted by a huge number of webmail providers.  Besides, the argument had a design flaw where the CSRF protection applied to both GET and POST requests.
+I heard arguments for extending the whitelist to sites potentially hosting the links that point to the application that is protected with a Referer/Origin check.  This can be a slippery slope as sending a link through email may end up being hosted by a huge number of webmail providers.  Besides, the argument had a design flaw where the CSRF protection applied to both GET and POST requests.
 Instead I suggest to mention an implementation detail that relies on a common practice of separating the UI interface from the API.  That is,

@@ Line 46: / Line 46: @@
 * instead of sending a link clicking which is supposed to generate a GET request such as SITE/authorize?id=XXXXXXX (with some non-predictable GUID) authorizing the user immediately,
 I suggest to avoid implementing CSRF protection for GET requests entirely and keep actions that change user profiles to POST handlers.  Therefore,
-* send a link pointing to the UI service such as UISITE/authorize.html?id=XXXXXX  Clicking it can be handled safely assuming that none of your GET request handlers implement CSRF protection.  Once the user finds themselves in the unauthenticated page generated by the UI service, clicking a button in it will send a POST request to an API service such as SITE/authorize?id=XXXXX.  The POST handler can safely apply the suggested Referer/Origin check, insisting on all of the received headers of these two to contain white-listed hosts.  ~~----
+* send a link pointing to the UI service such as UISITE/authorize.html?id=XXXXXX  Clicking it can be handled safely assuming that none of your GET request handlers implement CSRF protection.  Once the user finds themselves in the unauthenticated page generated by the UI service, clicking a button in it will send a POST request to an API service such as SITE/authorize?id=XXXXX.  The POST handler can safely apply the suggested Referer/Origin check, insisting on all of the received headers of these two to contain white-listed hosts.  [[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 16:29, 12 November 2018 (CST)

@@ Line 39: / Line 39: @@
 :: Indeed, the abuse scenario CSRF normally focuses on involves luring a victim user into a malicious site/vulnerable blog/forum and letting the user's browser execute requests against a CSRF-vulnerable target site on behalf of the user without the user's participation (or with the user clicking a form submit button aiming at the vulnerable target site).  Luring a victim into pasting a link could be considered a less likely scenario.  I guess that would rely on the target site interpreting a GET request or its embedded requests as actions.  In that unlikely scenario I can see that checking the origin and "referer" referrer will block the unexpected abuse, encouraging developers to rely on REST conventions in mirroring the page state in its address. (Changing the application's state on receiving GET requests would make it vulnerable to embedded foreign requests such as <img src="https://bank.test/my/transfer?to=GogAndMagog">). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 09:11, 30 May 2017 (CDT)
-== The link host argument against the Referer/Origin check ==
+== The link-presenter host with regard to the Referer/Origin check ==
 I heard arguments for extending the whitelist to sites potentially hosting the link to the application that is protected with a Referer/Origin check.  This can be a slippery slope as sending a link through email may end up being hosted by a huge number of webmail providers.  Besides, the argument had a design flaw where the CSRF protection applied to both GET and POST requests.

← Older revision		Revision as of 22:27, 12 November 2018
Line 38:		Line 38:

	:: Indeed, the abuse scenario CSRF normally focuses on involves luring a victim user into a malicious site/vulnerable blog/forum and letting the user's browser execute requests against a CSRF-vulnerable target site on behalf of the user without the user's participation (or with the user clicking a form submit button aiming at the vulnerable target site). Luring a victim into pasting a link could be considered a less likely scenario. I guess that would rely on the target site interpreting a GET request or its embedded requests as actions. In that unlikely scenario I can see that checking the origin and "referer" referrer will block the unexpected abuse, encouraging developers to rely on REST conventions in mirroring the page state in its address. (Changing the application's state on receiving GET requests would make it vulnerable to embedded foreign requests such as <img src="https://bank.test/my/transfer?to=GogAndMagog">). --[[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 09:11, 30 May 2017 (CDT)		:: Indeed, the abuse scenario CSRF normally focuses on involves luring a victim user into a malicious site/vulnerable blog/forum and letting the user's browser execute requests against a CSRF-vulnerable target site on behalf of the user without the user's participation (or with the user clicking a form submit button aiming at the vulnerable target site). Luring a victim into pasting a link could be considered a less likely scenario. I guess that would rely on the target site interpreting a GET request or its embedded requests as actions. In that unlikely scenario I can see that checking the origin and "referer" referrer will block the unexpected abuse, encouraging developers to rely on REST conventions in mirroring the page state in its address. (Changing the application's state on receiving GET requests would make it vulnerable to embedded foreign requests such as <img src="https://bank.test/my/transfer?to=GogAndMagog">). --[[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 09:11, 30 May 2017 (CDT)
		+
		+	== The link host argument against the Referer/Origin check ==
		+
		+	I heard arguments for extending the whitelist to sites potentially hosting the link to the application that is protected with a Referer/Origin check. This can be a slippery slope as sending a link through email may end up being hosted by a huge number of webmail providers. Besides, the argument had a design flaw where the CSRF protection applied to both GET and POST requests.
		+
		+	Instead I suggest to mention an implementation detail that relies on a common practice of separating the UI interface from the API. That is,
		+	* instead of sending a link clicking which is supposed to generate a GET request such as SITE/authorize?id=XXXXXXX (with some non-predictable GUID) authorizing the user immediately,
		+	I suggest to avoid implementing CSRF protection for GET requests entirely and keep actions that change user profiles to POST handlers. Therefore,
		+	* send a link pointing to the UI service such as UISITE/authorize.html?id=XXXXXX Clicking it can be handled safely assuming that none of your GET request handlers implement CSRF protection. Once the user finds themselves in the unauthenticated page generated by the UI service, clicking a button in it will send a POST request to an API service such as SITE/authorize?id=XXXXX. The POST handler can safely apply the suggested Referer/Origin check, insisting on all of the received headers of these two to contain white-listed hosts. ~~----

← Older revision		Revision as of 16:57, 30 May 2017
Line 37:		Line 37:
	: Thanks you Lindon for the remarks and note about these headers. In CSRF context, we want to protect from request altering data, is the reason why the CSRF filter is applied on request targeting "backend service" in order to be sure to be invoked for services and not for UI URL (ex: when loading a form or the site home page), perhaps i should mention it on sample. If the URL of the service is invoked directly (i.e. entering or pasting a URL into the browser as you mention) is not a normal behavior and the protection should block the request because service is invoked normally by ajax (more common way in recent apps) or submitting a html form. Thanks again for the talk, it helps to fine tune the sample. --[[User:Dominique_RIGHETTO\|dominique]] ([[User talk:Dominique_RIGHETTO\|talk]]) 06:20, 30 May 2017 (CEST)		: Thanks you Lindon for the remarks and note about these headers. In CSRF context, we want to protect from request altering data, is the reason why the CSRF filter is applied on request targeting "backend service" in order to be sure to be invoked for services and not for UI URL (ex: when loading a form or the site home page), perhaps i should mention it on sample. If the URL of the service is invoked directly (i.e. entering or pasting a URL into the browser as you mention) is not a normal behavior and the protection should block the request because service is invoked normally by ajax (more common way in recent apps) or submitting a html form. Thanks again for the talk, it helps to fine tune the sample. --[[User:Dominique_RIGHETTO\|dominique]] ([[User talk:Dominique_RIGHETTO\|talk]]) 06:20, 30 May 2017 (CEST)

−	:: Indeed, the abuse scenario CSRF normally focuses on involves luring a victim user into a malicious site/~~vulerable~~ blog/forum and letting the user's browser execute requests against a CSRF-vulnerable target site on behalf of the user without the user's participation (or with the user clicking a form submit button aiming at the vulnerable target site). Luring a victim into pasting a link could be considered a less likely scenario. I guess that would rely on the target site interpreting a GET request or its embedded requests as actions. In that unlikely scenario I can see that checking the origin and "referer" referrer will block the unexpected abuse, encouraging developers to rely on REST conventions in mirroring the page state in its address. (Changing the application's state on receiving GET requests would make it vulnerable to embedded foreign requests such as <img src="https://bank.test/my/transfer?to=GogAndMagog">). --[[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 09:11, 30 May 2017 (CDT)	+	:: Indeed, the abuse scenario CSRF normally focuses on involves luring a victim user into a malicious site/vulnerable blog/forum and letting the user's browser execute requests against a CSRF-vulnerable target site on behalf of the user without the user's participation (or with the user clicking a form submit button aiming at the vulnerable target site). Luring a victim into pasting a link could be considered a less likely scenario. I guess that would rely on the target site interpreting a GET request or its embedded requests as actions. In that unlikely scenario I can see that checking the origin and "referer" referrer will block the unexpected abuse, encouraging developers to rely on REST conventions in mirroring the page state in its address. (Changing the application's state on receiving GET requests would make it vulnerable to embedded foreign requests such as <img src="https://bank.test/my/transfer?to=GogAndMagog">). --[[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 09:11, 30 May 2017 (CDT)

← Older revision		Revision as of 14:13, 30 May 2017
Line 37:		Line 37:
	: Thanks you Lindon for the remarks and note about these headers. In CSRF context, we want to protect from request altering data, is the reason why the CSRF filter is applied on request targeting "backend service" in order to be sure to be invoked for services and not for UI URL (ex: when loading a form or the site home page), perhaps i should mention it on sample. If the URL of the service is invoked directly (i.e. entering or pasting a URL into the browser as you mention) is not a normal behavior and the protection should block the request because service is invoked normally by ajax (more common way in recent apps) or submitting a html form. Thanks again for the talk, it helps to fine tune the sample. --[[User:Dominique_RIGHETTO\|dominique]] ([[User talk:Dominique_RIGHETTO\|talk]]) 06:20, 30 May 2017 (CEST)		: Thanks you Lindon for the remarks and note about these headers. In CSRF context, we want to protect from request altering data, is the reason why the CSRF filter is applied on request targeting "backend service" in order to be sure to be invoked for services and not for UI URL (ex: when loading a form or the site home page), perhaps i should mention it on sample. If the URL of the service is invoked directly (i.e. entering or pasting a URL into the browser as you mention) is not a normal behavior and the protection should block the request because service is invoked normally by ajax (more common way in recent apps) or submitting a html form. Thanks again for the talk, it helps to fine tune the sample. --[[User:Dominique_RIGHETTO\|dominique]] ([[User talk:Dominique_RIGHETTO\|talk]]) 06:20, 30 May 2017 (CEST)

−	:: Indeed, the abuse scenario CSRF normally focuses on involves luring a victim user into a malicious site/vulerable blog/forum and letting the user's browser execute requests against a CSRF-vulnerable target site on behalf of the user without the user's participation (or with the user clicking a form submit button aiming at the vulnerable target site). Luring a victim into pasting a link could be considered a less likely scenario. I guess that would rely on the target site interpreting a GET request or its embedded requests as actions. In that unlikely scenario I can see that checking the origin and "referer" referrer will block the unexpected abuse, encouraging developers to rely on REST conventions in mirroring the page state in its address~~, as changing~~ the application on receiving GET requests ~~will~~ make it vulnerable to embedded foreign requests such as <img src="https://bank.test/my/transfer?to=GogAndMagog">. --[[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 09:11, 30 May 2017 (CDT)	+	:: Indeed, the abuse scenario CSRF normally focuses on involves luring a victim user into a malicious site/vulerable blog/forum and letting the user's browser execute requests against a CSRF-vulnerable target site on behalf of the user without the user's participation (or with the user clicking a form submit button aiming at the vulnerable target site). Luring a victim into pasting a link could be considered a less likely scenario. I guess that would rely on the target site interpreting a GET request or its embedded requests as actions. In that unlikely scenario I can see that checking the origin and "referer" referrer will block the unexpected abuse, encouraging developers to rely on REST conventions in mirroring the page state in its address. (Changing the application's state on receiving GET requests would make it vulnerable to embedded foreign requests such as <img src="https://bank.test/my/transfer?to=GogAndMagog">). --[[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 09:11, 30 May 2017 (CDT)

← Older revision		Revision as of 14:11, 30 May 2017
Line 37:		Line 37:
	: Thanks you Lindon for the remarks and note about these headers. In CSRF context, we want to protect from request altering data, is the reason why the CSRF filter is applied on request targeting "backend service" in order to be sure to be invoked for services and not for UI URL (ex: when loading a form or the site home page), perhaps i should mention it on sample. If the URL of the service is invoked directly (i.e. entering or pasting a URL into the browser as you mention) is not a normal behavior and the protection should block the request because service is invoked normally by ajax (more common way in recent apps) or submitting a html form. Thanks again for the talk, it helps to fine tune the sample. --[[User:Dominique_RIGHETTO\|dominique]] ([[User talk:Dominique_RIGHETTO\|talk]]) 06:20, 30 May 2017 (CEST)		: Thanks you Lindon for the remarks and note about these headers. In CSRF context, we want to protect from request altering data, is the reason why the CSRF filter is applied on request targeting "backend service" in order to be sure to be invoked for services and not for UI URL (ex: when loading a form or the site home page), perhaps i should mention it on sample. If the URL of the service is invoked directly (i.e. entering or pasting a URL into the browser as you mention) is not a normal behavior and the protection should block the request because service is invoked normally by ajax (more common way in recent apps) or submitting a html form. Thanks again for the talk, it helps to fine tune the sample. --[[User:Dominique_RIGHETTO\|dominique]] ([[User talk:Dominique_RIGHETTO\|talk]]) 06:20, 30 May 2017 (CEST)

−	:: Indeed, the abuse scenario involves luring a victim user into a malicious site/vulerable blog/forum and letting the user's browser execute requests against a CSRF-vulnerable target site on behalf of the user without the user's participation (or with the user clicking a form submit button aiming at the vulnerable target site). Luring a victim into pasting a link could be considered a less likely scenario. I guess that would rely on the target site interpreting a GET request or its embedded requests as actions. In that unlikely scenario I can see that checking the origin and "referer" referrer will block the unexpected abuse, encouraging developers to rely on REST conventions in mirroring the page state in its address, as changing the application on receiving GET requests will make it vulnerable to embedded foreign requests such as <img src="https://bank.test/my/transfer?to=GogAndMagog">. --[[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 09:11, 30 May 2017 (CDT)	+	:: Indeed, the abuse scenario CSRF normally focuses on involves luring a victim user into a malicious site/vulerable blog/forum and letting the user's browser execute requests against a CSRF-vulnerable target site on behalf of the user without the user's participation (or with the user clicking a form submit button aiming at the vulnerable target site). Luring a victim into pasting a link could be considered a less likely scenario. I guess that would rely on the target site interpreting a GET request or its embedded requests as actions. In that unlikely scenario I can see that checking the origin and "referer" referrer will block the unexpected abuse, encouraging developers to rely on REST conventions in mirroring the page state in its address, as changing the application on receiving GET requests will make it vulnerable to embedded foreign requests such as <img src="https://bank.test/my/transfer?to=GogAndMagog">. --[[User:Eelgheez\|Eelgheez]] ([[User talk:Eelgheez\|talk]]) 09:11, 30 May 2017 (CDT)