Kingdom: Input Validation and Representation
Input validation and representation problems ares caused by metacharacters, alternate encodings and numeric representations. Security problems result from trusting input. The issues include: "Buffer Overflows," "Cross-Site Scripting" attacks, "SQL Injection," and many others.
Cross-Site Scripting: Reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following ABAP code segment reads an employee ID,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following ABAP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following ABAP code segment reads an employee ID,
eid
, from an HTTP request and displays it to the user.
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
The code in this example operates correctly if
eid
contains only standard alphanumeric text. If eid
has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following ABAP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...
As in
Example 1
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
References
[1] SAP OSS notes 1582870, 1582867 and related notes for ABAP XSS support
[2] SAP OSS Notes 822881, 1600317, 1640092, 1671470 and 1638779 for XSS support in BSPs
[3] Understanding Malicious Content Mitigation for Web Developers CERT
[4] HTML 4.01 Specification W3
[5] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[18] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[19] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[20] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2021 A03 Injection
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[61] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.abap.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following ActionScript code segment reads an employee ID,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following ActionScript code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following ActionScript code segment reads an employee ID,
eid
, from an HTTP request and displays it to the user.
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...
The code in this example operates correctly if
eid
contains only standard alphanumeric text. If eid
has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following ActionScript code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + name;
}
As in
Example 1
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.actionscript.cross_site_scripting_reflected
Abstract
Sending unvalidated data to the web browser may lead to the execution of malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, an untrusted source is most frequently a web request, and in the case of persistent (also known as stored) XSS it is the results of a database query.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content usually is a segment of JavaScript code, but can also be HML, Flash or any other active content that might be executed by the browser. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Visualforce code segment reads an HTTP request parameter,
The code in this example was intended to receive only alphanumeric text and display it. However, if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following Apex code segment queries a database for a contact name with a given ID and returns the corresponding employee's name, which later gets printed by the Visualforce code.
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are two vectors by which an XSS attack can be executed:
- As in
- As in
1. Data enters a web application through an untrusted source. In the case of reflected XSS, an untrusted source is most frequently a web request, and in the case of persistent (also known as stored) XSS it is the results of a database query.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content usually is a segment of JavaScript code, but can also be HML, Flash or any other active content that might be executed by the browser. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Visualforce code segment reads an HTTP request parameter,
username
, and displays it to the user.
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
The code in this example was intended to receive only alphanumeric text and display it. However, if
username
contains metacharacters or source code, it will be executed by the web browser.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following Apex code segment queries a database for a contact name with a given ID and returns the corresponding employee's name, which later gets printed by the Visualforce code.
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
As in
Example 1
, this code behaves correctly when the values of name
are well defined like just alphanumeric characters, but does nothing to check for malicious data. Even read from a database, the value should be properly validated because the content of the database can be originated from user-supplied data. This way, an attacker can have malicious commands executed in the user's web browser without the need to interact with the victim like in Reflected XSS. This type of attack, known as Stored XSS (or Persistent), can be very hard to detect since the data is indirectly provided to the vulnerable function and also have a higher impact due to the possibility to affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are two vectors by which an XSS attack can be executed:
- As in
Example 1
, data is read from the HTTP request and reflected back in the HTTP response. Reflected XSS occurs when an attacker can have dangerous content delivered to a vulnerable web application and then reflected back to the user and execute by his browser. The most common mechanism to deliver malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to the victim. URLs crafted this way are the core of many phishing schemes, where the attacker lures the victim to visit the URL. After the site reflects the content back to the user, it is executed and can perform several actions like forward private sensitive information, execute unauthorized operations on the victim computer etc.- As in
Example 2
, the database or other data store can provide dangerous data to the application that will be included in dynamic content. From the attacker's perspective, the best place to store malicious content is an area accessible to all users specially those with elevated privileges, who are more likely to handle sensitive information or perform critical operations.References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Salesforce Developers Technical Library Secure Coding Guidelines - Cross Site Scripting
[4] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.apex.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following ASP.NET Web Form reads an employee ID number from an HTTP request and displays it to the user.
Where
The code in these examples operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks in order to lure victims into clicking a link. When the victims click the link, they unwittingly reflect the malicious content through the vulnerable web application and back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 3: The following ASP.NET Web Form queries a database for an employee with a given employee ID and prints the name corresponding with the ID.
Where
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
A number of modern web frameworks provide mechanisms to perform user input validation (including ASP.NET Request Validation and WCF). To highlight the unvalidated sources of input, Fortify Secure Coding Rulepacks dynamically re-prioritize the issues Fortify Static Code Analyzer reports by lowering their probability of exploit and providing pointers to the supporting evidence whenever the framework validation mechanism is in use. With ASP.NET Request Validation, we also provide evidence for when validation is explicitly disabled. We refer to this feature as Context-Sensitive Ranking. To further assist the Fortify user with the auditing process, the Fortify Software Security Research group makes available the Data Validation project template that groups the issues into folders based on the validation mechanism applied to their source of input.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following ASP.NET Web Form reads an employee ID number from an HTTP request and displays it to the user.
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Where
Login
and EmployeeID
are form controls defined as follows:Example 2: The following ASP.NET code segment shows the programmatic way to implement
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 1
.
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
The code in these examples operates correctly if
Login
contains only standard alphanumeric text. If Login
has a value that includes metacharacters or source code, then the code will be executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks in order to lure victims into clicking a link. When the victims click the link, they unwittingly reflect the malicious content through the vulnerable web application and back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 3: The following ASP.NET Web Form queries a database for an employee with a given employee ID and prints the name corresponding with the ID.
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>
Where
EmployeeName
is a form control defined as follows:Example 4: The following ASP.NET code segment is functionally equivalent to
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3
, but implements all of the form elements programmatically.
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
As in
Example 1
and Example 2
, these code examples function correctly when the values of name
are well-behaved, but they nothing to prevent exploits if the values are not. Again, these can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
and Example 2
, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 3
and Example 4
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
A number of modern web frameworks provide mechanisms to perform user input validation (including ASP.NET Request Validation and WCF). To highlight the unvalidated sources of input, Fortify Secure Coding Rulepacks dynamically re-prioritize the issues Fortify Static Code Analyzer reports by lowering their probability of exploit and providing pointers to the supporting evidence whenever the framework validation mechanism is in use. With ASP.NET Request Validation, we also provide evidence for when validation is explicitly disabled. We refer to this feature as Context-Sensitive Ranking. To further assist the Fortify user with the auditing process, the Fortify Software Security Research group makes available the Data Validation project template that groups the issues into folders based on the validation mechanism applied to their source of input.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Anti-Cross Site Scripting Library MSDN
[4] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.dotnet.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web browser without being validated.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following code segment reads an employee ID,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web browser without being validated.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following code segment reads an employee ID,
EID
, from an HTML form and displays it to the user.
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
The code in this example operates correctly if
EID
contains only standard alphanumeric text. If EID
has a value that includes metacharacters or source code, then the code will be executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
As in
Example 1
, this code functions correctly when the values of ENAME
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of ENAME
is read from a database, whose contents are apparently managed by the application. However, if the value of ENAME
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Stored XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from the HTML Form and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Stored XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker might perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.cobol.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following CFML code segment reads an employee ID,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following CFML code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following CFML code segment reads an employee ID,
eid
, from a web form and displays it to the user.
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
The code in this example operates correctly if
Form.eid
contains only standard alphanumeric text. If Form.eid
has a value that includes metacharacters or source code, then the code will be executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following CFML code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
As in
Example 1
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] ColdFusion Developer Center: Security Macromedia
[4] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.cfml.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Go code segment reads a user name,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following Go code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As shown in
- As shown in
- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Go code segment reads a user name,
user
, from an HTTP request and displays it to the user.
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
The code in this example operates correctly if
user
contains only standard alphanumeric text. If user
has a value that includes metacharacters or source code, then the code will be executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following Go code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}
As in
Example 1
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker can execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack affects multiple users. XSS began in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As shown in
Example 1
, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As shown in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker can perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.golang.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following JSP code segment reads an employee ID,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
As in
Some think that in the mobile environment, classic web application vulnerabilities, such as cross-site scripting, do not make sense -- why would the user attack themself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.
Example 3: The following code enables JavaScript in Android's WebView (by default, JavaScript is disabled) and loads a page based on the value received from an Android intent.
If the value of
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- As in
A number of modern web frameworks provide mechanisms to perform user input validation (including Struts and Struts 2). To highlight the unvalidated sources of input, Fortify Secure Coding Rulepacks dynamically re-prioritize the issues Fortify Static Code Analyzer reports by lowering their probability of exploit and providing pointers to the supporting evidence whenever the framework validation mechanism is in use. We refer to this feature as Context-Sensitive Ranking. To further assist the Fortify user with the auditing process, the Fortify Software Security Research group makes available the Data Validation project template that groups the issues into folders based on the validation mechanism applied to their source of input.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following JSP code segment reads an employee ID,
eid
, from an HTTP request and displays it to the user.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
The code in this example operates correctly if
eid
contains only standard alphanumeric text. If eid
has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>
As in
Example 1
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.Some think that in the mobile environment, classic web application vulnerabilities, such as cross-site scripting, do not make sense -- why would the user attack themself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.
Example 3: The following code enables JavaScript in Android's WebView (by default, JavaScript is disabled) and loads a page based on the value received from an Android intent.
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
If the value of
url
starts with javascript:
, JavaScript code that follows executes within the context of the web page inside WebView.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- As in
Example 3
, a source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.A number of modern web frameworks provide mechanisms to perform user input validation (including Struts and Struts 2). To highlight the unvalidated sources of input, Fortify Secure Coding Rulepacks dynamically re-prioritize the issues Fortify Static Code Analyzer reports by lowering their probability of exploit and providing pointers to the supporting evidence whenever the framework validation mechanism is in use. We refer to this feature as Context-Sensitive Ranking. To further assist the Fortify user with the auditing process, the Fortify Software Security Research group makes available the Data Validation project template that groups the issues into folders based on the validation mechanism applied to their source of input.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[21] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2021 A03 Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[38] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[39] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[62] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.java.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Node.js code segment reads an employee ID,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following Node.js code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Node.js code segment reads an employee ID,
eid
, from an HTTP request and displays it to the user.
var http = require('http');
var url = require('url');
...
function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);
The code in this example operates correctly if
eid
contains only standard alphanumeric text. If eid
has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following Node.js code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
var http = require('http');
...
function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);
As in
Example 1
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.javascript.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following code reads an employee ID,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following code segment queries a database for an employee with a given ID and prints the corresponding employee's name in the servlet's response.
As in
Some think that in the mobile environment, classic web application vulnerabilities, such as cross-site scripting, do not make sense -- why would the user attack themself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.
Example 3: The following code enables JavaScript in Android's WebView (by default, JavaScript is disabled) and loads a page based on the value received from an Android intent.
If the value of
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- As in
A number of modern web frameworks provide mechanisms to perform user input validation (including Struts and Spring MVC). To highlight the unvalidated sources of input, Fortify Secure Coding Rulepacks dynamically re-prioritize the issues Fortify Static Code Analyzer reports by lowering their probability of exploit and providing pointers to the supporting evidence whenever the framework validation mechanism is in use. We refer to this feature as Context-Sensitive Ranking. To further assist the Fortify user with the auditing process, the Fortify Software Security Research group makes available the Data Validation project template that groups the issues into folders based on the validation mechanism applied to their source of input.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following code reads an employee ID,
eid
, from an HTTP servlet request, then displays the value back to the user in the servlet's response.
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
The code in this example operates correctly if
eid
contains only standard alphanumeric text. If eid
has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following code segment queries a database for an employee with a given ID and prints the corresponding employee's name in the servlet's response.
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
As in
Example 1
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.Some think that in the mobile environment, classic web application vulnerabilities, such as cross-site scripting, do not make sense -- why would the user attack themself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.
Example 3: The following code enables JavaScript in Android's WebView (by default, JavaScript is disabled) and loads a page based on the value received from an Android intent.
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
If the value of
url
starts with javascript:
, JavaScript code that follows executes within the context of the web page inside WebView.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- As in
Example 3
, a source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.A number of modern web frameworks provide mechanisms to perform user input validation (including Struts and Spring MVC). To highlight the unvalidated sources of input, Fortify Secure Coding Rulepacks dynamically re-prioritize the issues Fortify Static Code Analyzer reports by lowering their probability of exploit and providing pointers to the supporting evidence whenever the framework validation mechanism is in use. We refer to this feature as Context-Sensitive Ranking. To further assist the Fortify user with the auditing process, the Fortify Software Security Research group makes available the Data Validation project template that groups the issues into folders based on the validation mechanism applied to their source of input.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[21] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2021 A03 Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[38] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[39] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[62] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.kotlin.cross_site_scripting_reflected
Abstract
The method sends unvalidated data to a web browser which can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web page through an untrusted source. In the case of reflected XSS, the untrusted source is typically through user components, URL scheme handlers, or notifications, while in the case of Persistent (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a UIWebView component without being validated.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Objective-C code segment reads the text portion of a custom URL scheme which was passed to and invoked the application (
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in HTTP content. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
1. Data enters a web page through an untrusted source. In the case of reflected XSS, the untrusted source is typically through user components, URL scheme handlers, or notifications, while in the case of Persistent (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a UIWebView component without being validated.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Objective-C code segment reads the text portion of a custom URL scheme which was passed to and invoked the application (
myapp://input_to_the_application
). The untrusted data in the URL is then used to render HTML output in a UIWebView component.
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
As in
Example 1
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in HTTP content. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from a custom URL scheme and reflected back in the content of a UIWebView response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable iOS application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a custom scheme URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable app. After the app reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] MWR Labs Continued Adventures with iOS UIWebViews
[4] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.objc.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following PHP code segment reads an employee ID,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following PHP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following PHP code segment reads an employee ID,
eid
, from an HTTP request and displays it to the user.
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
The code in this example operates correctly if
eid
contains only standard alphanumeric text. If eid
has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following PHP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>
As in
Example 1
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.php.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following code segment reads an employee ID,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following code segment reads an employee ID,
eid
, from an HTTP request and displays it to the user.
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
The code in this example operates correctly if
eid
contains only standard alphanumeric text. If eid
has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
As in
Example 1
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.sql.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Python code segment reads an employee ID,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following Python code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Python code segment reads an employee ID,
eid
, from an HTTP request and displays it to the user.
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
The code in this example operates correctly if
eid
contains only standard alphanumeric text. If eid
has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following Python code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
As in
Example 1
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.python.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Ruby code segment reads an employee ID,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS, however please note that if using
Example 2: The following Ruby code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Ruby code segment reads an employee ID,
eid
, from an HTTP request and displays it to the user.
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
The code in this example operates correctly if
eid
contains only standard alphanumeric text. If eid
has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS, however please note that if using
Rack::Request#params()
as in Example 1
, this sees both GET
and POST
parameters, so may be vulnerable to various types of attacks other than just having the malicious code appended to the URL.Example 2: The following Ruby code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
As in
Example 1
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.ruby.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Play controller code segment reads an employee ID,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following Play controller code segment reads an employee ID,
eid
, from an HTTP request and displays it to the user.
def getEmployee = Action { implicit request =>
val eid = request.getQueryString("eid")
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
The code in this example operates correctly if
eid
contains only standard alphanumeric text. If eid
has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[21] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2021 A03 Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[38] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[39] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[62] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.scala.cross_site_scripting_reflected
Abstract
The method sends unvalidated data to a web browser which can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web page through an untrusted source. In the case of reflected XSS, the untrusted source is typically through user components, URL scheme handlers, or notifications, while in the case of Persistent (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a WKWebView component without being validated.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following code reads the contents of a UITextField and displays it to the user within a WKWebView:
The code in this example operates without issues if the text within
Initially this might not appear to be much of a vulnerability. After all, why would someone provide input that can cause malicious code to run on their own device? The real danger is that an attacker may use email or social engineering tricks to lure victims into performing such actions. When this is successful, the victims unwittingly reflect the malicious content through the vulnerable web application back to their own devices. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following Swift code segment reads the text portion of a custom URL scheme which was passed to and invoked the application (
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in HTTP content. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- As in
1. Data enters a web page through an untrusted source. In the case of reflected XSS, the untrusted source is typically through user components, URL scheme handlers, or notifications, while in the case of Persistent (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a WKWebView component without being validated.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following code reads the contents of a UITextField and displays it to the user within a WKWebView:
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
The code in this example operates without issues if the text within
inputTextField
contains only standard alphanumeric text. If the text within inputTextField
includes metacharacters or source code, then the input may be executed as code by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone provide input that can cause malicious code to run on their own device? The real danger is that an attacker may use email or social engineering tricks to lure victims into performing such actions. When this is successful, the victims unwittingly reflect the malicious content through the vulnerable web application back to their own devices. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following Swift code segment reads the text portion of a custom URL scheme which was passed to and invoked the application (
myapp://input_to_the_application
). The untrusted data in the URL is then used to render HTML output in a UIWebView component.
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
As in
Example 2
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in HTTP content. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from a user-controllable UI component and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, a source outside the target application makes a URL request using the target application's custom URL scheme, and unvalidated data from the URL request subsequently read back into the application as trusted data and included in dynamic content.- As in
Example 3
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] MWR Labs Continued Adventures with iOS UIWebViews
[4] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.swift.cross_site_scripting_reflected
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following ASP code segment reads an employee ID,
The code in this example operates correctly if
Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following ASP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
As in
As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
- As in
- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.
2. The data is included in dynamic content that is sent to a web user without validation.
The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.
Example 1: The following ASP code segment reads an employee ID,
eid
, from an HTTP request and displays it to the user.
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
The code in this example operates correctly if
eid
contains only standard alphanumeric text. If eid
has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.
Example 2: The following ASP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...
As in
Example 1
, this code functions correctly when the values of name
are well-behaved, but it does nothing to prevent exploits if they are not. Again, this code can appear less dangerous because the value of name
is read from a database, whose contents are apparently managed by the application. However, if the value of name
originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Persistent (or Stored) XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:
- As in
Example 1
, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.- As in
Example 2
, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.vb.cross_site_scripting_reflected