摘要：前言對于一個影子殺手而言，總能殺人于無形。前端也有影子殺手，它總是防不勝防地危害著你的網站本篇打算介紹一些前端的影子殺手們和。影子殺手們，由來已久，幾乎伴隨著整個互聯網的發展。

對于一個影子殺手而言，總能殺人于無形。前端也有影子殺手，它總是防不勝防地危害著你的網站

本篇打算介紹一些前端的影子殺手們——XSS和CSRF。或許，你對它恨之入骨；又或者，你運用的得心應手。恨之入骨，可能是因為你的網站被它搞得苦不堪言；得心應手，可能是因為你從事這項工作，每天都在和此類問題打交道。那我們今天就來了解它，防御它。如果你喜歡我的文章，歡迎評論，歡迎Star~。歡迎關注我的github博客

注：在開始正文之前，先聲明一下，所有的實驗環境均為本地搭建——DVWA。

影子殺手們，由來已久，幾乎伴隨著整個互聯網的發展。歷史的潮流，總是值得去考究，去深思的。可能在十年之前，這些問題層出不窮；隨著開發者安全意識的提高，總是多多少少可以避免的。那么，我們就先來看看，今天的第一位主角——XSS。

記得在學校的時候，玩過CTF，應對類似于XSS等網絡漏洞，總是會有固定的套路。今天我們也來了解了解這些套路。

XSS的全名叫做Cross-site Scripting。不知你可否會有個疑問，老外都喜歡將英文縮寫，但是為什么這個縮寫卻是XSS呢？因為只能怪它來的晚咯，被css搶先一步^_^。不過沒關系，并不阻礙我們記憶它。

XSS是一種代碼注入類攻擊，它允許攻擊者在其他人的電腦上面執行惡意的腳本代碼。往往XSS并不需要攻擊者去直接攻擊受害者的瀏覽器。攻擊者可以利用網站的漏洞，將這一段惡意代碼提交。然后，通過網站去傳遞給受害者，同時竊取受害者的信息等。

我們可以先看一個簡單的例子：

或許，你會好奇，我應該怎么去運用網站的漏洞，那我們先來看一張圖：

這是一個評論框，然后我們可以在其中輸入：

然后，你提交這條信息，如果該網站沒有做防護(例如：過濾)，那么，你所在的頁面會跳出如下畫面：

看了這個信息，或許你已經意識到了它的危害。因為如果可以這樣子隨意的運行js腳本，對于你客戶端的信息(例如：cookie)將統統被竊取。

回到我們的話題，在看到xss的基本效果之后，你會認為JavaScript是危險的嗎？

其實不然，真正的JavaScript是運行在比較嚴格的環境下面，并不會對操作系統或者其他應用造成傷害。不信的話，你可以打開控制臺，在里面隨意嘗試，你會發現你并沒有造成任何危害。那么，我們所謂的XSS的嚴重性，是吹的嗎？

那就更加不是了。首先，我們要申明的是——何為惡意代碼？惡意代碼的叫法，并不是因為它本身是有危害的，而是它的意圖是對使用者有害的。我們可以來看看，何為對使用者有害？例子：

JavaScript對于用戶的私密信息進行讀取(例如：cookies)。

JavaScript可以通過XMLHttpRequest發送任意的信息到任意的服務器上

JavaScript可以修改當前頁面中的任意DOM元素

這些行為，如果是不善的人所為，那么，將對使用者造成不可估量的損失。

XSS整個流程中，會出現不同的角色。演員表可分為：網站、受害者、攻擊者。

網站，通常是指那些會被受害者訪問的HTML頁面。

受害者，指的是那些訪問網站的普通用戶

攻擊者，則是那些躲在陰暗角落，敲擊著鍵盤的惡意用戶。通常，攻擊者還會具備一臺自己的服務器，用來接收發送過來的用戶信息。

整個流程圖，如下：

整個流程中，演員都是必須的環節，不然整個攻擊都無法完成。可從圖中看出4個步驟：

攻擊者選取一個具備漏洞的網站，在其數據庫插入惡意代碼

用戶向網站服務器請求這個被注入的網站

網站服務器響應用戶請求，并發送給用戶已被修改的網站

用戶完成訪問，同時注入的惡意代碼執行，將用戶的cookie發送給攻擊者服務器

希望你對這幅流程圖多看幾眼，因為它也將會是我們后續防御XSS的先決條件。之后，我們來看看XSS的分類情況

XSS的目標是在受害者的瀏覽器中執行惡意代碼。而實現這一目標，往往只有不同的途徑，主要可以分為三種：反射型XSS、存儲型XSS、基于DOM的XSS。

反射型XSS：用戶的惡意代碼字符串來源于受害者的請求，例如，郵件中參雜的惡意鏈接。

存儲型XSS：用戶的惡意代碼字符串來自于網站的數據庫。通常是我們圖中舉的例子——在評論中注入惡意代碼，讓受害者進行訪問

基于DOM型XSS：這種攻擊的漏洞主要在客戶端，而非服務端。一般比較少見。

由于存儲型的XSS的流程圖，我們已經在上面看到過了。之后，我們需要來看一看反射型的XSS流程圖，如圖：

可以看到流程中，并未向網站的數據庫中插入惡意代碼，而是由以下4步驟組成：

攻擊者向受害者傳遞一個網站URL地址

然后，受害者點擊了這個地址，同時會向網站發出請求

網站響應原先已經存在惡意代碼的網頁給用戶

當用戶加載完網頁之后，會向攻擊者的服務器發送私密信息。

這種形式往往是需要用戶進行點擊的。

還有一種基于DOM的XSS，平時運用較少，而且攻擊條件較為苛刻。在此不做討論。

我們看完分類之后，對于攻擊的大體流程已經掌握。

接下來的操作平臺，我比較推薦——DVWA。因為目前網上XSS漏洞比較少，主要也是因為開發者的重視，而且網上操作會導致一定的危害，所以在本地搭建開發環境是最好的選擇。

實際操作：

最初，我們需要安裝DVWA，這個教程網上有很多，所以，可以自行百度。

第一步，我們需要將DVWA的安全級別調低，因為不同的安全級別采取的防御措施不同。

第二步，我們開始在XSS reflected中進行xss試驗。

第三步，在輸入框中輸入""，如圖：

第四步：提交之后，我們即可看到彈窗(這里提醒一下盡量不要使用chrome，那個瀏覽器會屏蔽這些，最好使用老版本的IE)，如圖：

如果你具備后臺服務器的話，那么就可以將這個cookie通過請求的形式發送到服務器后臺上面，此處就不做演示了。

既然有人企圖使用這些玩意來危害使用者，那么，我們這些開發者在開發應用的過程中，自然會有應對之策。不知你還記得上面的攻擊流程圖沒有？如果忘記了，不妨回去看一眼。因為，最好的防御措施就是截斷攻擊環節中的任意一個環節。

首先，作為一個開發者，必須達成的一點共識是所有的用戶輸入都是不安全的。尤其是類似于XSS這類的注入型漏洞。我們可以通過兩個方式對其進行防御——編碼和驗證。

編碼：對于用戶的輸入而言，所輸入的內容只會作為數據，而不是代碼。

驗證：通過正則表達式等方式，去檢查用戶的輸入中是否帶有敏感字符等。

所以，我們的解決方案可以圍繞上述兩點進行展開：

輸入檢測
對用戶輸入的數據進行檢測。對于這些代碼注入類的漏洞原則上是不相信用戶輸入的數據的。所以，我們要對用戶輸入的數據進行一定程度上的過濾，將輸入數據中的特殊字符與關鍵詞都過濾掉，并且對輸入的長度進行一定的限制。只要開發的人員嚴格檢查每個輸入點，對每個輸入點的數據進行檢測和xss過濾，是可以阻止xss攻擊的。

輸出編碼
通過前面xss的原理分析，我們知道造成xss的還有一個原因是應用程序直接將用戶輸入的數據嵌入HTML頁面中了。如果我們對用戶輸入的數據進行編碼，之后在嵌入頁面中，那么html頁面會將輸入的數據當作是普通的數據進行處理。

Cookie安全
利用xss攻擊，我們可以輕易的獲取到用戶的cookie信息。那么我們需要對用戶的cookie進行一定的處理。首先，我們盡可能減少cookie中敏感信息的存儲，并且盡量對cookie使用hash算法多次散列存放。合理的使用cookie的httponly的屬性值。這樣可以防止惡意的js代碼對cookie的調用。

禁用腳本
可以在瀏覽器中進行js的安全設置。類似與chrome等瀏覽器都會攔截一些危險的xss操作，例如：想要讀取cookie時，瀏覽器會阻止這個操作，征求用戶指示，同時提醒用戶此類操作的危害性。

對于XSS而言，我們可以了解的內容就到此為止。如果你想要深究，可以看一些網絡安全的書籍，或者查閱其他的文章，均可得到詳細的解答。下面我們需要介紹我們的第二位主角——CSRF

還記得第一位主角的名字叫什么嗎？是叫——跨站腳本攻擊。那么第二位主角也有一個類似的名字——跨站請求偽造(Cross-site request forgery)。

CSRF 顧名思義，是偽造請求，冒充用戶在站內的正常操作。我們知道，絕大多數網站是通過 cookie 等方式辨識用戶身份（包括使用服務器端 Session 的網站，因為 Session ID 也是大多保存在 cookie 里面的），再予以授權的。所以要偽造用戶的正常操作，最好的方法是通過 XSS 或鏈接欺騙等途徑，讓用戶在本機（即擁有身份 cookie 的瀏覽器端）發起用戶所不知道的請求。

CSRF這種攻擊方式在2000年已經被國外的安全人員提出，但在國內，直到06年才開始被關注，08年，國內外的多個大型社區和交互網站分別爆出CSRF漏洞，如：NYTimes.com（紐約時報）、Metafilter（一個大型的BLOG網站），YouTube和百度HI......

或許，我們現在對它了解的少了，但是網絡中的確還留有它的足跡。我們具體的操作就不實際操作了。我們可以來看一下CSRF的原理，如圖(該圖來自一篇知名的博客，在此注明)：

可以從圖中看到以下步驟：

首先用戶會登錄網站A，之后在通過驗證之后，會由cookie來進行信息的傳遞

這時，用戶又訪問了網站B(例如：郵件鏈接等形式)，用戶會在不知情的情況下，利用用戶在網站A的cookie，對網站A發送第三方請求。

A站點通常不會關注這個訪問是來自用戶或者網站B

CSRF也可會分成兩種形式的攻擊：站內攻擊和站外攻擊

CSRF站內類型的漏洞在一定程度上是由于程序員濫用$_REQUEST類變量造成的，一些敏感的操作本來是要求用戶從表單提交發起POST請求傳參給程序，但是由于使用了$_REQUEST等變量，程序也接收GET請求傳參，這樣就給攻擊者使用CSRF攻擊創造了條件，一般攻擊者只要把預測好的請求參數放在站內一個貼子或者留言的圖片鏈接里，受害者瀏覽了這樣的頁面就會被強迫發起請求。

CSRF站外類型的漏洞其實就是傳統意義上的外部提交數據問題，一般程序員會考慮給一些留言評論等的表單加上水印以防止SPAM問題，但是為了用戶的體驗性，一些操作可能沒有做任何限制，所以攻擊者可以先預測好請求的參數，在站外的Web頁面里編寫javascript腳本偽造文件請求或和自動提交的表單來實現GET、POST請求，用戶在會話狀態下點擊鏈接訪問站外的Web頁面，客戶端就被強迫發起請求。

CSRF，對于目前而言攻擊較少，也是因為對于這方面的防御手段越來越成熟所導致的。下面，我們來看一下如何去防護CSRF的攻擊。

預防CSRF攻擊可以從兩方面入手：

正確使用GET、POST和cookie

在非GET請求的時候添加偽隨機碼

何為正確使用GET和POST呢？拿RESTful API舉例來說，GET是獲取資源，而POST是提交修改資源。那么我們在定義一個url時，遵循這個規則，就可以保證GET的非用戶請求，無法對服務器資源進行修改，這樣就可以防止GET的CSRF攻擊。

那么，你可能會疑惑，要是POST的請求攻擊怎么辦呢？這就需要從第二方面下手。

增加偽隨機碼的方式，一般可以分為三種：

為每個用戶生成一個cookie token，這樣可以保證在每次表單驗證時附帶上同一個偽隨機碼。這種方式是最簡單的，但是同時也需要保證cookie的安全。往往cookie中的信息是非常容易被盜取的，所以這種方案在保證沒有XSS的前提下是比較安全的。

每次請求生成驗證碼。這種方法是安全的，但是相對于用戶體驗來說，并不友好

不同表單包含一個不同的token。有興趣可以去了解一下，這種是比較安全的POST請求方式。

由于，現在對于CSRF的攻擊預防比較徹底，一般在沒有XSS的前提下，已經很難進行此類攻擊了。所以真實的實際操作環境并沒有多少。以往主要的攻擊手段還是，通過XSS對于cookie進行盜取，然后通過CSRF用戶數據進行修改。我們可以一個例子來說明最經典的銀行的例子：

如果銀行A允許以GET請求的形式來轉賬，我們這里大多指的不是實際生活中的，因為實際生活中銀行不可能只用get請求轉賬這么簡單操作：http://www.mybank.com/Transfe...

這是危險網站B的代碼段中有這么一句：

那么當你再回A銀行時，就會發現你的賬戶上已經少了1000元。

當然，這是假的。

前端安全，一直以來都是被關注的重點對象。我們在了解他們的同時，應該注重他們的防護，這就是對用戶的包含。可以是XSS的漏洞，時有發生，BAT等大廠的產品也不例外。今天總結了XSS和CSRF的攻擊與防護，是警醒自己，在以后的開發中多加注意，同時，也希望和你們一起分享。

如果你對我寫的有疑問，可以評論，如我寫的有錯誤，歡迎指正。你喜歡我的博客，請給我關注Star~呦github博客