Fortify漏洞之Cross-Site Scripting（XSS 跨站腳本攻擊）
書接上文，繼續對Fortify漏洞進行總結，本篇主要針對XSS跨站腳步攻擊漏洞進行總結如下：
1、Cross-Site Scripting（XSS 跨站腳本攻擊）
1.1、產生原因：
1. 數據通過一個不可信賴的數據源進入 Web 應用程序。對於 Reflected XSS（反射型），不可信賴的源通常為 Web 請求，只影響攻擊到當前操作用戶；而對於 Persisted（也稱為 Stored 持久型）XSS，該源通常為數據庫或其他後端數據存儲，可能影響多操作用戶。
2. 未檢驗包含在動態內容中的數據，便將其傳送給了 Web 用戶。
圖1.1.1 XSS漏洞分類
傳送到 Web 瀏覽器的惡意內容通常采用 JavaScript
示例 1：以下代碼可從 HTTP servlet 請求中讀取雇員 ID eid，並在 servlet 響應中將值顯示給該用戶。
String eid = request.getParameter("eid");
...
ServletOutputStream out = response.getOutputStream();
out.print("Employee ID: " +
eid);
...
out.close();
...
如果 eid 只包含標準的字母或數字文本，這個例子中的代碼就能正確運行。如果 eid 裏有包含元字符或源代碼中的值，那麽 Web 瀏覽器就會像顯示 HTTP 響應那樣執行代碼。
起初，這個例子似乎是不會輕易遭受攻擊的。畢竟，有誰會輸入導致惡意代碼的 URL，並且還在自己的電腦上運行呢？真正的危險在於攻擊者會創建惡意的 URL，然後采用電子郵件或者社會工程的欺騙手段誘使受害者訪問此 URL 的鏈接。當受害者單擊這個鏈接時，他們不知不覺地通過易受攻擊的網絡應用程序，將惡意內容帶到了自己的電腦中。這種對易受攻擊的 Web 應用程序進行盜取的機制通常被稱為反射式 XSS。
示例 2：以下代碼片段可在數據庫中查詢具有給定 ID 的雇員，並在 servlet 響應中輸出相應雇員姓名。
...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name =
rs.getString("name");
}
ServletOutputStream out = response.getOutputStream();
out.print("Employee Name: " + name);
...
out.close();
...
如同例 1，如果對 name 的值處理得當，該代碼就能正常地執行各種功能；如若處理不當，就會對代碼的盜取行為無能為力。同樣，這段代碼暴露出的危險較小，因為 name的值是從數據庫中讀取的，而且顯然這些內容是由應用程序管理的。然而，如果 name 的值是由用戶提供的數據產生，數據庫就會成為惡意內容溝通的通道。如果不對數據庫中存儲的所有數據進行恰當的輸入驗證，那麽攻擊者就可以在用戶的 Web 瀏覽器中執行惡意命令。這種類型的 Persistent XSS（也稱為 Stored XSS）盜取極其陰險狡猾，因為數據存儲導致的間接性使得辨別威脅的難度增大，而且還提高了一個攻擊影響多個用戶的可能性。XSS 盜取會從訪問提供留言簿 (guestbook) 的網站開始。攻擊者會在這些留言簿的條目中嵌入 JavaScript，接下來所有訪問該留言簿的用戶都會執行這些惡意代碼。
1.2、修復方案：
所以根據XSS漏洞產生的原因，對於XSS腳本攻擊的漏洞修復，主要解決方案是：
a、對輸入源進行校驗和過濾；
b、對輸出源進行校驗和過濾；
例：
提供公共方法，結合實際業務需求，對輸入源和輸出源調用該方法進行特殊字符的過濾，主要是瀏覽器腳本可能包含的一些特殊字符。
圖1.1.2：過濾XSS攻擊的特殊字符公共方法
Fortify漏洞之Cross-Site Scripting（XSS 跨站腳本攻擊）