界: Input Validation and Representation
輸入驗證和表示法問題是由中繼字元、替代編碼和數值表示法引起的。信任輸入會導致安全問題。問題包括:「Buffer Overflows」、「Cross-Site Scripting」攻擊、「SQL Injection」及其他許多問題。
Cross-Site Scripting: Reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 ABAP 程式碼片段會從 HTTP 要求中讀取員工的識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的 ABAP 程式碼片段會根據所給予的識別碼在資料庫中查詢員工,並列印該員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 ABAP 程式碼片段會從 HTTP 要求中讀取員工的識別碼
eid
,並將識別碼顯示給使用者。
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的 ABAP 程式碼片段會根據所給予的識別碼在資料庫中查詢員工,並列印該員工姓名。
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...
如
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 79, CWE ID 80
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[18] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[19] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[20] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2021 A03 Injection
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[62] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.abap.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
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 程式碼片段會根據所給予的識別碼在資料庫中查詢員工,並列印該員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 ActionScript 程式碼片段會從 HTTP 要求中讀取員工的識別碼
eid
,並將識別碼顯示給使用者。
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 ActionScript 程式碼片段會根據所給予的識別碼在資料庫中查詢員工,並列印該員工姓名。
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + name;
}
如
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 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - 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.actionscript.cross_site_scripting_reflected
Abstract
將未經驗證的資料傳送到網頁瀏覽器可能會導致執行惡意程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入 Web 應用程式。如果是 Reflected XSS,不可信賴的來源大多為 Web 要求;如果是 Persistent XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
惡意內容通常為 JavaScript 程式碼片段,但也可以是 HTML、Flash 或瀏覽器可執行的任何其他作用中內容。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 Visualforce 程式碼片段會讀取 HTTP 要求參數
此範例中的程式碼旨在僅接收英數文字並加以顯示。但是,如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 Apex 程式碼片段會在資料庫中查詢具有指定 ID 的聯絡人名稱並傳回對應的員工姓名 (之後由 Visualforce 程式碼進行列印)。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。有兩種途徑可執行 XSS 攻擊:
- 如
- 如
1. 資料從一個不可信賴的來源進入 Web 應用程式。如果是 Reflected XSS,不可信賴的來源大多為 Web 要求;如果是 Persistent XSS (也可稱為 Stored XSS),來源大多為資料庫查詢結果。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
惡意內容通常為 JavaScript 程式碼片段,但也可以是 HTML、Flash 或瀏覽器可執行的任何其他作用中內容。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 Visualforce 程式碼片段會讀取 HTTP 要求參數
username
,並向使用者顯示。
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
此範例中的程式碼旨在僅接收英數文字並加以顯示。但是,如果
username
包含中繼字元或來源程式碼,則會由網頁瀏覽器執行。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 Apex 程式碼片段會在資料庫中查詢具有指定 ID 的聯絡人名稱並傳回對應的員工姓名 (之後由 Visualforce 程式碼進行列印)。
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
如
Example 1
所述,對 name
的值進行明確界定時 (例如,僅英數字元),此程式碼會正常運作,但無法檢查惡意資料。即使該值讀取自資料庫,也應該對其進行適當驗證,因為資料庫的內容可能源自於使用者提供的資料。這樣一來,攻擊者可以在使用者的網頁瀏覽器中執行惡意指令,而無需與受害者進行互動 (類似於 Reflected XSS)。此類攻擊稱為 Stored XSS (或 Persistent XSS),可能非常難以偵測,因為資料是以間接方式提供給易受攻擊的函數,並且由於影響多個使用者的可能性,此類攻擊的影響會更強烈。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。有兩種途徑可執行 XSS 攻擊:
- 如
Example 1
所述,會從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者將危險內容傳遞至易受攻擊的 Web 應用程式,然後回傳給使用者並透過其瀏覽器執行時,會出現 Reflected XSS。傳遞惡意內容最常用的機制就是,將惡意內容當作參數包含在公開發佈的 URL 中,或者以電子郵件方式直接傳送給受害者。透過此方式修改的 URL 是許多釣魚架構的核心,其中攻擊者會誘騙受害者造訪該 URL。當網站回傳內容給使用者後便會加以執行,並且可執行多個動作,例如轉送隱私、敏感的資訊、在受害者電腦上執行未經授權的作業等。- 如
Example 2
所述,資料庫或其他資料儲存區會向應用程式提供將包含在動態內容中的危險資料。從攻擊者的角度來看,儲存惡意內容的最佳位置是可供所有使用者 (尤其是擁有較高權限的使用者) 存取的區域,這些使用者更有可能會處理敏感資訊或執行關鍵作業。References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Salesforce Developers Technical Library Secure Coding Guidelines - Cross Site Scripting
[4] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - 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.apex.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 ASP.NET 網頁表單會從 HTTP 要求讀取員工識別碼,然後顯示給使用者。
其中,
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL? 真正的危險是攻擊者會建立惡意的 URL,然後使用電子郵件或社交工程技倆來誘騙受害者按下連結。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 3:以下的 ASP.NET 網頁表單使用指定的員工識別碼向資料庫查詢員工,並列印出與識別碼相對應的名字。
其中,
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 ASP.NET 要求驗證和 WCF)。為了突顯未驗證的輸入來源,Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性,並在使用框架驗證機制時提供支援證據的指標,以動態重新排列其優先順序。如果是 ASP.NET 要求驗證,我們也會針對何時明確停用驗證提供證據。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序,Fortify Software 安全研發團隊提供了資料驗證專案範本,該範本會依據套用到其輸入來源的驗證機制,按資料夾對問題進行分組。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 ASP.NET 網頁表單會從 HTTP 要求讀取員工識別碼,然後顯示給使用者。
<script runat="server">
...
EmployeeID.Text = 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 = Login.Text;
如果
Login
只包含標準英數字元,則這些範例中的程式碼都會正確地運作。如果 Login
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL? 真正的危險是攻擊者會建立惡意的 URL,然後使用電子郵件或社交工程技倆來誘騙受害者按下連結。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 3:以下的 ASP.NET 網頁表單使用指定的員工識別碼向資料庫查詢員工,並列印出與識別碼相對應的名字。
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>
其中,
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 = 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 79, CWE ID 80
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - 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.dotnet.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2. 在未對包含資料的動態內容進行驗證的情況下,便將其傳送至某個網路瀏覽器。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1: 以下的程式碼片段在 HTML 表單中讀取員工的識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2: 以下的程式碼片段,根據所給予的識別碼在資料庫中查詢員工,並列印該員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2. 在未對包含資料的動態內容進行驗證的情況下,便將其傳送至某個網路瀏覽器。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1: 以下的程式碼片段在 HTML 表單中讀取員工的識別碼
EID
,並顯示給使用者。
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
如果
EID
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 EID
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2: 以下的程式碼片段,根據所給予的識別碼在資料庫中查詢員工,並列印該員工姓名。
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
如
Example 1
所述,ENAME
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 ENAME
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 ENAME
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這種類型的攻擊,被稱作 Stored XSS,是特別狡詐的,因為間接的資料儲存方式使得該威脅難以辨別,而且提高了該攻擊會影響到多個使用者的可能性。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從 HTML 表單中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。- 如
Example 2
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。當攻擊者有以下情況時,Stored 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 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - 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.cobol.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1: 以下的 CFML 程式碼片段,會從網路表單中讀取員工識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2: 以下的 CFML 程式碼片段,根據提供的員工識別碼來查詢資料庫,並列印出該員工的相應姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1: 以下的 CFML 程式碼片段,會從網路表單中讀取員工識別碼
eid
,並將其顯示給使用者。
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
如果
Form.eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 Form.eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2: 以下的 CFML 程式碼片段,根據提供的員工識別碼來查詢資料庫,並列印出該員工的相應姓名。
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
如
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] ColdFusion Developer Center: Security Macromedia
[4] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - 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.cfml.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網頁瀏覽器,會導致瀏覽器執行惡意程式碼。
Explanation
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 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料存放區中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
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: ", 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: ", 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 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - 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.golang.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted 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 安全研發團隊提供了資料驗證專案範本,該範本會依據套用到其輸入來源的驗證機制,按資料夾對問題進行分組。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 JSP 程式碼片段會從 HTTP 要求中讀取員工識別碼
eid
,並將其向使用者顯示。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 JSP 程式碼片段會在資料庫中查詢具有指定識別碼的員工,並列印相應的員工姓名。
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>
如
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(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 79, CWE ID 80
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[21] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2021 A03 Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[38] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[39] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.java.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 Node.js 程式碼片段會在 HTTP 要求中讀取員工識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 Node.js 程式碼片段會根據所給予的識別碼在資料庫中查詢員工,並列印對應員工的姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 Node.js 程式碼片段會在 HTTP 要求中讀取員工識別碼
eid
,並顯示給使用者。
var http = require('http');
var url = require('url');
...
function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 Node.js 程式碼片段會根據所給予的識別碼在資料庫中查詢員工,並列印對應員工的姓名。
var http = require('http');
...
function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);
如
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 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - 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.javascript.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-Site Scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料存放區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下程式碼會從 HTTP servlet 要求讀取員工識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的程式碼片段,會根據所給予的識別碼在資料庫中查詢員工,並在 servlet 的回應中列印對應的員工姓名。
如
有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 3:以下程式碼會在 Android 的 WebView 中啟用 JavaScript (JavaScript 預設為停用),並根據從 Android 用意接收的值載入頁面。
若
如同範例中所示,XSS 弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 如
有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Spring MVC)。為了突顯未驗證的輸入來源,Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性,並在使用框架驗證機制時提供支援證據的指標,以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序,Fortify Software 安全研發團隊提供了資料驗證專案範本,該範本會依據套用到其輸入來源的驗證機制,按資料夾對問題進行分組。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料存放區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下程式碼會從 HTTP servlet 要求讀取員工識別碼
eid
,然後在 servlet 的回應中向使用者顯示其值。
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的程式碼片段,會根據所給予的識別碼在資料庫中查詢員工,並在 servlet 的回應中列印對應的員工姓名。
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
如
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(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 79, CWE ID 80
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[21] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2021 A03 Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[38] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[39] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.kotlin.cross_site_scripting_reflected
Abstract
這個方法會傳送未經驗證的資料到網路瀏覽器會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入網頁。在 Reflected XSS 案例中,不可信賴的來源通常為使用者元件、URL 架構處理常式或通知,而在 Persistent XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2. 在未對包含資料的動態內容進行驗證的情況下,便將其傳送至某個 UIWebView 元件。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 Objective-C 程式碼片段會讀取自訂 URL 架構的文字部份,其會被傳送至應用程式 (
如
如同範例中所示,XSS 的弱點是由 HTTP 內容中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
1. 資料從一個不可信賴的來源進入網頁。在 Reflected XSS 案例中,不可信賴的來源通常為使用者元件、URL 架構處理常式或通知,而在 Persistent XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2. 在未對包含資料的動態內容進行驗證的情況下,便將其傳送至某個 UIWebView 元件。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 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];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
如
Example 1
所述,name
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 name
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 name
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 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] MWR Labs Continued Adventures with iOS UIWebViews
[4] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - 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.objc.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 PHP 程式碼片段會從 HTTP 要求中讀取員工 ID
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的 PHP 程式碼片段,根據提供的員工識別碼來查詢資料庫,並列印出該員工的相應姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 PHP 程式碼片段會從 HTTP 要求中讀取員工 ID
eid
,並將 ID 顯示給使用者。
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的 PHP 程式碼片段,根據提供的員工識別碼來查詢資料庫,並列印出該員工的相應姓名。
<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>
如
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 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - 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.php.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
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:以下程式碼片段會在資料庫中查詢具有指定識別碼的員工,並列印相應的員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下程式碼片段會從 HTTP 要求中讀取員工識別碼
eid
,並向使用者顯示。
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下程式碼片段會在資料庫中查詢具有指定識別碼的員工,並列印相應的員工姓名。
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
如
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 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - 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.sql.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
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 程式碼片段,根據所給予的識別碼在資料庫中查詢員工,並列印該員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 Python 程式碼片段在 HTTP 要求中讀取員工的識別碼
eid
,並顯示給使用者。
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的 Python 程式碼片段,根據所給予的識別碼在資料庫中查詢員工,並列印該員工姓名。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + 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 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - 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.python.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
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 程式碼片段會查詢資料庫中具有指定識別碼的員工,然後列印相對應的員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 Ruby 程式碼片段會從 HTTP 要求中讀取員工識別碼
eid
,並顯示給使用者。
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 程式碼片段會查詢資料庫中具有指定識別碼的員工,然後列印相對應的員工姓名。
...
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 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - 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.ruby.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 Play 控制項程式碼片段會從 HTTP 要求中讀取員工 ID
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下 Play 控制項程式碼片段會從 HTTP 要求中讀取員工 ID
eid
,並向使用者顯示。
def getEmployee = Action { implicit request =>
val eid = request.getQueryString("eid")
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
如果
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] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[4] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[5] INJECT-3: XML and HTML generation requires care Oracle
[6] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[21] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2021 A03 Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[38] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[39] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.scala.cross_site_scripting_reflected
Abstract
這個方法會傳送未經驗證的資料到網路瀏覽器會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入網頁。在 Reflected XSS 案例中,不可信賴的來源通常為使用者元件、URL 架構處理常式或通知,而在 Persistent XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2. 在未對包含資料的動態內容進行驗證的情況下,便將其傳送至 WKWebView 元件。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下程式碼會讀取 UITextField 的內容,並在 WKWebView 中將其顯示給使用者:
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的裝置上提供會導致惡意程式碼執行的輸入?真正的危險在於攻擊者可能使用電子郵件或社交工程病毒誘騙受害者執行此類動作。當這樣的誘騙成功,受害者就在不知情的情況下,透過易受攻擊的 Web 應用程式,將惡意內容帶回他們自己的裝置。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 Swift 程式碼片段會讀取自訂 URL 架構的文字部分,其會被傳遞到應用程式 (
如
如同範例中所示,XSS 的弱點是由 HTTP 內容中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 如
1. 資料從一個不可信賴的來源進入網頁。在 Reflected XSS 案例中,不可信賴的來源通常為使用者元件、URL 架構處理常式或通知,而在 Persistent XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2. 在未對包含資料的動態內容進行驗證的情況下,便將其傳送至 WKWebView 元件。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下程式碼會讀取 UITextField 的內容,並在 WKWebView 中將其顯示給使用者:
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
如果
inputTextField
中的文字只包含標準英數字元,這個範例中的程式碼便會正常運作而不會有問題。如果 inputTextField
中的文字包括中繼字元或原始程式碼,那麼網路瀏覽器就會像顯示 HTTP 回應那樣,可能會將輸入當成程式碼來執行。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的裝置上提供會導致惡意程式碼執行的輸入?真正的危險在於攻擊者可能使用電子郵件或社交工程病毒誘騙受害者執行此類動作。當這樣的誘騙成功,受害者就在不知情的情況下,透過易受攻擊的 Web 應用程式,將惡意內容帶回他們自己的裝置。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 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 2
所述,name
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 name
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 name
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 的弱點是由 HTTP 內容中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,會直接從使用者可控制的 UI 元件讀取資料,並在 HTTP 回應中傳回資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。- 如
Example 2
所述,目標應用程式以外的來源會使用目標應用程式的自訂 URL 架構提出 URL 要求,之後來自此 URL 要求的未驗證資料會被當作信賴的資料讀回到應用程式,並會包含在動態內容中。- 如
Example 3
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] MWR Labs Continued Adventures with iOS UIWebViews
[4] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - 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.swift.cross_site_scripting_reflected
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
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 程式碼片段會在資料庫中查詢具有指定識別碼的員工,並列印相應的員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 應用程式以外的來源會在資料庫或是其他資料記憶體中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
範例 1:以下的 ASP 程式碼片段會從 HTTP 要求中讀取員工識別碼
eid
,並向使用者顯示。
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下的 ASP 程式碼片段會在資料庫中查詢具有指定識別碼的員工,並列印相應的員工姓名。
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...
如
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 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[18] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - 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.vb.cross_site_scripting_reflected