界: Input Validation and Representation
输入验证与表示问题是由元字符、交替编码和数字表示引起的。安全问题源于信任输入。这些问题包括:“Buffer Overflows”、“Cross-Site Scripting”攻击、“SQL Injection”等其他问题。
Cross-Site Scripting: Poor Validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定的编码函数模块(例如
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 ABAP 代码片段可在 HTTP 请求中读取雇员 ID
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:以下 ABAP 代码片段可在数据库中查询具有给定 ID 的雇员,并输出采用 HTML 编码的相应雇员姓名。
如同
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
- 如
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
cl_http_utility=>escape_html
)能避免一部分 cross-site scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码函数模块等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便进行了编码,Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 ABAP 代码片段可在 HTTP 请求中读取雇员 ID
eid
,对其进行 HTML 编码,并将其显示给用户。
...
eid = request->get_form_field( 'eid' ).
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = eid
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_eid.
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( e_eid ).
...
如果
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:以下 ABAP 代码片段可在数据库中查询具有给定 ID 的雇员,并输出采用 HTML 编码的相应雇员姓名。
...
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.
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = itab_employees-name
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_name.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( e_name ).
...
如同
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。- 如
Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
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 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[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 - Security Technical Implementation Guide Version 6.1 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.abap.cross_site_scripting_poor_validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定编码函数能避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便进行了编码,Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 ActionScript 代码片段可在 HTTP 请求中读取雇员 ID
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:以下 ActionScript 代码片段可在数据库中查询具有给定 ID 的雇员,并输出采用 HTML 编码的相应雇员姓名。
如同
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
- 如
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 ActionScript 代码片段可在 HTTP 请求中读取雇员 ID
eid
,对其进行 HTML 编码,并将其显示给用户。
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + escape(eid);
...
如果
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:以下 ActionScript 代码片段可在数据库中查询具有给定 ID 的雇员,并输出采用 HTML 编码的相应雇员姓名。
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: " + escape(name);
}
如同
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。- 如
Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.actionscript.cross_site_scripting_poor_validation
Abstract
向 Web 浏览器发送未经验证的数据可能导致执行恶意代码。
Explanation
由于用户提供的数据和 Web 浏览器解析器之间可能发生大量交互,因此不可能始终正确地评估所应用的编码是否足以防范 XSS 漏洞。所以,即便进行了编码,Fortify Static Code Analyzer(Fortify 静态代码分析器)仍会报告跨站脚本攻击结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
恶意内容通常为 JavaScript 代码片段,但也可以是 HTML、Flash 或其他任何可以被浏览器执行的活动内容。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 Apex 代码片段在数据库中查询具有给定 ID 的联系人姓名,并返回相应的员工姓名,以便稍后通过 Visualforce 代码进行打印。
尽管此代码使用了
示例 2:以下 Visualforce 代码片段读取 HTTP 请求参数
此示例中的代码原本是仅接收字母数字文本并进行显示。但是,如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。有两种 XSS 攻击途径:
- 如
- 如
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
恶意内容通常为 JavaScript 代码片段,但也可以是 HTML、Flash 或其他任何可以被浏览器执行的活动内容。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 Apex 代码片段在数据库中查询具有给定 ID 的联系人姓名,并返回相应的员工姓名,以便稍后通过 Visualforce 代码进行打印。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!HTMLENCODE(variable)}'">Click me!</div>
尽管此代码使用了
HTMLENCODE
,但仍未正确验证数据库提供的数据,因而易受 XSS 攻击。发生这种情况的原因是,variable
内容通过不同的机制(HTML 和 Javascript 解析器)进行解析,因此需要编码两次。这样,攻击者就可以在用户的 Web 浏览器中执行恶意命令,而无需像在 Reflected XSS 中那样与受害者进行交互。这种类型的攻击(称为 Stored XSS 或 Persistent)可能极难发现,因为数据被间接提供给易受攻击的函数;另外,由于这种攻击可能影响多个用户,因而会造成巨大的影响。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿的用户都会执行这些恶意代码。示例 2:以下 Visualforce 代码片段读取 HTTP 请求参数
username
,并将其显示给用户。
<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>
此示例中的代码原本是仅接收字母数字文本并进行显示。但是,如果
username
包含元字符或源代码,则其将由 Web 浏览器执行。同样,在此示例中,使用 HTMLENCODE
不足以防止 XSS 攻击,因为该变量由 Javascript 解析器处理。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。有两种 XSS 攻击途径:
- 如
Example 1
中所示,数据库或其他数据存储可能会向应用程序提供危险数据,这些数据将包含在动态内容中。从攻击者的角度看,存储恶意内容的最佳位置莫过于可供所有用户(特别是具有较高权限的用户)访问的区域,因为这些用户更有可能处理敏感信息或执行重要操作。- 如
Example 2
中所示,系统从 HTTP 请求中读取数据,并在 HTTP 响应中返回数据。如果攻击者可以将危险内容发送给易受攻击的 Web 应用程序,随后将其反馈给用户并在用户浏览器中执行,则会发生 Reflected XSS。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布的或通过电子邮件直接发送给受害者的 URL 中。以这种方式构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者可以借此诱骗受害者访问该 URL。站点将该内容反馈给用户后,便会执行这些内容,并可执行多项操作,例如转发私人敏感信息、在受害者计算机上执行未经授权的操作等。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 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 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.apex.cross_site_scripting_poor_validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定编码函数能避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便进行了编码,Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 ASP.NET 代码片段可从 HTTP 请求中读取雇员 ID,对其进行 HTML 编码,并显示给用户。
其中,
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢? 真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者单击链接。当受害者单击该链接时,就会不知不觉地通过易受攻击的 Web 应用程序,使自己的电脑蒙受恶意内容带来的风险。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 3:以下 ASP.NET 代码片段可根据一个给定的雇员 ID 来查询数据库,并输出采用 HTML 编码的相应雇员姓名。
其中,
如
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
- 如
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
许多现代 Web 框架都会提供对用户输入执行验证的机制(包括 ASP.NET 请求验证和 WCF)。为了突出显示未经验证的输入源,Fortify 安全编码规则包会对 Fortify Static Code Analyzer(Fortify 静态代码分析器)报告的问题动态重新调整优先级,即在采用框架验证机制时降低这些问题被利用的几率并提供指向相应证据的指针。对于 ASP.NET 请求验证,我们还会提供有关何时明确禁用此验证的证据。我们将这种功能称之为上下文敏感排序。为了进一步帮助 Fortify 用户执行审计过程,Fortify 软件安全研究团队开发了 Data Validation(数据验证)项目模板,该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 ASP.NET 代码片段可从 HTTP 请求中读取雇员 ID,对其进行 HTML 编码,并显示给用户。
<script runat="server">
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
...
</script>
其中,
Login
和 EmployeeID
为表单控件,定义如下:示例 2:下面的 ASP.NET 代码片段实现的功能与
<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 = Server.HtmlEncode(Login.Text);
如果
Login
只包含标准的字母或数字文本,上面两个示例中的代码就能正确运行。如果 Login
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢? 真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者单击链接。当受害者单击该链接时,就会不知不觉地通过易受攻击的 Web 应用程序,使自己的电脑蒙受恶意内容带来的风险。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 3:以下 ASP.NET 代码片段可根据一个给定的雇员 ID 来查询数据库,并输出采用 HTML 编码的相应雇员姓名。
<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 = Server.HtmlEncode(name);
</script>
其中,
EmployeeName
为表单控件,定义如下:示例 4:同样,下面的 ASP.NET 代码片段在功能上等效于
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3
,不过是以编程方式实现所有表单元素。
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 = Server.HtmlEncode(name);
如
Example 1
和Example 2
中所示,如果 name
的值正常,则这些代码片段可以正确运行,但如果这些值不正常,则这些代码片段将无法阻止漏洞利用。另外,这些代码示例可能会看起来不太危险,因为 name
的值是从数据库中读取的,而数据库的内容明显由应用程序管理。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
和Example 2
中所示,系统会从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。- 如
Example 3
和Example 4
中所示,应用程序会将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
许多现代 Web 框架都会提供对用户输入执行验证的机制(包括 ASP.NET 请求验证和 WCF)。为了突出显示未经验证的输入源,Fortify 安全编码规则包会对 Fortify Static Code Analyzer(Fortify 静态代码分析器)报告的问题动态重新调整优先级,即在采用框架验证机制时降低这些问题被利用的几率并提供指向相应证据的指针。对于 ASP.NET 请求验证,我们还会提供有关何时明确禁用此验证的证据。我们将这种功能称之为上下文敏感排序。为了进一步帮助 Fortify 用户执行审计过程,Fortify 软件安全研究团队开发了 Data Validation(数据验证)项目模板,该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。
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 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 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.dotnet.cross_site_scripting_poor_validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定编码函数能避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便进行了编码,Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
例 1:下面的代码片段可从 HTTP 请求中读取
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
— 应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被回写到应用程序中,并包含在动态内容中。Persistent XSS 盗取发生在如下情况:攻击者将危险内容注入到数据存储器中,且该存储器之后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于一个面向许多用户,尤其是相关用户显示的区域。相关用户通常在应用程序中具备较高的特权,或相互之间交换敏感数据,这些数据对攻击者来说有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人所有的敏感数据的访问权限。
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
例 1:下面的代码片段可从 HTTP 请求中读取
text
参数,对其进行 HTML 编码,并将其显示在脚本标签之间的警报框中。
"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";
如果
text
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 text
具有单引号、圆括号和分号,则会结束 alert
文本框,之后将执行代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。— 应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被回写到应用程序中,并包含在动态内容中。Persistent XSS 盗取发生在如下情况:攻击者将危险内容注入到数据存储器中,且该存储器之后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于一个面向许多用户,尤其是相关用户显示的区域。相关用户通常在应用程序中具备较高的特权,或相互之间交换敏感数据,这些数据对攻击者来说有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人所有的敏感数据的访问权限。
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.cfml.cross_site_scripting_poor_validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定编码函数能避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便进行了编码,Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。
Cross-Site Scripting (XSS) 漏洞会在以下情况下发生:
1.数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 Go 代码片段可从 HTTP 请求中读取用户名
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:下面的 Go 代码片段会根据一个特定的雇员 ID 来查询数据库,并显示出相应的雇员姓名。
如同
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
- 如
- 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据读回到应用程序中,并包含在动态内容中。
Cross-Site Scripting (XSS) 漏洞会在以下情况下发生:
1.数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 Go 代码片段可从 HTTP 请求中读取用户名
user
,并将其显示给用户。
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(user))
}
如果
user
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 user
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:下面的 Go 代码片段会根据一个特定的雇员 ID 来查询数据库,并显示出相应的雇员姓名。
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: ", html.EscapeString(name))
}
如同
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者便能在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并提高多个用户受此攻击影响的可能性。XSS 漏洞利用会在网站上为访问者提供一个“留言簿”,以此开始攻击。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中反馈数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。- 如
Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。- 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据读回到应用程序中,并包含在动态内容中。
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.golang.cross_site_scripting_poor_validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定的编码构造,例如带有
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 JSP 代码片段可从 HTTP 请求中读取雇员 ID
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:以下 JSP 代码片段可在数据库中查询具有给定 ID 的雇员,并通过
如同
有些人认为在移动环境中,典型的 Web 应用程序漏洞(如 Cross-Site Scripting)是无意义的 -- 为什么用户要攻击自己?但是,谨记移动平台的本质是从各种来源下载并在相同设备上运行的应用程序。恶意软件在银行应用程序附近运行的可能性很高,它们会强制扩展移动应用程序的攻击面(包括跨进程通信)。
示例 3:以下代码在 Android WebView 中启用了 JavaScript(默认情况下,JavaScript 为禁用状态),并根据从 Android Intent 接收到的值加载页面。
如果
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
- 如
- 如
许多现代 Web 框架都会提供对用户输入执行验证的机制(包括 Struts 和 Struts 2)。为了突出显示未经验证的输入源,Fortify 安全编码规则包会对 Fortify Static Code Analyzer(Fortify 静态代码分析器)报告的问题动态重新调整优先级,即在采用框架验证机制时降低这些问题被利用的几率并提供指向相应证据的指针。我们将这种功能称之为上下文敏感排序。为了进一步帮助 Fortify 用户执行审计过程,Fortify 软件安全研究团队开发了 Data Validation(数据验证)项目模板,该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。
escapeXml="true"
属性(默认设置)的 <c:out/>
标签可以避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码构造等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便应用了编码,Fortify Static Code Analyzer(Fortify 静态代码分析器)仍会报告发现跨站点脚本攻击,并将其显示为“Cross-Site Scripting: Poor Validation”问题。Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 JSP 代码片段可从 HTTP 请求中读取雇员 ID
eid
,并通过 <c:out/>
标签将其显示给用户。
Employee ID: <c:out value="${param.eid}"/>
如果
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:以下 JSP 代码片段可在数据库中查询具有给定 ID 的雇员,并通过
<c:out/>
标签输出相应雇员姓名。
<%...
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: <c:out value="${name}"/>
如同
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。有些人认为在移动环境中,典型的 Web 应用程序漏洞(如 Cross-Site Scripting)是无意义的 -- 为什么用户要攻击自己?但是,谨记移动平台的本质是从各种来源下载并在相同设备上运行的应用程序。恶意软件在银行应用程序附近运行的可能性很高,它们会强制扩展移动应用程序的攻击面(包括跨进程通信)。
示例 3:以下代码在 Android WebView 中启用了 JavaScript(默认情况下,JavaScript 为禁用状态),并根据从 Android Intent 接收到的值加载页面。
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(URLEncoder.encode(url));
...
如果
url
的值以 javascript:
开头,则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。- 如
Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。- 如
Example 3
中所示,应用程序外部的源会将危险数据存储在数据库或其他数据存储中,随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。许多现代 Web 框架都会提供对用户输入执行验证的机制(包括 Struts 和 Struts 2)。为了突出显示未经验证的输入源,Fortify 安全编码规则包会对 Fortify Static Code Analyzer(Fortify 静态代码分析器)报告的问题动态重新调整优先级,即在采用框架验证机制时降低这些问题被利用的几率并提供指向相应证据的指针。我们将这种功能称之为上下文敏感排序。为了进一步帮助 Fortify 用户执行审计过程,Fortify 软件安全研究团队开发了 Data Validation(数据验证)项目模板,该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。
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 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[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 - Security Technical Implementation Guide Version 6.1 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.java.cross_site_scripting_poor_validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定编码函数能避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便进行了编码,Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于基于 DOM 的 XSS,将从 URL 参数或浏览器中的其他值读取数据,并使用客户端代码将其重新写入该页面。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。对于基于 DOM 的 XSS,任何时候当受害人的浏览器解析 HTML 页面时,恶意内容都将作为 DOM(文档对象模型)创建的一部分执行。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 JavaScript 代码片段从 HTTP 请求中读取雇员 ID(即
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。
— 应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被回写到应用程序中,并包含在动态内容中。Persistent XSS 盗取发生在如下情况:攻击者将危险内容注入到数据存储器中,且该存储器之后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于一个面向许多用户,尤其是相关用户显示的区域。相关用户通常在应用程序中具备较高的特权,或相互之间交换敏感数据,这些数据对攻击者来说有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人所有的敏感数据的访问权限。
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于基于 DOM 的 XSS,将从 URL 参数或浏览器中的其他值读取数据,并使用客户端代码将其重新写入该页面。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。对于基于 DOM 的 XSS,任何时候当受害人的浏览器解析 HTML 页面时,恶意内容都将作为 DOM(文档对象模型)创建的一部分执行。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 JavaScript 代码片段从 HTTP 请求中读取雇员 ID(即
eid
),对其进行转义并显示给用户。
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(escape(document.URL.substring(pos,document.URL.length)));
</SCRIPT>
如果
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。
— 应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被回写到应用程序中,并包含在动态内容中。Persistent XSS 盗取发生在如下情况:攻击者将危险内容注入到数据存储器中,且该存储器之后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于一个面向许多用户,尤其是相关用户显示的区域。相关用户通常在应用程序中具备较高的特权,或相互之间交换敏感数据,这些数据对攻击者来说有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人所有的敏感数据的访问权限。
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.javascript.cross_site_scripting_poor_validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定的编码构造,例如带有
Cross-Site Scripting (XSS) 漏洞会在以下情况下发生:
1.数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信来源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
如同
有些人认为在移动环境中,典型的 Web 应用程序漏洞(如 Cross-Site Scripting)是无意义的 -- 为什么用户要攻击自己?但是,谨记移动平台的本质是从各种来源下载并在相同设备上运行的应用程序。恶意软件在银行应用程序附近运行的可能性很高,它们会强制扩展移动应用程序的攻击面(包括跨进程通信)。
示例 3:以下代码在 Android WebView 中启用了 JavaScript(默认情况下,JavaScript 为禁用状态),并根据从 Android Intent 接收到的值加载页面。
如果
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
- 如
- 如
许多现代 Web 框架都会提供对用户输入执行验证的机制(包括 Struts 和 Spring MVC)。为了突出显示未经验证的输入源,Fortify 安全编码规则包会对 Fortify Static Code Analyzer(Fortify 静态代码分析器)报告的问题动态重新调整优先级,即在采用框架验证机制时降低这些问题被利用的几率并提供指向相应证据的指针。我们将这种功能称之为上下文敏感排序。为了进一步帮助 Fortify 用户执行审计过程,Fortify 软件安全研究团队开发了 Data Validation(数据验证)项目模板,该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。
escapeXml="true"
属性(默认设置)的 <c:out/>
标签可以避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码构造等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便应用了编码,Fortify Static Code Analyzer(Fortify 静态代码分析器)仍会报告发现跨站点脚本攻击,并将其显示为“Cross-Site Scripting: Poor Validation”问题。Cross-Site Scripting (XSS) 漏洞会在以下情况下发生:
1.数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信来源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
如果
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
如同
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。有些人认为在移动环境中,典型的 Web 应用程序漏洞(如 Cross-Site Scripting)是无意义的 -- 为什么用户要攻击自己?但是,谨记移动平台的本质是从各种来源下载并在相同设备上运行的应用程序。恶意软件在银行应用程序附近运行的可能性很高,它们会强制扩展移动应用程序的攻击面(包括跨进程通信)。
示例 3:以下代码在 Android WebView 中启用了 JavaScript(默认情况下,JavaScript 为禁用状态),并根据从 Android Intent 接收到的值加载页面。
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(URLEncoder.encode(url))
...
如果
url
的值以 javascript:
开头,则接下来的 JavaScript 代码将在 WebView 中的 Web 页面上下文内部执行。正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。- 如
Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。- 如
Example 3
中所示,应用程序外部的源会将危险数据存储在数据库或其他数据存储中,随后这些危险数据会作为可信数据读回到应用程序并包含在动态内容中。许多现代 Web 框架都会提供对用户输入执行验证的机制(包括 Struts 和 Spring MVC)。为了突出显示未经验证的输入源,Fortify 安全编码规则包会对 Fortify Static Code Analyzer(Fortify 静态代码分析器)报告的问题动态重新调整优先级,即在采用框架验证机制时降低这些问题被利用的几率并提供指向相应证据的指针。我们将这种功能称之为上下文敏感排序。为了进一步帮助 Fortify 用户执行审计过程,Fortify 软件安全研究团队开发了 Data Validation(数据验证)项目模板,该模板根据应用于输入源的验证机制按文件夹对问题进行了分组。
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 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[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 - Security Technical Implementation Guide Version 6.1 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.kotlin.cross_site_scripting_poor_validation
Abstract
使用 HTML、XML 或其他类型的编码并不总是能够防止恶意代码访问 Web 浏览器。
Explanation
使用特定的编码构造(例如 ESAPI 或 AntiXSS)能避免一部分跨站脚本攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码构造等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便应用了编码,Fortify Static Code Analyzer(Fortify 静态代码分析器)仍会报告发现跨站点脚本攻击,并将其显示为“Cross-Site Scripting: Poor Validation”问题。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入网页。对于 Reflected XSS,不可信赖的数据源通常为用户组件、URL 方案处理程序或通知,而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2. 未检验包含在动态内容中的数据,便将其传送给了 UIWebView 组件。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
以下的示例突出显示了使用编码 API 进行编码的可利用的 XSS 实例:
示例 1:下面的 Objective-C 代码片段会读取传递至并调用应用程序 (
如同
正如例子中所显示的,XSS 漏洞是由于 HTTP 内容中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
- 如
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入网页。对于 Reflected XSS,不可信赖的数据源通常为用户组件、URL 方案处理程序或通知,而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2. 未检验包含在动态内容中的数据,便将其传送给了 UIWebView 组件。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
以下的示例突出显示了使用编码 API 进行编码的可利用的 XSS 实例:
示例 1:下面的 Objective-C 代码片段会读取传递至并调用应用程序 (
myapp://input_to_the_application
) 的自定义 URL 方案的文本部分。然后,该 URL 中不受信赖的数据将用于呈现 UIWebView 组件中的 HTML 输出。
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
...
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSString *htmlPage = [NSString stringWithFormat: @"%@/%@/%@", @"...<input type=text onclick=\"callFunction('",
[DefaultEncoder encodeForHTML:partAfterSlashSlash],
@"')\" />"];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:htmlPage baseURL:nil];
...
如同
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,此代码可能看起来不太危险,因为 name
的值是从数据库中读取的,而且采用了 HTML 编码。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。攻击者提供的漏洞可能会绕过编码的字符或在不受 HTML 编码影响的环境中输入信息。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。正如例子中所显示的,XSS 漏洞是由于 HTTP 内容中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
中所示,数据会直接从自定义 URL 方案中读取,并反馈回 UIWebView 响应的内容中。当攻击者诱使用户为易受攻击的 iOS 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行,就会发生 Reflected XSS 漏洞利用。传递恶意内容的最常见机制是,将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的自定义方案 URL 中。以这种手段构造的 URL 构成了多种“网络钓鱼”(phishing) 阴谋的核心,攻击者借此诱骗受害者访问指向易受攻击应用程序的 URL。该应用程序将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。- 如
Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] W/Labs Continued Adventures with iOS UIWebViews
[4] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 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.objc.cross_site_scripting_poor_validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定的编码函数(例如
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:下面的代码片段会从 HTTP 请求中读取
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
— 应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被回写到应用程序中,并包含在动态内容中。Persistent XSS 盗取发生在如下情况:攻击者将危险内容注入到数据存储器中,且该存储器之后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于一个面向许多用户,尤其是相关用户显示的区域。相关用户通常在应用程序中具备较高的特权,或相互之间交换敏感数据,这些数据对攻击者来说有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人所有的敏感数据的访问权限。
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
htmlspecialchars()
或 htmlentities()
)能避免一部分 cross-site scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外(仅当已设置 ENT_QUOTES
时),其他字符可能具有元意。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便进行了编码,Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:下面的代码片段会从 HTTP 请求中读取
text
参数,使用 HTML 加以编码,并将该参数显示在脚本标签之间的警报框中。
<?php
$var=$_GET['text'];
...
$var2=htmlspecialchars($var);
echo "<script>alert('$var2')</script>";
?>
如果
text
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 text
具有单引号、圆括号和分号,则会结束 alert
文本框,之后将执行代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。— 应用程序将危险数据存储在数据库或其他可信赖的数据存储器中。这些危险数据随后会被回写到应用程序中,并包含在动态内容中。Persistent XSS 盗取发生在如下情况:攻击者将危险内容注入到数据存储器中,且该存储器之后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于一个面向许多用户,尤其是相关用户显示的区域。相关用户通常在应用程序中具备较高的特权,或相互之间交换敏感数据,这些数据对攻击者来说有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人所有的敏感数据的访问权限。
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.php.cross_site_scripting_poor_validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定编码函数能避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便进行了编码,Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:下面的代码片段在 HTTP 请求中读取雇员 ID
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:下面的代码片段根据给定的雇员 ID 查询数据库,并打印采用 URL 编码的相应雇员姓名。
如同
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
- 如
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:下面的代码片段在 HTTP 请求中读取雇员 ID
eid
,对其进行 URL 编码,并将其显示给用户。
...
-- 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: ' || HTMLDB_UTIL.url_encode(eid) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
如果
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:下面的代码片段根据给定的雇员 ID 查询数据库,并打印采用 URL 编码的相应雇员姓名。
...
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: ' || HTMLDB_UTIL.url_encode(name) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
如同
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。- 如
Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.sql.cross_site_scripting_poor_validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定编码函数能避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便进行了编码,Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:下面的 Python 代码片段在 HTTP 请求中读取雇员 ID
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:下面的 Python 代码片段根据给定的雇员 ID 查询数据库,并打印采用 HTML 编码的相应雇员姓名。
如同
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
- 如
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:下面的 Python 代码片段在 HTTP 请求中读取雇员 ID
eid
,对其进行 HTML 编码,并将其显示给用户。
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + escape(eid))
如果
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:下面的 Python 代码片段根据给定的雇员 ID 查询数据库,并打印采用 HTML 编码的相应雇员姓名。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + escape(row["emp"]))
...
如同
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。- 如
Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.python.cross_site_scripting_poor_validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定编码函数能避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便进行了编码,Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 Ruby 代码片段可在 HTTP 请求中读取雇员 ID
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种利用易受攻击的 Web 应用程序的机制称为 Reflected XSS,但请注意,如果按
示例 2:以下 Ruby 代码片段可在数据库中查询具有给定 ID 的雇员,并输出采用 HTML 编码的相应雇员姓名。
如同
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
- 如
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 Ruby 代码片段可在 HTTP 请求中读取雇员 ID
eid
,对其进行 HTML 编码,并将其显示给用户。
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
如果
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种利用易受攻击的 Web 应用程序的机制称为 Reflected XSS,但请注意,如果按
Example 1
所示使用 Rack::Request#params()
,则会看到 GET
和 POST
这两个参数,因此可能很容易受到各种类型的攻击,而不仅仅是将恶意代码附加到 URL 中。示例 2:以下 Ruby 代码片段可在数据库中查询具有给定 ID 的雇员,并输出采用 HTML 编码的相应雇员姓名。
...
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
...
如同
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行适当的输入验证,那么攻击者就可能在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。- 如
Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.ruby.cross_site_scripting_poor_validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定的编码构造能避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码构造等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便应用了编码,Fortify Static Code Analyzer(Fortify 静态代码分析器)仍会报告发现跨站点脚本攻击,并将其显示为“Cross-Site Scripting: Poor Validation”问题。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 Play 控制器代码片段从 HTTP 请求中读取雇员 ID(即
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源大多数情况下为 Web 请求;而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库查询的结果。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 Play 控制器代码片段从 HTTP 请求中读取雇员 ID(即
eid
),并将其显示给用户。
def getEmployee = Action { implicit request =>
var eid = request.getQueryString("eid")
eid = StringEscapeUtils.escapeHtml(eid); // insufficient validation
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
如果
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] INJECT-3: XML and HTML generation requires care Oracle
[4] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 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.scala.cross_site_scripting_poor_validation
Abstract
使用 HTML、XML 或其他类型的编码并不总是能够防止恶意代码访问 Web 浏览器。
Explanation
使用特定的编码构造(例如 ESAPI 或 AntiXSS)能避免一部分,跨站脚本攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码构造等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便应用了编码,Fortify Static Code Analyzer(Fortify 静态代码分析器)仍会报告发现跨站点脚本攻击,并将其显示为“Cross-Site Scripting: Poor Validation”问题。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入网页。对于 Reflected XSS,不可信赖的数据源通常为用户组件、URL 方案处理程序或通知,而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2. 未检验包含在动态内容中的数据,便将其传送给了 UIWebView 组件。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
以下的示例突出显示了使用编码 API 进行编码的可利用的 XSS 实例:
示例 1:下面的 Swift 代码片段会读取传递至并调用应用程序 (
如同
示例 3:以下代码可读取 UITextField 的内容并在 WKWebView 内将其显示给用户:
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己设备上运行的内容呢?真正的危险在于,攻击者可能会使用电子邮件或社交工程手段引诱受害者执行此类操作。此诡计得逞后,受害者会不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的设备中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
正如例子中所显示的,XSS 漏洞是由于 HTTP 内容中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
- 如
- 如
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入网页。对于 Reflected XSS,不可信赖的数据源通常为用户组件、URL 方案处理程序或通知,而对于 Persistent(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2. 未检验包含在动态内容中的数据,便将其传送给了 UIWebView 组件。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
以下的示例突出显示了使用编码 API 进行编码的可利用的 XSS 实例:
示例 1:下面的 Swift 代码片段会读取传递至并调用应用程序 (
myapp://input_to_the_application
) 的自定义 URL 方案的文本部分。然后,该 URL 中不受信赖的数据将用于呈现 UIWebView 组件中的 HTML 输出。
...
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
}
...
如同
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,此代码可能看起来不太危险,因为 name
的值是从数据库中读取的,而且采用了 HTML 编码。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。攻击者提供的漏洞可能会绕过编码的字符或在不受 HTML 编码影响的环境中输入信息。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。示例 3:以下代码可读取 UITextField 的内容并在 WKWebView 内将其显示给用户:
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
如果
inputTextField
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 inputTextField
中的文本包括元字符或源代码,那么可以由 Web 浏览器在显示 HTTP 响应的过程中以代码方式执行输入。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己设备上运行的内容呢?真正的危险在于,攻击者可能会使用电子邮件或社交工程手段引诱受害者执行此类操作。此诡计得逞后,受害者会不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的设备中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
正如例子中所显示的,XSS 漏洞是由于 HTTP 内容中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
中所示,数据会直接从自定义 URL 方案中读取,并反馈回 UIWebView 响应的内容中。当攻击者诱使用户为易受攻击的 iOS 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行,就会发生 Reflected XSS 漏洞利用。传递恶意内容的最常见机制是,将其作为参数包含在公开发布或通过电子邮件直接发送给受害者的自定义方案 URL 中。以这种手段构造的 URL 构成了多种“网络钓鱼”(phishing) 阴谋的核心,攻击者借此诱骗受害者访问指向易受攻击应用程序的 URL。该应用程序将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。- 如
Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。- 如
Example 3
中所示,目标应用程序外部的源使用目标应用程序的自定义 URL 方案发出 URL 请求,该 URL 请求中未经验证的数据随后作为可信数据读回应用程序并包含在动态内容中。References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] W/Labs Continued Adventures with iOS UIWebViews
[4] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 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.swift.cross_site_scripting_poor_validation
Abstract
依靠 HTML、XML 和其他类型的编码来验证用户输入可能会导致浏览器执行恶意代码。
Explanation
使用特定编码函数能避免一部分 Cross-Site Scripting 攻击,但不能完全避免。根据数据出现的上下文,除 HTML 编码的基本字符 <、>、& 和 " 以及 XML 编码的字符 <、>、&、" 和 ' 之外,其他字符可能具有元意。依靠此类编码函数等同于用一个安全性较差的拒绝列表来防止 cross-site scripting 攻击,并且可能允许攻击者注入恶意代码,并在浏览器中加以执行。由于不可能始终准确地确定静态显示数据的上下文,因此即便进行了编码,Fortify 安全编码规则包仍会报告 Cross-Site Scripting 结果,并将其显示为 Cross-Site Scripting: Poor Validation 问题。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 ASP 代码片段可在 HTTP 请求中读取雇员 ID
如果
起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:以下 ASP 代码片段可在数据库中查询具有给定 ID 的雇员,并输出采用 HTML 编码的相应雇员姓名。
如同
正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
- 如
— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
Cross-Site Scripting (XSS) 漏洞在以下情况下发生:
1. 数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS,不可信赖的数据源通常为 Web 请求,而对于 Persisted(也称为 Stored)XSS,该数据源通常为数据库或其他后端数据存储。
2.未经验证但包含在动态内容中的数据将传送给 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 片段的形式,但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出,几乎是无穷无尽的,但通常它们都会包含传输给攻击者的私有数据(如 Cookie 或者其他会话信息)。在攻击者的控制下,指引受害者进入恶意的网络内容;或者利用易受攻击的站点,对用户的机器进行其他恶意操作。
示例 1:以下 ASP 代码片段可在 HTTP 请求中读取雇员 ID
eid
,对其进行 HTML 编码,并将其显示给用户。
...
eid = Request("eid")
Response.Write "Employee ID:" & Server.HTMLEncode(eid) & "<br/>"
..
如果
eid
只包含标准的字母或数字文本,这个例子中的代码就能正确运行。如果 eid
中的某个值包含元字符或源代码,则 Web 浏览器就会在显示 HTTP 响应时执行该代码。起初,这个例子似乎是不会轻易遭受攻击的。毕竟,有谁会输入导致恶意代码在自己电脑上运行的 URL 呢?真正的危险在于攻击者会创建恶意的 URL,然后采用电子邮件或社交工程的欺骗手段诱使受害者访问此 URL 的链接。当受害者单击这个链接时,他们不知不觉地通过易受攻击的网络应用程序,将恶意内容带到了自己的电脑中。这种对易受攻击的 Web 应用程序进行盗取的机制通常被称为反射式 XSS。
示例 2:以下 ASP 代码片段可在数据库中查询具有给定 ID 的雇员,并输出采用 HTML 编码的相应雇员姓名。
...
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:" & Server.HTMLEncode(objADORecordSet("name"))
objADORecordSet.MoveNext
Wend
...
如同
Example 1
,如果对 name
的值处理得当,该代码就能正常地执行各种功能;如若处理不当,就会对代码的漏洞利用行为无能为力。同样,这段代码看似没那么危险,因为 name
的值是从数据库中读取的,而且这些内容显然是由应用程序管理的。然而,如果 name
的值来自用户提供的数据,数据库就会成为恶意内容传播的通道。如果不对数据库中存储的所有数据进行恰当的输入验证,那么攻击者就可以在用户的 Web 浏览器中执行恶意命令。这种类型的漏洞利用称为 Persistent XSS(或 Stored XSS),它极其隐蔽,因为数据存储导致的间接行为会增大辨别威胁的难度,并使多个用户受此攻击影响的可能性提高。XSS 盗取会从访问提供留言簿 (guestbook) 的网站开始。攻击者会在这些留言簿的条目中嵌入 JavaScript,接下来所有访问该留言簿页面的访问者都会执行这些恶意代码。正如例子中所显示的,XSS 漏洞是由于 HTTP 响应中包含了未经验证的数据代码而引起的。受害者遭受 XSS 攻击的途径有三种:
- 如
Example 1
中所示,系统从 HTTP 请求中直接读取数据,并在 HTTP 响应中返回数据。当攻击者诱使用户为易受攻击的 Web 应用程序提供危险内容,而这些危险内容随后会反馈给用户并在 Web 浏览器中执行时,就会发生 Reflected XSS 漏洞利用。发送恶意内容最常用的方法是,将恶意内容作为一个参数包含在公开发布或通过电子邮件直接发送给受害者的 URL 中。以这种手段构造的 URL 已成为多种网络钓鱼阴谋的核心,攻击者会借此诱骗受害者访问指向易受攻击站点的 URL。该站点将攻击者的内容反馈给受害者后,便会执行这些内容,接下来会将用户计算机中的各种私密信息(比如可能包含会话信息的 Cookie)传输给攻击者,或者执行其他恶意活动。- 如
Example 2
中所示,应用程序将危险数据存储在数据库或其他可信赖的数据存储中。这些危险数据随后会被读回到应用程序中,并包含在动态内容中。在以下情况下会发生 Persistent XSS 漏洞利用:攻击者将危险内容注入到数据存储中,而这些危险内容随后会被读取并包含在动态内容中。从攻击者的角度看,注入恶意内容的最佳位置莫过于显示给许多用户或显示给特定相关用户的区域。这些相关用户通常在应用程序中具备较高的特权,或者可以与敏感数据交互,这些数据对攻击者来说具有利用价值。如果某一个用户执行了恶意内容,攻击者就有可能以该用户的名义执行某些需要特权的操作,或者获得该用户个人敏感数据的访问权。— 应用程序之外的数据源将危险数据储存在一个数据库或其他数据存储器中,随后这些危险数据被当作可信赖的数据回写到应用程序中,并储存在动态内容中。
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[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 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.vb.cross_site_scripting_poor_validation