界: Input Validation and Representation
輸入驗證和表示法問題是由中繼字元、替代編碼和數值表示法引起的。信任輸入會導致安全問題。問題包括:「Buffer Overflows」、「Cross-Site Scripting」攻擊、「SQL Injection」及其他許多問題。
Cross-Site Scripting: Inter-Component Communication
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 或行動應用程式。在 Inter-Component Communication XSS 案例中,不可信賴的來源為同一系統上其他元件所接收的資料。在行動環境中,這些是指在同一裝置上執行的應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 1:以下 ASP.NET 程式碼片段會從 HTTP 要求中讀取員工 ID
其中,
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 ASP.NET 程式碼片段會在資料庫中查詢具有指定 ID 的員工,並列印相應的員工姓名。
其中,
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Struts 2)。為了突顯未驗證的輸入來源,Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性,並在使用框架驗證機制時提供支援證據的指標,以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序,Fortify Software 安全研發團隊提供了資料驗證專案範本,該範本會依據套用到其輸入來源的驗證機制,按資料夾對問題進行分組。
1.資料從一個不可信賴的來源進入 Web 或行動應用程式。在 Inter-Component Communication XSS 案例中,不可信賴的來源為同一系統上其他元件所接收的資料。在行動環境中,這些是指在同一裝置上執行的應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 1:以下 ASP.NET 程式碼片段會從 HTTP 要求中讀取員工 ID
eid
,並向使用者顯示。
String eid = Request["eid"];
...
EmployeeID.Text = eid;
其中,
EmployeeID
是定義如下的伺服器端 ASP.NET 控制項:
<form runat="server">
...
<asp:Label id="EmployeeID" runat="server"/>
...
</form>
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 2:以下 ASP.NET 程式碼片段會在資料庫中查詢具有指定 ID 的員工,並列印相應的員工姓名。
...
string name = "";
using (SqlConnection conn = new SqlConnection(_ConnectionString))
{
string eid = Request["eid"];
SqlCommand cmd = new SqlCommand("SELECT * FROM emp WHERE id = @id", conn);
cmd.Parameters.AddWithValue("@id", eid);
conn.Open();
SqlDataReader objReader = cmd.ExecuteReader();
while (objReader.Read())
{
name = objReader["name"];
}
objReader.Close();
}
...
EmployeeName.Text = name;
其中,
EmployeeName
是定義如下的伺服器端 ASP.NET 控制項:
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server"/>
...
</form>
如
Example 2
所述,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 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Struts 2)。為了突顯未驗證的輸入來源,Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性,並在使用框架驗證機制時提供支援證據的指標,以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序,Fortify Software 安全研發團隊提供了資料驗證專案範本,該範本會依據套用到其輸入來源的驗證機制,按資料夾對問題進行分組。
References
[1] Anti-Cross Site Scripting Library MSDN
[2] Understanding Malicious Content Mitigation for Web Developers CERT
[3] HTML 4.01 Specification W3
[4] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin Attacks on WebView in the Android System
[5] Erika Chin and David Wagner Bifocals: Analyzing WebView Vulnerabilities in Android Applications
[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 Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[21] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[22] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2021 A03 Injection
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[36] 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
[37] 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
[38] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.dotnet.cross_site_scripting_inter_component_communication
Abstract
傳送未經驗證的資料至網頁瀏覽器,會導致瀏覽器執行惡意程式碼。
Explanation
Cross-Site Scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Inter-Component Communication XSS 案例中,不可信賴的來源為同一系統上其他元件所接收的資料。在 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 應用程式。在 Inter-Component Communication XSS 案例中,不可信賴的來源為同一系統上其他元件所接收的資料。在 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 Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[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.golang.cross_site_scripting_inter_component_communication
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 或行動應用程式。在 Inter-Component Communication XSS 案例中,不可信賴的來源為同一系統上其他元件所接收的資料。在行動環境中,這些是指在同一裝置上執行的應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 1:以下程式碼會在 Android 的 WebView 中啟用 JavaScript (預設狀況下停用 JavaScript),並根據從 Android 用意接收的值載入頁面。
若
範例 2:以下 JSP 程式碼片段會從 HTTP 要求中讀取員工識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 3:以下 JSP 程式碼片段會在資料庫中查詢具有指定識別碼的員工,並列印相應的員工姓名。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 如
有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Struts 2)。為了突顯未驗證的輸入來源,Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性,並在使用框架驗證機制時提供支援證據的指標,以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序,Fortify Software 安全研發團隊提供了資料驗證專案範本,該範本會依據套用到其輸入來源的驗證機制,按資料夾對問題進行分組。
1.資料從一個不可信賴的來源進入 Web 或行動應用程式。在 Inter-Component Communication XSS 案例中,不可信賴的來源為同一系統上其他元件所接收的資料。在行動環境中,這些是指在同一裝置上執行的應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 1:以下程式碼會在 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 內執行。範例 2:以下 JSP 程式碼片段會從 HTTP 要求中讀取員工識別碼
eid
,並將其向使用者顯示。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
如果
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 3:以下 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 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
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。有許多現代的 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 Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[21] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[22] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2021 A03 Injection
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[36] 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
[37] 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
[38] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.java.cross_site_scripting_inter_component_communication
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-Site Scripting (XSS) 弱點會在以下情況中出現:
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Inter-Component Communication XSS 案例中,不可信賴的來源為同一系統上其他元件所接收的資料。在行動環境中,這些是指在同一裝置上執行的應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料存放區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 1:以下程式碼會在 Android 的 WebView 中啟用 JavaScript (JavaScript 預設為停用),並根據從 Android 用意接收的值載入頁面。
若
範例 2:以下程式碼會從 HTTP servlet 要求讀取員工識別碼
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的電腦中輸入會執行惡意程式碼的 URL?其實,真正的危險在於攻擊者會建立惡意的 URL,接著使用電子郵件或社交工程病毒誘騙受害者透過連結前往該 URL。當受害者按下該連結時,他們即不知不覺地透過易受攻擊的 Web 應用程式,將惡意內容資訊帶回他們自己的電腦。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 3:以下的程式碼片段,會根據所給予的識別碼在資料庫中查詢員工,並在 servlet 的回應中列印對應的員工姓名。
如
如同範例中所示,XSS 弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 如
有許多現代的 Web 架構提供執行使用者輸入驗證的機制 (包括 Struts 和 Spring MVC)。為了突顯未驗證的輸入來源,Fortify 安全編碼檢查規則會降低 Fortify Static Code Analyzer 所報告之問題的攻擊可能性,並在使用框架驗證機制時提供支援證據的指標,以動態重新排列其優先順序。我們將此功能稱為「內容相關性排名」。為了進一步協助 Fortify 使用者進行稽核程序,Fortify Software 安全研發團隊提供了資料驗證專案範本,該範本會依據套用到其輸入來源的驗證機制,按資料夾對問題進行分組。
1.資料從一個不可信賴的來源進入 Web 應用程式。在 Inter-Component Communication XSS 案例中,不可信賴的來源為同一系統上其他元件所接收的資料。在行動環境中,這些是指在同一裝置上執行的應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料存放區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 1:以下程式碼會在 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 內執行。範例 2:以下程式碼會從 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。
範例 3:以下的程式碼片段,會根據所給予的識別碼在資料庫中查詢員工,並在 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 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
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。有許多現代的 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 Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[21] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[22] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[25] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[26] Standards Mapping - OWASP Top 10 2021 A03 Injection
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[36] 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
[37] 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
[38] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.kotlin.cross_site_scripting_inter_component_communication
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入 Web 或行動應用程式。在 Inter-Component Communication XSS 案例中,不可信賴的來源為同一系統上其他元件所接收的資料。在行動環境中,這些是指在同一裝置上執行的應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 1:以下程式碼可讓應用程式在含有資料的 WKWebView 中,從使用應用程式自訂 URL 架構的 URL 要求載入 html 頁面:
AppDelegate.m:
ViewController.m
由於傳遞到 loadHTMLString: 的字串是使用者可控制的,並且 WKWebView 內依預設已啟用 JavaScript,因此使用者可透過使用應用程式自訂 URL 架構的要求,將任意內容 (包括可執行檔指令碼) 寫入 WKWebView。
範例 2:以下程式碼會讀取 UITextField 的內容,並在 WKWebView 中將其顯示給使用者:
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的裝置上提供會導致惡意程式碼執行的輸入?真正的危險在於攻擊者可能使用電子郵件或社交工程病毒誘騙受害者執行此類動作。當這樣的誘騙成功,受害者就在不知情的情況下,透過易受攻擊的 Web 應用程式,將惡意內容帶回他們自己的裝置。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 3:以下程式碼片段會查詢資料庫中具有指定識別碼的員工,然後將值輸出於 WKWebView 的顯示內容中。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 如
1. 資料從一個不可信賴的來源進入 Web 或行動應用程式。在 Inter-Component Communication XSS 案例中,不可信賴的來源為同一系統上其他元件所接收的資料。在行動環境中,這些是指在同一裝置上執行的應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 1:以下程式碼可讓應用程式在含有資料的 WKWebView 中,從使用應用程式自訂 URL 架構的 URL 要求載入 html 頁面:
AppDelegate.m:
...
@property (strong, nonatomic) NSString *webContentFromURL;
...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
...
[self setWebContentFromURL:[url host]];
...
...
ViewController.m
...
@property (strong, nonatomic) WKWebView *webView;
...
AppDelegate *appDelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
...
[_webView loadHTMLString:appDelegate.webContentFromURL] baseURL:nil];
...
由於傳遞到 loadHTMLString: 的字串是使用者可控制的,並且 WKWebView 內依預設已啟用 JavaScript,因此使用者可透過使用應用程式自訂 URL 架構的要求,將任意內容 (包括可執行檔指令碼) 寫入 WKWebView。
範例 2:以下程式碼會讀取 UITextField 的內容,並在 WKWebView 中將其顯示給使用者:
...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView loadHTMLString:_inputTextField.text baseURL:nil];
...
如果
inputTextField
中的文字只包含標準英數字元,這個範例中的程式碼便會正常運作而不會有問題。如果 inputTextField
中的文字包括中繼字元或原始程式碼,那麼網路瀏覽器就會像顯示 HTTP 回應那樣,可能會將輸入當成程式碼來執行。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的裝置上提供會導致惡意程式碼執行的輸入?真正的危險在於攻擊者可能使用電子郵件或社交工程病毒誘騙受害者執行此類動作。當這樣的誘騙成功,受害者就在不知情的情況下,透過易受攻擊的 Web 應用程式,將惡意內容帶回他們自己的裝置。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 3:以下程式碼片段會查詢資料庫中具有指定識別碼的員工,然後將值輸出於 WKWebView 的顯示內容中。
...
@property (strong, nonatomic) WKWebView *webView;
...
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Employee" inManagedObjectContext:context];
[fetchRequest setEntity:entity];
NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];
for (NSManagedObject *info in fetchedObjects) {
NSString msg = @"Hello, " + [info valueForKey:@"name"];
[_webView loadHTMLString:msg baseURL:nil]
...
}
...
如
Example 2
所述,name
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 name
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 name
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,目標應用程式以外的來源會使用目標應用程式的自訂 URL 架構提出 URL 要求,之後來自此 URL 要求的未驗證資料會被當作信賴的資料讀回到應用程式,並會包含在動態內容中。- 如
Example 2
所述,會直接從使用者可控制的 UI 元件讀取資料,並在 HTTP 回應中傳回資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。- 如
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 Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[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.objc.cross_site_scripting_inter_component_communication
Abstract
傳送未經驗證的資料至網路瀏覽器,會導致瀏覽器執行惡意的程式碼。
Explanation
Cross-site scripting (XSS) 弱點會在以下情況中出現:
1. 資料從一個不可信賴的來源進入 Web 或行動應用程式。在 Inter-Component Communication XSS 案例中,不可信賴的來源為同一系統上其他元件所接收的資料。在行動環境中,這些是指在同一裝置上執行的應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 1:以下程式碼可讓應用程式在含有資料的 WKWebView 中,從使用應用程式自訂 URL 架構的 URL 要求載入 html 頁面:
由於傳遞到
範例 2:以下程式碼會讀取 UITextField 的內容,並在 WKWebView 中將其顯示給使用者:
如果
一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的裝置上提供會導致惡意程式碼執行的輸入?真正的危險在於攻擊者可能使用電子郵件或社交工程病毒誘騙受害者執行此類動作。當這樣的誘騙成功,受害者就在不知情的情況下,透過易受攻擊的 Web 應用程式,將惡意內容帶回他們自己的裝置。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 3:以下程式碼片段會查詢資料庫中具有指定識別碼的員工,然後將值輸出於 WKWebView 的顯示內容中。
如
如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
- 如
- 如
1. 資料從一個不可信賴的來源進入 Web 或行動應用程式。在 Inter-Component Communication XSS 案例中,不可信賴的來源為同一系統上其他元件所接收的資料。在行動環境中,這些是指在同一裝置上執行的應用程式。在 Reflected XSS 案例中,不可信賴的來源通常為網頁要求,而在 Persisted XSS (也可稱為 Stored XSS) 案例中,來源通常為資料庫或其他後端資料儲存區。
2.未經驗證且包含在動態內容中的資料將傳送給某個網頁使用者。
傳送到網頁瀏覽器的惡意內容經常是以 JavaScript 片段的形式出現,但是也可能包含 HTML、Flash 或者瀏覽器執行的任何其他程式碼類型。以 XSS 為基礎的攻擊手段花樣百出且幾乎無窮無盡,但是它們通常會傳輸 Cookie 或其他階段作業資訊之類的私人資料給攻擊者、將受害者重新導向到攻擊者控制的網頁內容,或者利用易受攻擊的網站,在使用者的機器上執行其他惡意操作。
有人認為在行動環境中,典型的 Web 應用程式弱點 (例如跨網站指令碼) 不會產生影響,因為使用者為何會攻擊自己呢?但是請謹記,行動平台的本質是從多種來源下載,並在相同裝置上一起執行的應用程式。在金融應用程式旁執行惡意程式碼的可能性很高,這必然會擴大行動應用程式的受攻擊面,將程序之間的通訊包括在內。
範例 1:以下程式碼可讓應用程式在含有資料的 WKWebView 中,從使用應用程式自訂 URL 架構的 URL 要求載入 html 頁面:
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = WKWebView()
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
}
...
由於傳遞到
loadHTMLString:
的字串是使用者可控制的,並且 WKWebView 內依預設已啟用 JavaScript,因此使用者可透過使用應用程式自訂 URL 架構的要求,將任意內容 (包括可執行檔指令碼) 寫入 WKWebView。範例 2:以下程式碼會讀取 UITextField 的內容,並在 WKWebView 中將其顯示給使用者:
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
如果
inputTextField
中的文字只包含標準英數字元,這個範例中的程式碼便會正常運作而不會有問題。如果 inputTextField
中的文字包括中繼字元或原始程式碼,那麼網路瀏覽器就會像顯示 HTTP 回應那樣,可能會將輸入當成程式碼來執行。一開始,這似乎不會輕易受到攻擊。畢竟,誰會在自己的裝置上提供會導致惡意程式碼執行的輸入?真正的危險在於攻擊者可能使用電子郵件或社交工程病毒誘騙受害者執行此類動作。當這樣的誘騙成功,受害者就在不知情的情況下,透過易受攻擊的 Web 應用程式,將惡意內容帶回他們自己的裝置。這個利用易受攻擊的 Web 應用程式進行攻擊的機制就是通常所知的 Reflected XSS。
範例 3:以下程式碼片段會查詢資料庫中具有指定識別碼的員工,然後將值輸出於 WKWebView 的顯示內容中。
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Employee", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
do {
let results = try managedContext.executeFetchRequest(fetchRequest)
let result : NSManagedObject = results.first!
let name : String = result.valueForKey("name")
let msg : String = "Hello, \(name)"
let webView : UIWebView = UIWebView()
webView.loadHTMLString(msg, baseURL:nil)
} catch let error as NSError {
print("Error \(error)")
}
如
Example 2
所述,name
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 name
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 name
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。如同範例中所示,XSS 的弱點是由 HTTP 回應中包含未經驗證資料的程式碼所引起的。XSS 攻擊有三種途徑可攻擊受害者:
- 如
Example 1
所述,目標應用程式以外的來源會使用目標應用程式的自訂 URL 架構提出 URL 要求,之後來自此 URL 要求的未驗證資料會被當作信賴的資料讀回到應用程式,並會包含在動態內容中。- 如
Example 2
所述,會直接從使用者可控制的 UI 元件讀取資料,並在 HTTP 回應中傳回資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。- 如
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 Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[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.swift.cross_site_scripting_inter_component_communication