XSS攻擊，通常指黑客通過“html注入” 篡改了網頁，插入了惡意的指令碼，從而在使用者瀏覽網頁的時候，控制使用者瀏覽器的一種攻擊。其原理是攻擊者向有XSS漏洞的網站中輸入(傳入)一段惡意的HTML程式碼，當其它使用者瀏覽該網站時，這段HTML程式碼會自動執行，從而達到攻擊的目的。如，盜取使用者Cookie、破壞頁面結構、重定向到其它網站等。

l XSS攻擊的生效方式（按危害大小排序）：
1）構造URL

XSS攻擊者通過構造URL的方式構造了一個有問題的頁面；當其他人點選了此頁面後，會發現頁面出錯，或者被暗中執行了某些js指令碼，這時，攻擊行為才真正生效。

一般來說，動態頁面中會將url中的部分內容回寫在頁面中。以百度的搜尋為例：

http://www.baidu.com/s?wd=<script>alert("wrong")<%2Fscript>
引數<script>alert("wrong")<%2Fscript>是<script>alert("wrong")</script>轉義後的結果，搜尋結果頁中，會在標題中中和搜尋框中回寫使用者輸入的內容。從頁面的原始碼中，我們看到，這兩處本應該顯示使用者輸入內容<script>alert("wrong")</script>的地方，實際也經過了轉義處理，變成了<script>alert("wrong")</script>。如果這裡沒有經過轉義處理，則頁面中就嵌入了一段script，會執行，並彈出對話方塊提示使用者。如果是其他惡意程式碼，則可能造成破壞。

然後攻擊者將此URL廣為傳播——比如說，以報錯的方式發給百度的管理員，管理員開啟這個URL就中招了。

2）釋出內容式

構造URL攻擊方式傳播範圍有限，被攻擊者只要有基本的安全意識就可以避免，因此這種手段的危險性比較小。相比之下，通過發表內容構造的XSS的危害就大了很多。

在可以發表內容的論壇、討論區、吧、部落格、微博等網站上，使用者發表的內容會儲存起來，允許其他使用者瀏覽。這些儲存的內容顯示在頁面上的時候，如果沒有經過正確的處理，也會把攻擊者精心構造的內容顯示出來，訪問該內容的使用者就此中招。如果該頁面流傳廣泛，則影響會更加深遠。

一般來說，這種攻擊都做得比較隱蔽，被攻擊者並不知道自己什麼時候踩中了地雷；網站也很難追查問題的來源。

3）蠕蟲式

上述兩種方式的流傳範圍都有一定限度；最徹底最暴力的方式是使用蠕蟲——就是首先發一個有問題的文章，瀏覽者閱讀時會被暗中執行惡意程式碼，發表一篇新的文章的，該文章也含有同樣的惡意程式碼。這樣有可能在最快時間內將攻擊鋪滿整個網站。蠕蟲式攻擊將暗中偷偷摸摸的攻擊行為變成了光明正大的攻城拔寨，極容易被發現和修復。

下面是6月28日新浪微博被蠕蟲攻擊的報告，其實質就是XSS攻擊。

http://www.ijinshan.com/news/20110629001.shtml 

l XSS攻擊的防範方式：
防範XSS攻擊的方式也十分簡單：轉義！但是你會面臨兩種抉擇，是在入庫前轉義呢，還是在讀取前轉義呢？

這兩種方式各有優劣，對於新手來說，一般會選擇入庫前轉義，因為這種方法看起來可以一勞永逸，而且操作非常簡單，只需要寫一個filter或者interceptor攔截所有的寫入請求，統一轉義後交給controller處理入庫即可。但是如果你的終端是多樣化的，需要有多種展現形式的時候，這種方式就顯得力不從心了。比如說你的終端要求以XML的形式顯示資料，那麼你就先得unescape回原始資料然後再按照xml的格式escape一次。假如終端要求更復雜的方式，轉換起來就更復雜了。所以老手們慢慢會選擇使用第二種方式。

我來終結一下這兩種方式的優缺點：

轉義方式  入庫前轉義    

優點            一勞永逸

缺點           需要針對多端進行不同的輸出，靈活性不足，無法應對後期資料格式的變化

轉義方式  讀取前轉義    

優點            簡單，靈活，能應對各種資料格式的場景

缺點           需要對每個輸出資料轉義，人工處理容易遺漏

本人推薦第二種方式來防範xss攻擊。雖然需要對每個輸出資料都進行轉義，但是如果你使用帶自動轉義的模版或者框架來處理的話，那麼就可以極大的提高效率，又可以規避安全的問題。

下面介紹兩種基礎轉義的方法：

1）使用Apache的commons-lang.jar

StringEscapeUtils.escapeHtml(str);// 漢字會轉換成對應的ASCII碼，空格不轉換
2）自己實現轉換，只轉換部分字元

private static String htmlEncode(char c) {
    switch(c) {
       case '&':
           return"&";
       case '<':
           return"<";
       case '>':
           return">";
       case '"':
           return""";
       case ' ':
           return" ";
       default:
           return c +"";
    }
}
/** 對傳入的字串str進行Html encode轉換*/
public static String htmlEncode(String str) {
    if(str ==null || str.trim().equals(""))   return str;
    StringBuilder encodeStrBuilder = new StringBuilder();
    for (int i = 0, len = str.length(); i < len; i++) {
       encodeStrBuilder.append(htmlEncode(str.charAt(i)));
    }
    return encodeStrBuilder.toString();
}
 
l 另外介紹一種最常見的XSS攻擊及其防範方法
最常見的XSS攻擊就是通過讀取瀏覽器的Cookie物件，從而發起“cookie劫持”，當前使用者的登入憑證儲存於伺服器的session中，而在瀏覽器中是以cookie的形式進行儲存的，cookie被劫持後，意味著攻擊者可以不通過密碼而直接登入系統。我們也可以直接在瀏覽器中輸入指令碼javascript:alert(document.cookie)來獲取當前cookie值。

目前防止“cookie劫持”的方法大致有：a. 輸入檢查，使用filter來過濾敏感的關鍵字；b. 將cookie與使用者ip地址進行繫結；c. 為cookie植入HttpOnly標識。

本系統採用的是第3種方式：為cookie植入HttpOnly標識。一旦這個HttpOnly被設定，你在瀏覽器的 document物件中就看不到Cookie了，而瀏覽器在瀏覽的時候不受任何影響，因為Cookie會被放在瀏覽器頭中傳送出去(包括ajax的時 候)，應用程式也一般不會在js裡操作這些敏感Cookie的，對於一些敏感的Cookie我們採用HttpOnly，對於一些需要在應用程式中用js操作的cookie我們就不予設定，這樣就保障了Cookie資訊的安全也保證了應用。

具體程式碼實現：在web伺服器tomcat的配置檔案server.xml中新增：

<Context docBase="E:\tomcat\apache-tomcat-6.0.24/webapps/netcredit" path="/netcredit" reloadable="false" useHttpOnly="true"/>

或者在專案的web.xml 配置如下：

<session-config>
<cookie-config>
<http-only>true</http-only>
</cookie-config>
</session-config>

瀏覽器cookie截圖

PS：Cookie設定HttpOnly，Secure，Expire屬性

http://blog.csdn.net/a19881029/article/details/27536917
--------------------- 
轉載：https://blog.csdn.net/tanzhen1991910/article/details/52992726