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

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

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

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

影子殺手們，由來已久，幾乎伴隨著整個互聯(lián)網(wǎng)的發(fā)展。歷史的潮流，總是值得去考究，去深思的?？赡茉谑曛?，這些問題層出不窮；隨著開發(fā)者安全意識的提高，總是多多少少可以避免的。那么，我們就先來看看，今天的第一位主角——XSS。

記得在學(xué)校的時候，玩過CTF，應(yīng)對類似于XSS等網(wǎng)絡(luò)漏洞，總是會有固定的套路。今天我們也來了解了解這些套路。

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

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

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

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

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

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

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

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

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

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

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

JavaScript可以通過XMLHttpRequest發(fā)送任意的信息到任意的服務(wù)器上

JavaScript可以修改當(dāng)前頁面中的任意DOM元素

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

XSS整個流程中，會出現(xiàn)不同的角色。演員表可分為：網(wǎng)站、受害者、攻擊者。

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

受害者，指的是那些訪問網(wǎng)站的普通用戶

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

整個流程圖，如下：

整個流程中，演員都是必須的環(huán)節(jié)，不然整個攻擊都無法完成?？蓮膱D中看出4個步驟：

攻擊者選取一個具備漏洞的網(wǎng)站，在其數(shù)據(jù)庫插入惡意代碼

用戶向網(wǎng)站服務(wù)器請求這個被注入的網(wǎng)站

網(wǎng)站服務(wù)器響應(yīng)用戶請求，并發(fā)送給用戶已被修改的網(wǎng)站

用戶完成訪問，同時注入的惡意代碼執(zhí)行，將用戶的cookie發(fā)送給攻擊者服務(wù)器

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

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

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

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

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

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

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

攻擊者向受害者傳遞一個網(wǎng)站URL地址

然后，受害者點擊了這個地址，同時會向網(wǎng)站發(fā)出請求

網(wǎng)站響應(yīng)原先已經(jīng)存在惡意代碼的網(wǎng)頁給用戶

當(dāng)用戶加載完網(wǎng)頁之后，會向攻擊者的服務(wù)器發(fā)送私密信息。

這種形式往往是需要用戶進(jìn)行點擊的。

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

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

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

實際操作：

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

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

第二步，我們開始在XSS reflected中進(jìn)行xss試驗。

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

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

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

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

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

編碼：對于用戶的輸入而言，所輸入的內(nèi)容只會作為數(shù)據(jù)，而不是代碼。

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

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

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

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

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

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

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

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

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

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

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

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

首先用戶會登錄網(wǎng)站A，之后在通過驗證之后，會由cookie來進(jìn)行信息的傳遞

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

A站點通常不會關(guān)注這個訪問是來自用戶或者網(wǎng)站B

CSRF也可會分成兩種形式的攻擊：站內(nèi)攻擊和站外攻擊

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

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

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

預(yù)防CSRF攻擊可以從兩方面入手：

正確使用GET、POST和cookie

在非GET請求的時候添加偽隨機(jī)碼

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

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

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

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

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

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

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

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

這是危險網(wǎng)站B的代碼段中有這么一句：

那么當(dāng)你再回A銀行時，就會發(fā)現(xiàn)你的賬戶上已經(jīng)少了1000元。

當(dāng)然，這是假的。

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

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