界: 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 XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 ABAP 程式碼片段在 HTTP 要求中讀取員工的識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的 ABAP 程式碼片段會在資料庫中查詢具有所指定識別碼的員工,並列印相應 HTML 編碼的員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
cl_http_utility=>escape_html
) 可防止部分,但不是所有的 Cross-Site Scripting 攻擊。根據資料出現的內容,以 HTML 編碼的基本 <、>、& 和 ",以及以 XML 編碼的 <、>、&、" 和 ' 以外的字元,可能會有中繼意義。依賴類似編碼函數模組等同於使用安全性較差的拒絕清單來防止 Cross-Site Scripting 攻擊,並且可能會允許攻擊者插入隨後會在瀏覽器中執行的惡意程式碼。因為並非隨時都可以準確識別其中靜態顯示資料的內容,所以即使套用編碼,Fortify Secure Coding Rulepack 還是會報告 Cross-Site Scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入 Web 應用程式。如果是 Reflected XSS,不可信賴的來源大多為 Web 要求;如果是 Persistent XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 ABAP 程式碼片段在 HTTP 要求中讀取員工的識別碼
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
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的 ABAP 程式碼片段會在資料庫中查詢具有所指定識別碼的員工,並列印相應 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
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 Secure Coding Rulepack 還是會報告 Cross-Site Scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 ActionScript 程式碼片段在 HTTP 要求中讀取員工的識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的 ActionScript 程式碼片段會在資料庫中查詢具有所指定識別碼的員工,並列印相應 HTML 編碼的員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 ActionScript 程式碼片段在 HTTP 要求中讀取員工的識別碼
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
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的 ActionScript 程式碼片段會在資料庫中查詢具有所指定識別碼的員工,並列印相應 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
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 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] 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
將未經驗證的資料傳送到網頁瀏覽器可能會導致執行惡意程式碼。
Explanation
由於在使用者提供的資料與網頁瀏覽器解析器之間存在大量可能的互動,因此並非始終都能適當地評估套用的編碼是否足以防範 XSS 弱點。因此,即使套用編碼,並以 Cross-site scripting 來加以顯示,Fortify Static Code Analyzer 還是會報告 Cross-site scripting 發現:Poor Validation 問題。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入 Web 應用程式。如果是 Reflected XSS,不可信賴的來源大多為 Web 要求;如果是 Persistent XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
惡意內容通常為 JavaScript 程式碼片段,但也可以是 HTML、Flash 或瀏覽器可執行的任何其他作用中內容。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 Apex 程式碼片段會在資料庫中查詢具有指定 ID 的聯絡人名稱並傳回對應的員工姓名 (之後由 Visualforce 程式碼進行列印)。
儘管使用
範例 2:以下 Visualforce 程式碼片段會讀取 HTTP 要求參數
此範例中的程式碼旨在僅接收英數文字並加以顯示。但是,如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。有兩種途徑可執行 XSS 攻擊:
- 如
- 如
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入 Web 應用程式。如果是 Reflected XSS,不可信賴的來源大多為 Web 要求;如果是 Persistent XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
惡意內容通常為 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 解析器) 剖析,因此必須進行兩次編碼。這樣一來,攻擊者可以在使用者的網頁瀏覽器中執行惡意指令,而無需與受害者進行互動 (類似於 Reflected XSS)。此類攻擊稱為 Stored XSS (或 Persistent XSS),可能非常難以偵測,因為資料是以間接方式提供給易受攻擊的函數,並且由於影響多個使用者的可能性,此類攻擊的影響會更強烈。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。範例 2:以下 Visualforce 程式碼片段會讀取 HTTP 要求參數
username
,並向使用者顯示。
<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>
此範例中的程式碼旨在僅接收英數文字並加以顯示。但是,如果
username
包含中繼字元或來源程式碼,則會由網頁瀏覽器執行。此外,在此範例中,使用 HTMLENCODE
不足以避免 XSS 攻擊,因為變數由 Javascript 解析器進行處理。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected 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 Secure Coding Rulepack 還是會報告 Cross-Site Scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 ASP.NET 程式碼片段會從 HTTP 要求中讀取員工的識別碼,使用 HTML 加以編碼,並將識別碼顯示給使用者。
其中,
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL? 真正的危險是攻擊者會建立惡意的 URL,然後使用電子郵件或社交工程技倆來誘騙受害者按下連結。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 3:以下的 ASP.NET 程式碼片段使用員工的識別碼來查詢員工資料庫,並列印出與識別碼相對應的 HTML 編碼名字。
其中,
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 ASP.NET 要求驗證和 WCF)。為了突顯未驗證的輸入來源,Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性,並在使用框架驗證機制時提供支援證據的指標,以動態重新排列其優先順序。如果是 ASP.NET 要求驗證,我們也會針對何時明確停用驗證提供證據。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序,Fortify Software 安全研發團隊提供了資料驗證專案範本,該範本會依據套用到其輸入來源的驗證機制,按資料夾對問題進行分組。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 ASP.NET 程式碼片段會從 HTTP 要求中讀取員工的識別碼,使用 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
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL? 真正的危險是攻擊者會建立惡意的 URL,然後使用電子郵件或社交工程技倆來誘騙受害者按下連結。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 3:以下的 ASP.NET 程式碼片段使用員工的識別碼來查詢員工資料庫,並列印出與識別碼相對應的 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
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
和 Example 2
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。- 如
Example 3
和 Example 4
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 ASP.NET 要求驗證和 WCF)。為了突顯未驗證的輸入來源,Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性,並在使用框架驗證機制時提供支援證據的指標,以動態重新排列其優先順序。如果是 ASP.NET 要求驗證,我們也會針對何時明確停用驗證提供證據。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序,Fortify Software 安全研發團隊提供了資料驗證專案範本,該範本會依據套用到其輸入來源的驗證機制,按資料夾對問題進行分組。
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 Secure Coding Rulepack 還是會報告 Cross-Site Scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入 Web 應用程式。如果是 Reflected XSS,不可信賴的來源大多為 Web 要求;如果是 Persistent XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的程式碼片段會從 HTTP 要求中讀取
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料記憶體中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入 Web 應用程式。如果是 Reflected XSS,不可信賴的來源大多為 Web 要求;如果是 Persistent XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的程式碼片段會從 HTTP 要求中讀取
text
參數,使用 HTML 加以編碼,並將該參數顯示在 Script 標籤之間的警示方塊中。
"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";
如果
text
只包含標準英數字元,則這個範例中的程式碼會正確地執行。若 text
具有單引號、小括號及分號,則會結束 alert
文字方塊,並在此後執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 Secure Coding Rulepack 還是會報告 Cross-Site Scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 Go 程式碼片段會從 HTTP 要求中讀取使用者名稱
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 Go 程式碼片段會查詢資料庫中具有指定 ID 的員工,然後列印相對應的員工姓名。
如
如同範例中所示,XSS 弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料存放區中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 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
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected 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
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果沒有對所有儲存在資料庫中的資料進行適當的輸入驗證,那麼攻擊者即可在使用者的網頁瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其極其隱蔽,會因為間接的資料儲存方式而難以辨別該威脅,並會提高影響多個使用者的可能性。XSS 弱點會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所示,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 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] 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 XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 JSP 程式碼片段會從 HTTP 要求中讀取員工識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 JSP 程式碼片段會在資料庫中查詢具有指定識別碼的員工,並透過
如
有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 3:以下程式碼會在 Android 的 WebView 中啟用 JavaScript (預設狀況下停用 JavaScript),並根據從 Android 用意接收的值載入頁面。
若
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 如
有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Struts 2)。為了突顯未驗證的輸入來源,Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性,並在使用框架驗證機制時提供支援證據的指標,以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序,Fortify Software 安全研發團隊提供了資料驗證專案範本,該範本會依據套用到其輸入來源的驗證機制,按資料夾對問題進行分組。
escapeXml="true"
屬性 (預設行為) 的 <c:out/>
標籤能夠防止部分,但非全部的 Cross-Site Scripting 攻擊。根據資料出現的內容,以 HTML 編碼的基本 <、>、& 和 ",以及以 XML 編碼的 <、>、&、" 和 ' 以外的字元,可能會有中繼意義。依賴這類編碼建構等同於使用安全性較差的拒絕清單來防止 Cross-Site Scripting 攻擊,並且可能會允許攻擊者插入隨後會在瀏覽器中執行的惡意程式碼。因為並非隨時都可以準確識別其中靜態顯示資料的內容,所以即使已套用編碼,Fortify Static Code Analyzer 還是會報告 Cross-site scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入 Web 應用程式。如果是 Reflected XSS,不可信賴的來源大多為 Web 要求;如果是 Persistent XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 JSP 程式碼片段會從 HTTP 要求中讀取員工識別碼
eid
,並透過 <c:out/>
標籤將其向使用者顯示。
Employee ID: <c:out value="${param.eid}"/>
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 JSP 程式碼片段會在資料庫中查詢具有指定識別碼的員工,並透過
<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
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 3:以下程式碼會在 Android 的 WebView 中啟用 JavaScript (預設狀況下停用 JavaScript),並根據從 Android 用意接收的值載入頁面。
...
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 內執行。如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。- 如
Example 2
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。- 如
Example 3
所述,應用程式以外的來源會在資料庫或是其他資料儲存區中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Struts 2)。為了突顯未驗證的輸入來源,Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性,並在使用框架驗證機制時提供支援證據的指標,以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序,Fortify Software 安全研發團隊提供了資料驗證專案範本,該範本會依據套用到其輸入來源的驗證機制,按資料夾對問題進行分組。
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 攻擊,並且可能會允許攻擊者插入隨後會在瀏覽器中執行的惡意程式碼。因為並非隨時都可以準確識別其中靜態顯示資料的內容,所以即使套用編碼,並以 Cross-Site Scripting 來加以顯示,Fortify Secure Coding Rulepacks 還是會報告 Cross-Site Scripting 發現:Poor Validation 問題。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在基於 DOM 的 XSS 案例中,會從 URL 參數或瀏覽器內的其他值來讀取資料,並以用戶端程式碼回寫到頁面中。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。在基於 DOM 的 XSS 案例中,一旦受害者的瀏覽器開始剖析 HTML 頁面,就會開始執行惡意內容,且成為建立 DOM (Document Object Model,文件物件模型) 的一部分。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 JavaScript 程式碼片段會從 HTTP 要求中讀取員工識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 直接從 HTTP 要求讀取資料,並直接回傳至 HTTP 回應。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。
- 應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料記憶體中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在基於 DOM 的 XSS 案例中,會從 URL 參數或瀏覽器內的其他值來讀取資料,並以用戶端程式碼回寫到頁面中。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。在基於 DOM 的 XSS 案例中,一旦受害者的瀏覽器開始剖析 HTML 頁面,就會開始執行惡意內容,且成為建立 DOM (Document Object Model,文件物件模型) 的一部分。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 JavaScript 程式碼片段會從 HTTP 要求中讀取員工識別碼
eid
,將識別碼去除,然後顯示給使用者。
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(escape(document.URL.substring(pos,document.URL.length)));
</SCRIPT>
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 直接從 HTTP 要求讀取資料,並直接回傳至 HTTP 回應。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
如
有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 3:以下程式碼會在 Android 的 WebView 中啟用 JavaScript (JavaScript 預設為停用),並根據從 Android 用意接收的值載入頁面。
若
如同範例中所示,XSS 弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 如
有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Spring MVC)。為了突顯未驗證的輸入來源,Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性,並在使用框架驗證機制時提供支援證據的指標,以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序,Fortify Software 安全研發團隊提供了資料驗證專案範本,該範本會依據套用到其輸入來源的驗證機制,按資料夾對問題進行分組。
escapeXml="true"
屬性 (預設行為) 的 <c:out/>
標籤能夠防止部分,但非全部的 Cross-Site Scripting 攻擊。根據資料出現的內容,以 HTML 編碼的基本 <、>、& 和 ",以及以 XML 編碼的 <、>、&、" 和 ' 以外的字元,可能會有中繼意義。依賴這類編碼建構等同於使用安全性較差的拒絕清單來防止 Cross-Site Scripting 攻擊,並且可能會允許攻擊者插入隨後會在瀏覽器中執行的惡意程式碼。因為並非隨時都可以準確識別其中靜態顯示資料的內容,所以即使已套用編碼,Fortify Static Code Analyzer 還是會報告 Cross-site scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。Cross-Site Scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。如果是 Reflected XSS,不可信賴的來源大多為 Web 要求,而如果是 Persistent XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
如
Example 1
所述,name
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 name
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 name
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 3:以下程式碼會在 Android 的 WebView 中啟用 JavaScript (JavaScript 預設為停用),並根據從 Android 用意接收的值載入頁面。
...
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 內執行。如同範例中所示,XSS 弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。- 如
Example 2
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。- 如
Example 3
所述,應用程式以外的來源會在資料庫或是其他資料儲存區中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Spring MVC)。為了突顯未驗證的輸入來源,Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性,並在使用框架驗證機制時提供支援證據的指標,以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序,Fortify Software 安全研發團隊提供了資料驗證專案範本,該範本會依據套用到其輸入來源的驗證機制,按資料夾對問題進行分組。
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 和其他類型的編碼,但通常不足以防止惡意程式碼存取網頁瀏覽器。
Explanation
使用特定編碼建構 (例如 ESAPI 或 AntiXSS) 可防止部分,但不是所有 Cross-Site Scripting 攻擊。根據資料出現的內容,以 HTML 編碼的基本 <、>、&和",以及以 XML 編碼的 <、>、&、"和'以外的字元,可能會有中繼意義。依賴這類編碼建構等同於使用安全性較差的拒絕清單來防止 Cross-Site Scripting 攻擊,並且可能會允許攻擊者插入隨後會在瀏覽器中執行的惡意程式碼。因為並非隨時都可以準確識別其中靜態顯示資料的內容,所以即使已套用編碼,Fortify Static Code Analyzer 還是會報告 Cross-site scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入網頁。在 Reflected XSS 案例中,不可信賴的來源通常為使用者元件、URL 架構處理常式或通知,而在 Persistent XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.在未對包含資料的動態內容進行驗證的情況下,便將其傳送至某個 UIWebView 元件。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
以下範例突顯了可利用的 XSS 實例,其使用編碼 API 進行編碼:
範例 1:以下 Objective-C 程式碼片段會讀取自訂 URL 架構的文字部份,其會被傳送至應用程式 (
如
如同範例中所示,XSS 的弱點是由 HTTP 內容中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入網頁。在 Reflected XSS 案例中,不可信賴的來源通常為使用者元件、URL 架構處理常式或通知,而在 Persistent XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.在未對包含資料的動態內容進行驗證的情況下,便將其傳送至某個 UIWebView 元件。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
以下範例突顯了可利用的 XSS 實例,其使用編碼 API 進行編碼:
範例 1:以下 Objective-C 程式碼片段會讀取自訂 URL 架構的文字部份,其會被傳送至應用程式 (
myapp://input_to_the_application
) 並呼叫之。然後 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
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。攻擊者支援的攻擊可能會略過編碼字元或將輸入置於不受 HTML 編碼影響的環境中。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 的弱點是由 HTTP 內容中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從自訂 URL 架構讀取資料,並反映於 UIWebView 回應內容中。當攻擊者誘使使用者提供危險內容給易受攻擊的 iOS 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 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 XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的程式碼片段會從 HTTP 要求中讀取
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料記憶體中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
htmlspecialchars()
或htmlentities()
) 可防止部分,但不是所有 Cross-Site Scripting 攻擊。根據資料出現的內容,以 HTML 編碼的基本 <、>、&和",以及以 XML 編碼的 <、>、&、"和' (僅限在設定ENT_QUOTES
時) 以外的字元,可能會有中繼意義。依賴這類編碼功能等同於使用安全性較差的拒絕清單來防止 Cross-Site Scripting 攻擊,並且可能會允許攻擊者插入隨後會在瀏覽器中執行的惡意程式碼。因為並非隨時都可以準確識別其中靜態顯示資料的內容,所以即使套用編碼,並以 Cross-Site Scripting 來加以顯示,Fortify Secure Coding Rulepacks 還是會報告 Cross-Site Scripting 發現:Poor Validation 問題。Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入 Web 應用程式。如果是 Reflected XSS,不可信賴的來源大多為 Web 要求;如果是 Persistent XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的程式碼片段會從 HTTP 要求中讀取
text
參數,使用 HTML 加以編碼並將該參數顯示在 Script 標籤之間的警示方塊中。
<?php
$var=$_GET['text'];
...
$var2=htmlspecialchars($var);
echo "<script>alert('$var2')</script>";
?>
如果
text
只包含標準英數字元,則這個範例中的程式碼會正確地執行。若 text
具有單引號、小括號及分號,則會結束 alert
文字方塊,並在此後執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 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 Secure Coding Rulepack 還是會報告 Cross-Site Scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的程式碼片段在 HTTP 要求中讀取員工的識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的程式碼片段,根據所給予的識別碼在資料庫中查詢員工,並列印該 URL 編碼的員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的程式碼片段在 HTTP 要求中讀取員工的識別碼
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
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的程式碼片段,根據所給予的識別碼在資料庫中查詢員工,並列印該 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
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 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] 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 Secure Coding Rulepack 還是會報告 Cross-Site Scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 Python 程式碼片段會從 HTTP 要求中讀取員工識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 Python 程式碼片段會在資料庫中查詢具有指定識別碼的員工,並列印相應 HTML 編碼的員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 Python 程式碼片段會從 HTTP 要求中讀取員工識別碼
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
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 Python 程式碼片段會在資料庫中查詢具有指定識別碼的員工,並列印相應 HTML 編碼的員工姓名。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + escape(row["emp"]))
...
如
Example 1
所述,name
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 name
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 name
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 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] 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 Secure Coding Rulepack 還是會報告 Cross-Site Scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 Ruby 程式碼片段在 HTTP 要求中讀取員工的識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是所謂的 Reflected XSS,不過請注意,如果使用
範例 2:以下的 Ruby 程式碼片段會在資料庫中查詢具有所指定識別碼的員工,並列印相應 HTML 編碼的員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 Ruby 程式碼片段在 HTTP 要求中讀取員工的識別碼
eid
,使用 HTML 加以編碼並顯示給使用者。
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是所謂的 Reflected XSS,不過請注意,如果使用
Example 1
中的的 Rack::Request#params()
,會同時看到 GET
和 POST
參數,所以可能容易受到各種類型的攻擊,而不是只會使惡意程式碼附加到 URL 而已。範例 2:以下的 Ruby 程式碼片段會在資料庫中查詢具有所指定識別碼的員工,並列印相應 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
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 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] 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 還是會報告 Cross-site scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入 Web 應用程式。如果是 Reflected XSS,不可信賴的來源大多為 Web 要求;如果是 Persistent XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 Play 控制項程式碼片段會從 HTTP 要求中讀取員工 ID
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入 Web 應用程式。如果是 Reflected XSS,不可信賴的來源大多為 Web 要求;如果是 Persistent XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 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
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected 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 和其他類型的編碼,但通常不足以防止惡意程式碼存取網頁瀏覽器。
Explanation
使用特定編碼建構 (例如 ESAPI 或 AntiXSS) 可防止部分,但不是所有 Cross-Site Scripting 攻擊。根據資料出現的內容,以 HTML 編碼的基本 <、>、&和",以及以 XML 編碼的 <、>、&、"和'以外的字元,可能會有中繼意義。依賴這類編碼建構等同於使用安全性較差的拒絕清單來防止 Cross-Site Scripting 攻擊,並且可能會允許攻擊者插入隨後會在瀏覽器中執行的惡意程式碼。因為並非隨時都可以準確識別其中靜態顯示資料的內容,所以即使已套用編碼,Fortify Static Code Analyzer 還是會報告 Cross-site scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入網頁。在 Reflected XSS 案例中,不可信賴的來源通常為使用者元件、URL 架構處理常式或通知,而在 Persistent XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2. 在未對包含資料的動態內容進行驗證的情況下,便將其傳送至某個 UIWebView 元件。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
以下範例突顯了可利用的 XSS 實例,其使用編碼 API 進行編碼:
範例 1:以下 Swift 程式碼片段會讀取自訂 URL 架構的文字部分,其會被傳遞到應用程式 (
如
範例 3:以下程式碼會讀取 UITextField 的內容,並在 WKWebView 中將其顯示給使用者:
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的裝置上提供會導致惡意程式碼執行的輸入?真正的危險在於攻擊者可能使用電子郵件或社交工程病毒誘騙受害者執行此類動作。當這樣的誘騙成功,受害者就在不知情的情況下,透過易受攻擊的 Web 應用程式,將惡意內容帶回他們自己的裝置。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
如同範例中所示,XSS 的弱點是由 HTTP 內容中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 如
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入網頁。在 Reflected XSS 案例中,不可信賴的來源通常為使用者元件、URL 架構處理常式或通知,而在 Persistent XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2. 在未對包含資料的動態內容進行驗證的情況下,便將其傳送至某個 UIWebView 元件。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
以下範例突顯了可利用的 XSS 實例,其使用編碼 API 進行編碼:
範例 1:以下 Swift 程式碼片段會讀取自訂 URL 架構的文字部分,其會被傳遞到應用程式 (
myapp://input_to_the_application
) 並呼叫之。然後 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
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。攻擊者支援的攻擊可能會略過編碼字元或將輸入置於不受 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
中的文字包括中繼字元或原始程式碼,那麼網路瀏覽器就會像顯示 HTTP 回應那樣,可能會將輸入當成程式碼來執行。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的裝置上提供會導致惡意程式碼執行的輸入?真正的危險在於攻擊者可能使用電子郵件或社交工程病毒誘騙受害者執行此類動作。當這樣的誘騙成功,受害者就在不知情的情況下,透過易受攻擊的 Web 應用程式,將惡意內容帶回他們自己的裝置。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
如同範例中所示,XSS 的弱點是由 HTTP 內容中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從自訂 URL 架構讀取資料,並反映於 UIWebView 回應內容中。當攻擊者誘使使用者提供危險內容給易受攻擊的 iOS 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 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 Secure Coding Rulepack 還是會報告 Cross-Site Scripting 發現,並將其顯示為 Cross-Site Scripting: Poor Validation 問題。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 ASP 程式碼片段在 HTTP 要求中讀取員工的識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的 ASP 程式碼片段會在資料庫中查詢具有所指定識別碼的員工,並列印相應 HTML 編碼的員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 ASP 程式碼片段在 HTTP 要求中讀取員工的識別碼
eid
,使用 HTML 加以編碼並顯示給使用者。
...
eid = Request("eid")
Response.Write "Employee ID:" & Server.HTMLEncode(eid) & "<br/>"
..
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的 ASP 程式碼片段會在資料庫中查詢具有所指定識別碼的員工,並列印相應 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
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 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] 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