1. XSS簡介
跨站腳本攻擊，英文全稱是Cross Site Script，本來縮寫是CSS，但是為了和層疊樣式(Cascading Style Sheet,CSS)有所區別，所以在安全領域叫做“XSS”。
XSS攻擊，通常是指黑客通過“HTML注入”篡改了網頁，插入了惡意的腳本，從而在用戶瀏覽網頁時，控制用戶瀏覽器的一種攻擊。在一開始，這種攻擊的演示案例是跨域的，所以叫做“跨站腳本”
XSS長期以來被列為客戶端Web安全中的頭號大敵。因為XSS破壞力強大，且產生的場景發雜，難以一次性解決。現在業內達成的共識是：針對各種不同場景產生的XSS，需要區分情景對待。
第一種類型：反射型XSS
反射型XSS只是簡單地把用戶輸入的數據“反射”給瀏覽器。也就是說，黑客往往需要誘使用戶“點擊”一個惡意鏈接，才能攻擊成功。反射型XSS也叫做“非持久型XSS”(Non-persistent XSS)
第二種類型：存儲型XSS
存儲型XSS會把用戶輸入的數據“存儲”在服務器端。這種XSS具有很強的穩定性。
比較常見的場景就是，黑客寫下一篇包含有惡意JavaScript代碼的博客文章，文章表達后，所有訪問該博客文章的用戶，都會在他們的瀏覽器中執行這段惡意的JavaScript代碼。黑客把惡意的腳本保存到服務器端，所以這種XSS攻擊叫做“存儲型XSS”。
存儲型XSS通常也叫做“持久型XSS”(Persistent XSS)，因為從效果上來說，它存在的時間比較長的。
第三種類型：DOM Based XSS
這種類型的XSS並非按照“數據收費保存在服務器端”來划分，DOM Based XSS從效果上來說也是反射型XSS。
XSS的防御
XSS的防御是復雜的。
流行的瀏覽器都內置了一些對抗XSS的措施，比如Firefox的CSP、Noscript擴展，IE 8內置的XSS Filter等。對於網站來說，也應該尋找優秀的解決方案，保護用戶不被XSS攻擊。
2.1 HttpOnly
HttpOnly最早是由微軟提出，並在IE 6中實現的，至今已經逐漸成為一個標准。瀏覽器將靜止頁面的JavaScript訪問帶有HttpOnly屬性的Cookie。
嚴格地來說，HttpOnly並非為了對抗XSS——HttpOnly解決的是XSS后的Cookie劫持。
2.3 正確地防御XSS
為了更好地設計XSS防御方案，需要認清XSS產生的本質原因。
XSS的本質還是一種“HTML注入”，用戶的數據被當成了HTML代碼的一部分來執行，從而混淆了原本的語義，產生了新的語義。
如果網站使用了MVC架構，那么XSS就發生在View層——在應用拼接變量到HTML頁面時產生。所以在用戶提交數據處進行輸入檢查的方案，其實並不是在真正發生攻擊的地方做防御。
想要根治XSS問題，可以列出所有XSS可能發生的場景，再一一解決。
換個角度看XSS的風險
前文談到的所有XSS攻擊，都是從漏洞形成的原理上看的。如果從業務風險的角度來看，則會有不同的觀點。
一般來說，存儲型XSS的風險會高於反射型XSS。因為存儲型XSS會保存在服務器上，有可能會跨頁面存在。它不改變頁面URL的原有結構，因此有時候還能逃過一些IDS的檢測。比如IE 8的XSS Filter和Firefox的Noscript Extension，都會檢查地址欄中的地址是否包含XSS腳本。而跨頁面的存儲型XSS可能會繞過這些檢測工具。
從攻擊過程來說，反射型XSS，一般要求攻擊者誘使用戶點擊一個包含XSS代碼的URL鏈接；而存儲型XSS，則只需要讓用戶查看一個正常的URL鏈接。比如一個Web郵箱的郵件正文頁面存在一個存儲型的XSS漏洞，當用戶打開一封新郵件時，XSS Payload會被執行。這樣的漏洞極其隱蔽，且埋伏在用戶的正常業務中，風險頗高。
從風險的角度看，用戶之間有互通的頁面，是可能發起XSS Worm攻擊的地方。而根據不同頁面的PageView高低，也可以分析出哪些頁面受XSS攻擊后的影響會更大。比如在網站首頁發生的XSS攻擊，肯定比網站合作伙伴頁面的XSS攻擊嚴重得多。
在修補XSS漏洞時遇到的最大挑戰之一是漏洞數量太多，因此開發者可能來不及，也不願意修補這些漏洞。從業務風險的角度來重新定位每個XSS漏洞，就具有了重要的意義。