轉載自?XSS的那些事兒

XSS是什么

XSS，Cross-site scripting，跨站腳本攻擊，為了區分與CSS，起名為XSS。黑客利用網站的漏洞，通過代碼注入的方式將一些包含了惡意攻擊腳本程序注入到網頁中，企圖在用戶加載網頁時執行腳本來實施攻擊。腳本程序通常是JavaScript編寫，當然還包括Java，VBScript，ActiveX等。常見的攻擊手段是獲取用戶身份認證信息（Cookie，Session）、獲取私密網頁內容、植入病毒等。

XSS漏洞可以追溯到1990年代。Twitter，Facebook，MySpace，Orkut,新浪微博和百度貼吧這些網站曾遭受XSS漏洞攻擊或被發現此類漏洞。而最近幾年XSS升級為最流行的攻擊方式，有68%的網站可能遭受此類攻擊。根據開放網頁應用安全計劃（Open Web Application Security Project）公布的2010年統計數據，在Web安全威脅前10位中，XSS排在第2位，僅次于代碼注入。

場景還原

XSS是之所以能成功在于黑客注入的腳本程序在網頁上得到執行，那么它是怎么被注入？又是如何被執行的？我們來躺槍一次XSS攻擊就知道怎么回事了。

忙碌的一天過去了，下班后我打開博客，準備寫篇《XSS的那些事兒》。于是乎我偷偷的在內容處寫入了以下代碼：

<script>alert('I am a xss hacker.')</script>

提交發布博客后，我查看網頁的博客內容，頁面刷新時，就會彈出一個對話框:

之所以會彈出這個對話框，是因為我剛寫在內容中的那行JavaScript代碼被執行了（注入的代碼被執行）。我嘗試把這行代碼push到GitHub Page博客的Repository上，我就會遇到這種問題。它只是一句簡單的警告彈框，用戶登錄后的網站中嵌入下面代碼又會發生什么呢：

<script>
? ? var cockie = window.cockie; // localStorage, sessionStorage
? ? // Send cockie|localStorage|sessionStorage information to hacker
</script>

如果我訪問的博客網站使用了JWT做用戶認證，將Token保存在sessionStorage（cookie或 localStorage）中，而我無意間訪問了一個包含上述腳本的網頁，我的身份認證信息就會被黑客竊取，后續的事情就不得而知了。

XSS家族體系

根據XSS的表現形式和存儲形態，XSS主要分為三類反射性、持久型和基于DOM三種類型。而基于DOM型和反射型本質上又是一種類型。

反射型

XSS攻擊最開始出現是在那種服務器負責處理所有數據的網站中。比如一個Servlet+JSP的網站，服務器在處理完用戶的輸入（包含XSS）之后會將結果作為一個頁面（包含XSS）返回給用戶，XSS就會立即被執行，該類型就是典型的反射型XSS。

反射性是XSS中最基本的攻擊，用戶輸入（包含XSS）通常附加在HTTP查詢參數或者表單上，提交請求后，服務器直接返回結果就立即執行執行XSS。

反射型的攻擊主要針對個人用戶。黑客通常通過郵件發送包含一些看似沒有問題的URL（誘餌）給用戶，用戶點擊這些URL后就會跳轉到一個隱藏著XSS攻擊的網站。

持久型

我們知道反射型XSS需要使用誘惑用戶針對的是個人用戶，它的危害和波及范圍是可控的。而XSS被持久化到服務器數據庫中后，影響范圍就不再可控了。來回顧前文獲取cookie的XSS腳本：

<script>
? ? var cockie = window.cockie; // localStorage, sessionStorage
? ? // Send cockie|localStorage|sessionStorage information to hacker
</script>

如果該腳本被作為一篇博客文章的內容被原樣持久化到服務器端的數據庫中，之后任何用戶在瀏覽該博客文章的時候都會觸發瀏覽器執行該腳本，用戶的身份信息便會被盜走。

這種持久化在服務器端的XSS就是一種持久型的XSS攻擊，它的影響范圍是很廣。因為一旦被持久化到服務器，該博客網站的任何用戶都有可能遭遇攻擊。

基于DOM

隨著Web的發展，頁面承載了越來越多的展現邏輯，那么為了提高用戶體驗，頁面的渲染由同步轉向異步，架構師開始采用JavaScript+AJAX的方案。之后JavaScript就逐漸掌管頁面中數據請求和邏輯渲染。

JavaScript同時會處理用戶輸入并將其渲染出來。如果用戶輸入包含了XSS，此時XSS會以DOM的形式被執行。而這種XSS攻擊我們稱之為基于DOM型。

基于DOM型是由反射型衍生出來的一種新的類型，不同于反射型的是，后者需要服務器端的反射，而前者不會涉及跟服務器的交互。但它們本質上是一種類型，只是因為系統架構的演變而不得不進行基因變異。

防御措施

當我們使用cookie的時候，我們要防范CSRF，當我們使用了Token的時候，我們又得防范XSS，有種Web世界太危險，我要轉后端（服務器端）開發的姿態。不巧的是，恰恰從服務器端去阻止XSS攻擊才是有效的途徑。

從XSS的家族體系中可以看出XSS其實就是用戶輸入寄生蟲，所以只要能對癥下藥，正確處理用戶輸入，就能防御絕大部分XSS攻擊，甚至使其無地容身。

雙重校驗

對于用戶輸入，我們始終要保持懷疑的態度。要消除這種懷疑，我們要在瀏覽器端和服務器端做雙重嚴格校驗。

在安全架構方面，我們對JavaScript的定位是僅用于提高用戶體驗。所以瀏覽器校驗只是用來防君子，根本上需要在服務器端搭設一層可靠的防御網。針對雙重校驗，我們可以的事情主要有：

1.嚴格控制輸入的格式，比如年齡的input中，只允許用戶輸入數字。 2.對數據進行HTMLEncode處理，對URL進行URLEncode。

3.過濾或移除特殊的HTML標簽。例如: <script>,<iframe>,&lt;?

for <,&gt;for >, &quot for等。

4.過濾JavaScript事件的標簽。例如"οnclick=","onfocus"等

Web Framework在這方面一般都集成了XSS防御功能，比如Spring Security就提供了配置http.headers().xssProtection()的選項。

注入猴子

當我們處在危險境遇，我們不能坐以待斃。提前做一些主動的安全防御措施是絕對有必要的。比如說引入一些自動化的XSS監測機制。

借鑒著名的Netflix猴子軍的做法：

混亂猴子（Chaos Monkey）：

負責在一天隨機停掉服務器。

混亂大猩猩（Chaos Gorilla）：

負責隨機關閉整個可用區（數據中心）。

延遲猴子（Latency Monkey）：

則負責下系統之間注入網絡延遲。

Netflix的猴子軍的目標是在生產環境的制造故障，來鍛煉團隊對故障的應對能力。它核心理念：從錯誤中學習成長。所以我們既然要防御XSS，不妨引入一直注入猴子（Injectiion Monkey），它主要負責向我們的網站中注入類似腳本：

"/><script>alert(document.cookie)</script><!--
<script>alert(document.cookie)</script><!--
"onclick="alert(document.cookie)

特殊保護

XSS通常會盜用用戶身份信息，如果網站使用了Cookie中保存用戶Session的機制，則需要將重要的Cookie設置為httponly，即不讓JavaScript腳本去讀取Cooike信息。使用這種機制需要防范CSRF攻擊。如果你的網站使用了Token機制，則需要重點實施上述兩條措施。

總結

以上是生活随笔為你收集整理的XSS的那些事儿的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。