Abstract:
article_attrs.jsp 中的方法 _jspService() 向第 79 行的 Web 瀏覽器發送非法數據，從而導致瀏覽器執行惡意代碼。
Explanation:
Cross-Site Scripting (XSS) 漏洞在以下情況下發生：
1. 數據通過一個不可信賴的數據源進入 Web 應用程序。對於 Reflected XSS，不可信賴的源通常為 Web 請求，而對於 Persisted（也稱為 Stored）XSS，該源通常為數據庫或其他后端數據存儲。
在這種情況下，數據經由 XssHttpServletRequestWrapper.java 的第 40 行進入 getParameter()。
2. 未檢驗包含在動態內容中的數據，便將其傳送給了 Web 用戶。
在這種情況下，數據通過 article_attrs.jsp 的第 79 行中的 print() 傳送。
傳送到 Web 瀏覽器的惡意內容通常采用 JavaScript 代碼片段的形式，但也可能會包含一些 HTML、Flash 或者其他任意一種可以被瀏覽器執行的代碼。基於 XSS 的攻擊手段花樣百出，幾乎是無窮無盡的，但通常它們都會包含傳輸給攻擊者的私人數據（如 Cookie 或者其他會話信息）。在攻擊者的控制下，指引受害者進入惡意的網絡內容；或者利用易受攻擊的站點，對用戶的機器進行其他惡意操作。
示例 1：以下 JSP 代碼片段可從 HTTP 請求中讀取雇員 ID eid，並將其顯示給用戶。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
如果 text 只包含標准的字母或數字文本，這個例子中的代碼就能正確運行。如果 eid 里有包含元字符或源代碼中的值，那么 Web 瀏覽器就會像顯示 HTTP 響應那樣執行代碼。
起初，這個例子似乎是不會輕易遭受攻擊的。畢竟，有誰會輸入導致惡意代碼的 URL，並且還在自己的電腦上運行呢？真正的危險在於攻擊者會創建惡意的 URL，然后采用電子郵件或者社會工程的欺騙手段誘使受害者訪問此 URL 的鏈接。當受害者單擊這個鏈接時，他們不知不覺地通過易受攻擊的網絡應用程序，將惡意內容帶到了自己的電腦中。這種對易受攻擊的 Web 應用程序進行盜取的機制通常被稱為反射式 XSS。
示例 2：以下 JSP 代碼片段可在數據庫中查詢具有給定 ID 的雇員，並輸出相應雇員姓名。
<%...
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 %>
如同例 1，如果對 name 的值處理得當，該代碼就能正常地執行各種功能；如若處理不當，就會對代碼的盜取行為無能為力。同樣，這段代碼暴露出的危險較小，因為 name 的值是從數據庫中讀取的，而且顯然這些內容是由應用程序管理的。然而，如果 name 的值是由用戶提供的數據產生，數據庫就會成為惡意內容溝通的通道。如果不對數據庫中存儲的所有數據進行恰當的輸入驗證，那么攻擊者就可以在用戶的 Web 瀏覽器中執行惡意命令。這種類型的 Persistent XSS（也稱為 Stored XSS）盜取極其陰險狡猾，因為數據存儲導致的間接性使得辨別威脅的難度增大，而且還提高了一個攻擊影響多個用戶的可能性。XSS 盜取會從訪問提供留言簿 (guestbook) 的網站開始。攻擊者會在這些留言簿的條目中嵌入 JavaScript，接下來所有訪問該留言簿的用戶都會執行這些惡意代碼。
有些人認為在移動世界中，典型的 Web 應用程序漏洞（如 cross-site scripting）是無意義的 -- 為什么用戶要攻擊自己？但是，謹記移動平台的本質是從各種來源下載並在相同設備上運行的應用程序。惡意軟件在銀行應用程序附近運行的可能性很高，它們會強制擴展移動應用程序的攻擊面（包括跨進程通信）。
示例 3：以下代碼在 Android WebView 中啟用了 JavaScript（默認情況下，JavaScript 為禁用狀態），並根據從 Android Intent 接收到的值加載頁面。
...
WebView webview = (WebView) findViewById(R.id.webview); webview.getSettings().setJavaScriptEnabled(true); String url = this.getIntent().getExtras().getString("url"); webview.loadUrl(url);
...
如果 url 的值以 javascript: 開頭，則接下來的 JavaScript 代碼將在 WebView 中的 Web 頁面上下文內部執行。
正如例子中所顯示的，XSS 漏洞是由於 HTTP 響應中包含了未經驗證的數據代碼而引起的。受害者遭受 XSS 攻擊的途徑有三種：
－ 如例 1 所述，系統從 HTTP 請求中直接讀取數據，並在 HTTP 響應中返回數據。當攻擊者誘使用戶為易受攻擊的 Web 應用程序提供危險內容，而這些危險內容隨后會反饋給用戶並在 Web 瀏覽器中執行，就會發生反射式 XSS 盜取。發送惡意內容最常用的方法是，把惡意內容作為一個參數包含在公開發表的 URL 中，或者通過電子郵件直接發送給受害者。以這種手段構造的 URL 構成了多種“網絡釣魚”(phishing) 陰謀的核心，攻擊者借此誘騙受害者訪問指向易受攻擊站點的 URL。站點將攻擊者的內容反饋給受害者以后，便會執行這些內容，接下來會把用戶計算機中的各種私密信息（比如包含會話信息的 cookie）傳送給攻擊者，或者執行其他惡意活動。
－ 如例 2 所述，應用程序將危險數據儲存在一個數據庫或其他可信賴的數據存儲器中。這些危險數據隨后會被回寫到應用程序中，並包含在動態內容中。Persistent XSS 盜取發生在如下情況：攻擊者將危險內容注入到數據存儲器中，且該存儲器之后會被讀取並包含在動態內容中。從攻擊者的角度看，注入惡意內容的最佳位置莫過於一個面向許多用戶，尤其是相關用戶顯示的區域。相關用戶通常在應用程序中具備較高的特權，或相互之間交換敏感數據，這些數據對攻擊者來說有利用價值。如果某一個用戶執行了惡意內容，攻擊者就有可能以該用戶的名義執行某些需要特權的操作，或者獲得該用戶個人所有的敏感數據的訪問權限。
— 正如例 3 所示，應用程序之外的數據源將危險數據儲存在一個數據庫或其他數據存儲器中，隨后這些危險數據被當作可信賴的數據回寫到應用程序中，並存儲在動態內容中。
Instance ID: C6448B03CEB2DB85B704D442FA213581
Priority Metadata Values:
IMPACT: 5.0
LIKELIHOOD: 3.33
Legacy Priority Metadata Values:
SEVERITY: 4.0
CONFIDENCE: 3.33
Remediation Effort: 1.0
Recommendations:
針對 XSS 的解決方法是，確保在適當位置進行驗證，並檢驗其屬性是否正確。
由於 XSS 漏洞出現在應用程序的輸出中包含惡意數據時，因此，合乎邏輯的做法是在數據流出應用程序的前一刻對其進行驗證。然而，由於 Web 應用程序常常會包含復雜而難以理解的代碼，用以生成動態內容，因此，這一方法容易產生遺漏錯誤（遺漏驗證）。降低這一風險的有效途徑是對 XSS 也執行輸入驗證。
由於 Web 應用程序必須驗證輸入信息以避免其他漏洞（如 SQL Injection），因此，一種相對簡單的解決方法是，加強一個應用程序現有的輸入驗證機制，將 XSS 檢測包括其中。盡管有一定的價值，但 XSS 輸入驗證並不能取代嚴格的輸出驗證。應用程序可能通過共享的數據存儲或其他可信賴的數據源接受輸入，而該數據存儲所接受的輸入源可能並未執行適當的輸入驗證。因此，應用程序不能間接地依賴於該數據或其他任意數據的安全性。這就意味着，避免 XSS 漏洞的最佳方法是驗證所有進入應用程序以及由應用程序傳送至用戶端的數據。
針對 XSS 漏洞進行驗證最安全的方式是，創建一份安全字符白名單，允許其中的字符出現在 HTTP 內容中，並且只接受完全由這些經認可的字符組成的輸入。例如，有效的用戶名可能僅包含字母數字字符，電話號碼可能僅包含 0-9 的數字。然而，這種解決方法在 Web 應用程序中通常是行不通的，因為許多字符對瀏覽器來說都具有特殊的含義，在寫入代碼時，這些字符仍應被視為合法的輸入，比如一個 Web 設計版就必須接受帶有 HTML 代碼片段的輸入。
更靈活的解決方法稱為黑名單方法，但其安全性較差，這種方法在進行輸入之前就有選擇地拒絕或避免了潛在的危險字符。為了創建這樣一個列表，首先需要了解對於 Web 瀏覽器具有特殊含義的字符集。雖然 HTML 標准定義了哪些字符具有特殊含義，但是許多 Web 瀏覽器會設法更正 HTML 中的常見錯誤，並可能在特定的上下文中認為其他字符具有特殊含義，這就是我們不鼓勵使用黑名單作為阻止 XSS 的方法的原因。卡耐基梅隆大學 (Carnegie Mellon University) 軟件工程學院 (Software Engineering Institute) 下屬的 CERT(R) (CERT(R) Coordination Center) 合作中心提供了有關各種上下文中認定的特殊字符的具體信息 [1]：
在有關塊級別元素的內容中（位於一段文本的中間）：
－“<”是一個特殊字符，因為它可以引入一個標簽。
－“&”是一個特殊字符，因為它可以引入一個字符實體。
－“>”是一個特殊字符，之所以某些瀏覽器將其認定為特殊字符，是基於一種假設，即該頁的作者本想在前面添加一個“<”，卻錯誤地將其遺漏了。
下面的這些原則適用於屬性值：
－ 對於外加雙引號的屬性值，雙引號是特殊字符，因為它們標記了該屬性值的結束。
－ 對於外加單引號的屬性值，單引號是特殊字符，因為它們標記了該屬性值的結束。
－ 對於不帶任何引號的屬性值，空格字符（如空格符和制表符）是特殊字符。
-“&”與某些特定變量一起使用時是特殊字符，因為它引入了一個字符實體。
例如，在 URL 中，搜索引擎可能會在結果頁面內提供一個鏈接，用戶可以點擊該鏈接來重新運行搜索。可以將這一方法運用於編寫 URL 中的搜索查詢語句，這將引入更多特殊字符：
－ 空格符、制表符和換行符是特殊字符，因為它們標記了 URL 的結束。
-“&”是特殊字符，因為它可引入一個字符實體或分隔 CGI 參數。
－ 非 ASCII 字符（即 ISO-8859-1 編碼表中所有高於 128 的字符）不允許出現在 URL 中，因此在此上下文中也被視為特殊字符。
－ 在服務器端對在 HTTP 轉義序列中編碼的參數進行解碼時，必須過濾掉輸入中的“%”符號。例如，當輸入中出現“%68%65%6C%6C%6F”時，只有從輸入的內容中過濾掉“%”，上述字符串才能在網頁上顯示為“hello”。
在 <SCRIPT> </SCRIPT> 的正文內：
- 如果可以將文本直接插入到已有的腳本標簽中，應該過濾掉分號、省略號、中括號和換行符。
服務器端腳本：
－ 如果服務器端腳本會將輸入中的感嘆號 (!) 轉換成輸出中的雙引號 (")，則可能需要對此進行更多過濾。
其他可能出現的情況：
－ 如果攻擊者在 UTF-7 中提交了一個請求，那么特殊字符“<”可能會顯示為“+ADw-”，並可能會繞過過濾。如果輸出包含在沒有確切定義編碼格式的網頁中，有些瀏覽器就會設法根據內容自動識別編碼（此處采用 UTF-7 格式）。
一旦在應用程序中確定了針對 XSS 攻擊執行驗證的正確要點，以及驗證過程中要考慮的特殊字符，下一個難點就是定義驗證過程中處理各種特殊字符的方式。如果應用程序認定某些特殊字符為無效輸入，那么您可以拒絕任何帶有這些無效特殊字符的輸入。第二種選擇就是采用過濾手段來刪除這些特殊字符。然而，過濾的負面作用在於，過濾內容的顯示將發生改變。在需要完整顯示輸入內容的情況下，過濾的這種負面作用可能是無法接受的。
如果必須接受帶有特殊字符的輸入，並將其准確地顯示出來，驗證機制一定要對所有特殊字符進行編碼，以便刪除其具有的含義。官方的 HTML 規范 [2] 提供了特殊字符對應的 ISO 8859-1 編碼值的完整列表。
許多應用程序服務器都試圖避免應用程序出現 Cross-Site Scripting 漏洞，具體做法是為負責設置特定 HTTP 響應內容的函數提供各種實現方式，以檢驗是否存在進行 Cross-Site Scripting 攻擊必需的字符。不要依賴運行應用程序的服務器，以此確保該應用程序的安全。開發了某個應用程序后，並不能保證在其生命周期中它會在哪些應用程序服務器中運行。由於標准和已知盜取方式的演變，我們不能保證應用程序服務器也會保持同步。
Tips:
1. HPE Security 安全編碼規則包將就 SQL Injection 和 Access Control 提出警告：當把不可信賴的數據寫入數據庫時，數據庫將出現問題，並且會將數據庫當作不可信賴的數據的來源，這會導致 XSS 漏洞。如果數據庫在您的環境中是可信賴的資源，則使用自定義篩選器篩選出包含 DATABASE 污染標志或來自數據庫源的數據流問題。盡管如此，對所有從數據庫中讀取的內容進行驗證仍然是較好的做法。
2. 雖然使用 URL 對不可信數據進行編碼可以防止許多 XSS 攻擊，但部分瀏覽器（尤其是 Internet Explorer 6 和 7 以及其他瀏覽器）在將數據傳遞給 JavaScript 解釋器之前，會自動在文檔對象模型 (DOM) 中的特定位置對其內容進行解碼。為了反映出其危險之處，規則包不再認為 URL 編碼例程足以防御 cross-site scripting 攻擊。如果對數據值進行 URL 編碼並隨后輸出，Fortify 將會報告存在 Cross-Site Scripting: Poor Validation 漏洞。
3. Fortify RTA adds protection against this category.
References:
[1] Understanding Malicious Content Mitigation for Web Developers, CERT,
http://www.cert.org/tech_tips/malicious_code_mitigation.html#9
[2] HTML 4.01 Specification, W3,
http://www.w3.org/TR/html4/sgml/entities.html#h-24.2
[3] Tongbo Luo, Hao Hao, Wenliang Du, Yifei Wang, and Heng Yin, Attacks on WebView in the Android System,
http://www.cis.syr.edu/~wedu/Research/paper/webview_acsac2011.pdf
[4] Erika Chin and David Wagner, Bifocals: AnalyzingWebView Vulnerabilities in Android Applications,
http://www.cs.berkeley.edu/~emc/papers/Chin-WISA-WebViews.pdf
[5] INJECT-3: XML and HTML generation requires care, Oracle,
http://www.oracle.com/technetwork/java/seccodeguide-139067.html#3
[6] INPUT-1: Validate inputs, Oracle,
http://www.oracle.com/technetwork/java/seccodeguide-139067.html#5
[7] Standards Mapping - Common Weakness Enumeration, CWE ID 79, CWE ID 80
[8] Standards Mapping - FIPS200, SI
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4, SI-10 Information Input Validation (P1)
[10] Standards Mapping - OWASP Mobile Top 10 Risks 2014, M7 Client Side Injection
[11] Standards Mapping - OWASP Top 10 2004, A4 Cross Site Scripting
[12] Standards Mapping - OWASP Top 10 2007, A1 Cross Site Scripting (XSS)
[13] Standards Mapping - OWASP Top 10 2010, A2 Cross-Site Scripting (XSS)
[14] Standards Mapping - OWASP Top 10 2013, A3 Cross-Site Scripting (XSS)
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1, Requirement 6.5.4
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2, Requirement 6.3.1.1, Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0, Requirement 6.5.7
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0, Requirement 6.5.7
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1, Requirement 6.5.7
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2, Requirement 6.5.7
[21] Standards Mapping - SANS Top 25 2009, Insecure Interaction - CWE ID 079
[22] Standards Mapping - SANS Top 25 2010, Insecure Interaction - CWE ID 079
[23] Standards Mapping - SANS Top 25 2011, Insecure Interaction - CWE ID 079
[24] Standards Mapping - Security Technical Implementation Guide Version 3.1, APP3510 CAT I, APP3580 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.10, APP3510 CAT I, APP3580 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4, APP3510 CAT I, APP3580 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5, APP3510 CAT I, APP3580 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6, APP3510 CAT I, APP3580 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7, APP3510 CAT I, APP3580 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9, APP3510 CAT I, APP3580 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.1, APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[32] Standards Mapping - Web Application Security Consortium 24 + 2, Cross-Site Scripting
[33] Standards Mapping - Web Application Security Consortium Version 2.00, Cross-Site Scripting (WASC-08)