Cross-Site Scripting: Reflected解決方法

首先貼解決辦法吧，解決了我項目中的問題，不一定適用所有情況。

        //For Cross-Site Scripting: Reflected
      public static String filter(String output){
          List<String> list = new ArrayList<String>();
          list.add("<");
          list.add(">");
          list.add("(");
          list.add(")");
          list.add("&");
          list.add("?");
          list.add(";");
          String encode= Normalizer.normalize(output,Normalizer.Form.NFKC);
          for(int i = 0; i<list.size();i++){
              encode=encode.replace(list.get(i),"");
          }
      return encode;
      }

//需要校驗的內容
response.getWriter().write(XXXX.filter(XXX));

 

 

假如解決不了 就只能仔細研究下文檔中內容了，再結合自己的代碼做檢驗。↓

--------------------------------------------------------------------------------------------------------------------------------

 

Cross-Site Scripting: Reflected

Abstract

向Web瀏覽器發送未經驗證的數據可能會導致瀏覽器執行惡意代碼

Explanation

跨站點腳本(XSS)漏洞發生在以下情況：1.數據通過不可信的來源進入Web應用程序。在反射XSS的情況下，不受信任的源通常是Web請求，而在持久化(也稱為存儲)XSS的情況下，
它通常是數據庫或其他后端數據存儲。2.數據包括在動態內容中，該動態內容在未經驗證的情況下被發送給web用戶。發送到Web瀏覽器的惡意內容通常采用JavaScript片段的形
式，但也可能包括HTML、Flash或瀏覽器可能執行的任何其他類型的代碼。基於XSS的攻擊種類幾乎是無限的，但它們通常包括向攻擊者傳輸Cookie或其他會話信息等私人數據，將
受害者重定向到攻擊者控制的Web內容，或者以易受攻擊的站點為幌子在用戶計算機上執行其他惡意操作。示例1：下面的JSP代碼段從HTTP請求中讀取員工ID EID，並將其顯示給
用戶。

<% String eid = request.getParameter("eid"); %> 
... 
Employee ID: <%= eid %>

 

如果EID僅包含標准字母數字文本，則此示例中的代碼可以正常運行。如果EID具有包含元字符或源代碼的值，則代碼將由Web瀏覽器在顯示HTTP響應時執行。起初，這可能看起來不
是一個很大的漏洞。畢竟，為什么有人要輸入一個導致惡意代碼在他們自己的計算機上運行的URL呢？真正的危險在於，攻擊者會創建惡意URL，然后使用電子郵件或社會工程技巧引
誘受害者訪問指向該URL的鏈接。當受害者單擊該鏈接時，他們會在不知不覺中通過易受攻擊的Web應用程序將惡意內容反映回自己的計算機。這種利用易受攻擊的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
瀏覽器中執行惡意命令。這種類型的利用稱為持久(或存儲的)XSS，特別隱蔽，因為數據存儲導致的間接攻擊使識別威脅變得更加困難，並增加了攻擊影響多個用戶的可能性。XSS開始於這種
形式的網站，向訪問者提供“留言簿”。攻擊者會在他們的留言簿條目中包含JavaScript，所有隨后訪問留言簿頁面的訪問者都會執行惡意代碼。一些人認為，在移動世界中，傳統的Web應
用程序漏洞，如跨站點腳本，是沒有意義的--為什么用戶要攻擊他們自己呢？但是，請記住，移動平台的本質是從各種來源下載並在同一設備上並行運行的應用程序。在銀行應用程序旁邊運
行惡意軟件的可能性很高，這就需要擴大移動應用程序的攻擊面，以包括進程間通信。

示例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內的網頁上下文中執行。如示例所示，XSS漏洞是由HTTP響應中包含未經驗證的數據的代碼引起的。XSS攻擊可
以通過三個向量到達受害者：-如示例1所示，數據直接從HTTP請求中讀取並反映回HTTP響應中。當攻擊者使用戶向易受攻擊的Web應用程序提供危險內容，然后將其反射回用戶並由Web瀏覽器
執行時，就會發生反射的XSS利用漏洞攻擊。傳遞惡意內容的最常見機制是將其作為參數包含在公開發布或通過電子郵件直接發送給受害者的URL中。以這種方式構建的URL構成了許多網絡釣魚
計划的核心，攻擊者據此說服受害者訪問指向易受攻擊站點的URL。在站點將攻擊者的內容反映回用戶之后，該內容將被執行，並繼續將私人信息(例如可能包含會話信息的cookie)從用戶的計
算機傳輸到攻擊者或執行其他惡意活動。-如示例2所示，應用程序將危險數據存儲在數據庫或其他受信任的數據存儲中。危險數據隨后被讀回應用程序並包括在動態內容中。當攻擊者將危險內容
注入稍后讀取並包含在動態內容中的數據存儲中時，就會發生持久的XSS攻擊。從攻擊者的角度來看，注入惡意內容的最佳位置是向許多用戶或特別感興趣的用戶顯示的區域。感興趣的用戶通常在
應用程序中擁有提升的權限，或者與對攻擊者有價值的敏感數據交互。如果其中一個用戶執行惡意內容，攻擊者可能能夠代表該用戶執行特權操作或訪問屬於該用戶的敏感數據。-如示例3所示，應
用程序外部的源將危險數據存儲在數據庫或其他數據存儲中，然后將危險數據作為可信數據讀回應用程序，並將其包括在動態內容中。許多現代Web框架提供用於執行用戶輸入驗證的機制。
Struts和Spring MVC都在其中。為了突出顯示未經驗證的輸入源，規則包通過降低HPE Security Fortify靜態代碼分析器報告的問題的利用概率，並在使用框架驗證機制時提供指向支
持證據的指針，動態地重新確定問題的優先級。我們將此功能稱為上下文敏感排名。為了進一步幫助HPE Security Fortify用戶執行審核流程，HPE Security Fortify軟件安全研究小
組提供了數據驗證項目模板，該模板根據應用於其輸入源的驗證機制將問題分組到文件夾中。

Recommendation

XSS的解決方案是確保驗證在正確的位置進行，並檢查正確的屬性。由於當應用程序在其輸出中包含惡意數據時會出現XSS漏洞，因此一種合乎邏輯的方法是在數據離開應用程序之前立即對其進行
驗證。然而，由於Web應用程序通常具有復雜而復雜的代碼來生成動態內容，因此此方法容易出現遺漏錯誤(缺少驗證)。降低此風險的有效方法是還對XSS執行輸入驗證。Web應用程序必須驗證其
輸入以防止其他漏洞(如SQL注入)，因此擴展應用程序的現有輸入驗證機制以包括對XSS的檢查通常相對容易。盡管XSS的輸入驗證很有價值，但它並不能取代嚴格的輸出驗證。應用程序可以通過
共享數據存儲或其他可信來源接受輸入，並且該數據存儲可以接受來自沒有執行充分輸入驗證的源的輸入。因此，應用程序不能隱式依賴此數據或任何其他數據的安全性。這意味着防止XSS漏洞的
最好方法是驗證進入應用程序並將應用程序留給用戶的所有內容。對XSS進行驗證的最安全方法是創建允許出現在HTTP內容中的安全字符的白名單，並接受僅由批准的集合中的字符組成的輸入。
例如，有效的用戶名可能只包括字母數字字符，或者電話號碼可能只包括數字0-9。然而，此解決方案在以下方面通常是不可行的Web應用程序，因為許多對瀏覽器有特殊意義的字符在編碼后仍應被
視為有效輸入，例如必須接受來自其用戶的HTML片段的Web設計公告欄。一種更靈活但不太安全的方法被稱為黑名單，它在使用輸入之前有選擇地拒絕或轉義潛在的危險字符。為了形成這樣的列表
，您首先需要了解對Web瀏覽器具有特殊含義的字符集。雖然HTML標准定義了哪些字符有特殊含義，但許多Web瀏覽器試圖糾正HTML中的常見錯誤，並可能在某些上下文中將其他字符視為特殊字符
，這就是為什么我們不鼓勵使用黑名單作為防止XSS的手段。卡內基梅隆大學(Carnegie Mellon University)軟件工程學院的CERT(R)協調中心提供了關於各種上下文中的特殊字符的以
下詳細信息[1]：在塊級元素的內容中(在文本段落的中間)：-“<”是特殊的，因為它引入了一個標簽。-“&”是特殊的，因為它引入了一個字符實體。-“>”是特殊的，因為一些瀏覽器將其視為特殊的
，假設頁面的作者打算包括開頭的“<”，但錯誤地遺漏了它。以下原則適用於屬性值：-在用雙引號括起來的屬性值中，雙引號是特殊的，因為它們標記屬性值的結束。-在用單引號括起來的屬性值中，
單引號是特殊的，因為它們標記屬性值的末尾。-在不帶引號的屬性值中，空格和制表符等空格字符是特殊字符。-“&”在與某些屬性一起使用時是特殊的，因為它引入了一個字符實體。例如，在URL
中，搜索引擎可能會在結果頁內提供一個鏈接，用戶可以單擊該鏈接以重新運行搜索。這可以通過在URL中編碼搜索查詢來實現，這引入了額外的特殊字符：-空格、制表符和換行符是特殊的，因為它
們標記URL的末尾。-“&”是特殊的，因為它要么引入一個字符實體，要么分隔CGI參數。-URL中不允許使用非ASCII字符(即ISO-8859-1編碼中所有大於128的字符)，因此在此上下文中它們被
視為特殊字符。-在服務器端代碼解碼使用HTTP轉義序列編碼的參數時，必須從輸入中過濾“%”符號。例如，如果“%68%65%6C%6C%6C%6F”之類的輸入在相關網頁上顯示為“hello”，則必須過濾
“%”。在正文中：-分號、圓括號、大括號和換行符應該在文本可以直接插入到預先存在的腳本標記的情況下過濾掉。服務器端腳本：-轉換任何感嘆號(！)的服務器端腳本。在輸入到輸出上的雙引號字
符(“)時，可能需要額外的篩選。其他可能性：-如果攻擊者以UTF-7格式提交請求，則特殊字符“<”將顯示為“+adw-”，並可能繞過過濾。如果輸出包含在沒有顯式指定編碼格式的頁面中，那么一些
瀏覽器會嘗試根據內容(在本例中為UTF-7)智能地識別編碼。一旦您確定了應用程序中正確的點來執行XSS攻擊驗證，以及驗證應該考慮哪些特殊字符，下一個挑戰就是確定您的驗證如何處理特殊字
符。如果特殊字符不被視為應用程序的有效輸入，則可以拒絕任何包含特殊字符的無效輸入。這種情況下的第二個選項是使用過濾刪除特殊字符。然而，過濾具有改變過濾內容的任何可視表示的副作用
，並且在必須保留輸入完整性以供顯示的情況下可能是不可接受的。如果必須接受和准確顯示包含特殊字符的輸入，則驗證必須對任何特殊字符進行編碼以消除其重要性。特殊字符的ISO 8859-1編
碼值的完整列表作為官方HTML規范的一部分提供[2]。許多應用程序服務器試圖通過提供負責設置某些特定HTTP響應內容的函數的實現來限制應用程序暴露於跨站點腳本漏洞，這些特定HTTP響應
內容對跨站點腳本攻擊所必需的字符執行驗證。不要依賴運行應用程序的服務器來確保應用程序的安全。在開發應用程序時，無法保證它在其生命周期內將在哪些應用程序服務器上運行。隨着標准和
已知漏洞的發展，不能保證應用程序服務器也會保持同步。