前言

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

本篇打算介紹一些前端的影子殺手們——XSS和CSRF÷站洌或許，你對(duì)它恨之入骨腌闯；又或者姿骏，你運(yùn)用的得心應(yīng)手。恨之入骨，可能是因?yàn)槟愕木W(wǎng)站被它搞得苦不堪言趁冈；得心應(yīng)手，可能是因?yàn)槟銖氖逻@項(xiàng)工作旺坠，每天都在和此類(lèi)問(wèn)題打交道。那我們今天就來(lái)了解它璧疗，防御它。如果你喜歡我的文章却音，歡迎評(píng)論，歡迎Star~夷陋。歡迎關(guān)注我的github博客

正文

注：在開(kāi)始正文之前，先聲明一下爹谭，所有的實(shí)驗(yàn)環(huán)境均為本地搭建——DVWA践惑。

影子殺手們凉袱，由來(lái)已久，幾乎伴隨著整個(gè)互聯(lián)網(wǎng)的發(fā)展涤躲。歷史的潮流，總是值得去考究，去深思的俐镐。可能在十年之前棍苹，這些問(wèn)題層出不窮；隨著開(kāi)發(fā)者安全意識(shí)的提高彬碱，總是多多少少可以避免的。那么嚼沿，我們就先來(lái)看看，今天的第一位主角——XSS攀细。

第一位主角——XSS

記得在學(xué)校的時(shí)候，玩過(guò)CTF故河，應(yīng)對(duì)類(lèi)似于XSS等網(wǎng)絡(luò)漏洞，總是會(huì)有固定的套路凑阶。今天我們也來(lái)了解了解這些套路。

概述

XSS的全名叫做Cross-site Scripting。不知你可否會(huì)有個(gè)疑問(wèn)宝冕，老外都喜歡將英文縮寫(xiě)菊卷，但是為什么這個(gè)縮寫(xiě)卻是XSS呢？因?yàn)橹荒芄炙鼇?lái)的晚咯渴庆，被css搶先一步^_刃滓。不過(guò)沒(méi)關(guān)系卓缰，并不阻礙我們記憶它。

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

我們可以先看一個(gè)簡(jiǎn)單的例子：

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

comment

這是一個(gè)評(píng)論框，然后我們可以在其中輸入：

comment

然后，你提交這條信息台颠，如果該網(wǎng)站沒(méi)有做防護(hù)(例如：過(guò)濾)，那么酪呻，你所在的頁(yè)面會(huì)跳出如下畫(huà)面：

xss

看了這個(gè)信息贼邓，或許你已經(jīng)意識(shí)到了它的危害女坑。因?yàn)槿绻梢赃@樣子隨意的運(yùn)行js腳本劳景，對(duì)于你客戶(hù)端的信息(例如：cookie)將統(tǒng)統(tǒng)被竊取。

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

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

那就更加不是了蜜托。首先，我們要申明的是——何為惡意代碼蜂挪？惡意代碼的叫法，并不是因?yàn)樗旧硎怯形：Φ难戏荆撬囊鈭D是對(duì)使用者有害的。我們可以來(lái)看看酝枢，何為對(duì)使用者有害？例子：

1. JavaScript對(duì)于用戶(hù)的私密信息進(jìn)行讀取(例如：cookies)官脓。
2. JavaScript可以通過(guò)XMLHttpRequest發(fā)送任意的信息到任意的服務(wù)器上
3. JavaScript可以修改當(dāng)前頁(yè)面中的任意DOM元素

這些行為，如果是不善的人所為妖滔，那么座舍，將對(duì)使用者造成不可估量的損失疲牵。

XSS中的角色扮演

XSS整個(gè)流程中亥鸠，會(huì)出現(xiàn)不同的角色。演員表可分為：網(wǎng)站家妆、受害者腰鬼、攻擊者姜挺。

網(wǎng)站，通常是指那些會(huì)被受害者訪問(wèn)的HTML頁(yè)面词渤。

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

攻擊者高氮，則是那些躲在陰暗角落塞淹，敲擊著鍵盤(pán)的惡意用戶(hù)坊谁。通常箍铲，攻擊者還會(huì)具備一臺(tái)自己的服務(wù)器，用來(lái)接收發(fā)送過(guò)來(lái)的用戶(hù)信息。

整個(gè)流程圖资盅，如下：

xss-process

整個(gè)流程中今穿，演員都是必須的環(huán)節(jié)，不然整個(gè)攻擊都無(wú)法完成芝薇。可從圖中看出4個(gè)步驟：

1. 攻擊者選取一個(gè)具備漏洞的網(wǎng)站侣滩，在其數(shù)據(jù)庫(kù)插入惡意代碼
2. 用戶(hù)向網(wǎng)站服務(wù)器請(qǐng)求這個(gè)被注入的網(wǎng)站
3. 網(wǎng)站服務(wù)器響應(yīng)用戶(hù)請(qǐng)求，并發(fā)送給用戶(hù)已被修改的網(wǎng)站
4. 用戶(hù)完成訪問(wèn)，同時(shí)注入的惡意代碼執(zhí)行唯竹，將用戶(hù)的cookie發(fā)送給攻擊者服務(wù)器

希望你對(duì)這幅流程圖多看幾眼旺拉，因?yàn)樗矊?huì)是我們后續(xù)防御XSS的先決條件晋涣。之后，我們來(lái)看看XSS的分類(lèi)情況

分類(lèi)

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

• 反射型XSS：用戶(hù)的惡意代碼字符串來(lái)源于受害者的請(qǐng)求，例如，郵件中參雜的惡意鏈接派近。
• 存儲(chǔ)型XSS：用戶(hù)的惡意代碼字符串來(lái)自于網(wǎng)站的數(shù)據(jù)庫(kù)。通常是我們圖中舉的例子——在評(píng)論中注入惡意代碼娜扇，讓受害者進(jìn)行訪問(wèn)
• 基于DOM型XSS：這種攻擊的漏洞主要在客戶(hù)端泊业，而非服務(wù)端。一般比較少見(jiàn)。

由于存儲(chǔ)型的XSS的流程圖胁附，我們已經(jīng)在上面看到過(guò)了菇存。之后絮供，我們需要來(lái)看一看反射型的XSS流程圖塘揣，如圖：

xss-reflect

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

1. 攻擊者向受害者傳遞一個(gè)網(wǎng)站URL地址
2. 然后切蟋，受害者點(diǎn)擊了這個(gè)地址，同時(shí)會(huì)向網(wǎng)站發(fā)出請(qǐng)求
3. 網(wǎng)站響應(yīng)原先已經(jīng)存在惡意代碼的網(wǎng)頁(yè)給用戶(hù)
4. 當(dāng)用戶(hù)加載完網(wǎng)頁(yè)之后祈惶，會(huì)向攻擊者的服務(wù)器發(fā)送私密信息克蚂。

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

還有一種基于DOM的XSS，平時(shí)運(yùn)用較少，而且攻擊條件較為苛刻栅屏。在此不做討論。

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

接下來(lái)的操作平臺(tái)，我比較推薦——DVWA。因?yàn)槟壳熬W(wǎng)上XSS漏洞比較少叠艳，主要也是因?yàn)殚_(kāi)發(fā)者的重視，而且網(wǎng)上操作會(huì)導(dǎo)致一定的危害凡纳，所以在本地搭建開(kāi)發(fā)環(huán)境是最好的選擇芜飘。

實(shí)際操作：

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

第一步颈走，我們需要將DVWA的安全級(jí)別調(diào)低种远，因?yàn)椴煌陌踩?jí)別采取的防御措施不同掂恕。

DVWA

第二步钧唐，我們開(kāi)始在XSS reflected中進(jìn)行xss試驗(yàn)镀裤。

第三步缴饭，在輸入框中輸入"<script>alert(document.cookie)</script>"暑劝，如圖：

XSS

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

xss

如果你具備后臺(tái)服務(wù)器的話丢氢，那么就可以將這個(gè)cookie通過(guò)請(qǐng)求的形式發(fā)送到服務(wù)器后臺(tái)上面傅联，此處就不做演示了。

防御

既然有人企圖使用這些玩意來(lái)危害使用者疚察，那么蒸走，我們這些開(kāi)發(fā)者在開(kāi)發(fā)應(yīng)用的過(guò)程中，自然會(huì)有應(yīng)對(duì)之策貌嫡。不知你還記得上面的攻擊流程圖沒(méi)有比驻？如果忘記了，不妨回去看一眼岛抄。因?yàn)楸鸬耄詈玫姆烙胧┚褪墙財(cái)喙舡h(huán)節(jié)中的任意一個(gè)環(huán)節(jié)。

首先夫椭，作為一個(gè)開(kāi)發(fā)者掸掸，必須達(dá)成的一點(diǎn)共識(shí)是所有的用戶(hù)輸入都是不安全的。尤其是類(lèi)似于XSS這類(lèi)的注入型漏洞蹭秋。我們可以通過(guò)兩個(gè)方式對(duì)其進(jìn)行防御——編碼和驗(yàn)證扰付。

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

驗(yàn)證：通過(guò)正則表達(dá)式等方式，去檢查用戶(hù)的輸入中是否帶有敏感字符等陪竿。

所以禽翼，我們的解決方案可以圍繞上述兩點(diǎn)進(jìn)行展開(kāi)：

1. 輸入檢測(cè)
   對(duì)用戶(hù)輸入的數(shù)據(jù)進(jìn)行檢測(cè)屠橄。對(duì)于這些代碼注入類(lèi)的漏洞原則上是不相信用戶(hù)輸入的數(shù)據(jù)的。所以闰挡，我們要對(duì)用戶(hù)輸入的數(shù)據(jù)進(jìn)行一定程度上的過(guò)濾锐墙，將輸入數(shù)據(jù)中的特殊字符與關(guān)鍵詞都過(guò)濾掉，并且對(duì)輸入的長(zhǎng)度進(jìn)行一定的限制长酗。只要開(kāi)發(fā)的人員嚴(yán)格檢查每個(gè)輸入點(diǎn)溪北，對(duì)每個(gè)輸入點(diǎn)的數(shù)據(jù)進(jìn)行檢測(cè)和xss過(guò)濾，是可以阻止xss攻擊的夺脾。

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

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

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

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

第二位主角——CSRF

還記得第一位主角的名字叫什么嗎慨代？是叫——跨站腳本攻擊邢笙。那么第二位主角也有一個(gè)類(lèi)似的名字——跨站請(qǐng)求偽造(Cross-site request forgery)。

概述

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

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

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

CSRF

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

1. 首先用戶(hù)會(huì)登錄網(wǎng)站A旋膳，之后在通過(guò)驗(yàn)證之后诱担，會(huì)由cookie來(lái)進(jìn)行信息的傳遞
2. 這時(shí)淮捆，用戶(hù)又訪問(wèn)了網(wǎng)站B(例如：郵件鏈接等形式)，用戶(hù)會(huì)在不知情的情況下嚷堡，利用用戶(hù)在網(wǎng)站A的cookie尸变，對(duì)網(wǎng)站A發(fā)送第三方請(qǐng)求义图。
3. A站點(diǎn)通常不會(huì)關(guān)注這個(gè)訪問(wèn)是來(lái)自用戶(hù)或者網(wǎng)站B

分類(lèi)

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

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

CSRF站外類(lèi)型的漏洞其實(shí)就是傳統(tǒng)意義上的外部提交數(shù)據(jù)問(wèn)題酗昼，一般程序員會(huì)考慮給一些留言評(píng)論等的表單加上水印以防止SPAM問(wèn)題廊谓，但是為了用戶(hù)的體驗(yàn)性，一些操作可能沒(méi)有做任何限制麻削，所以攻擊者可以先預(yù)測(cè)好請(qǐng)求的參數(shù)蒸痹，在站外的Web頁(yè)面里編寫(xiě)javascript腳本偽造文件請(qǐng)求或和自動(dòng)提交的表單來(lái)實(shí)現(xiàn)GET春弥、POST請(qǐng)求，用戶(hù)在會(huì)話狀態(tài)下點(diǎn)擊鏈接訪問(wèn)站外的Web頁(yè)面电抚，客戶(hù)端就被強(qiáng)迫發(fā)起請(qǐng)求惕稻。

防護(hù)

CSRF，對(duì)于目前而言攻擊較少蝙叛，也是因?yàn)閷?duì)于這方面的防御手段越來(lái)越成熟所導(dǎo)致的俺祠。下面，我們來(lái)看一下如何去防護(hù)CSRF的攻擊借帘。

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

• 正確使用GET蜘渣、POST和cookie
• 在非GET請(qǐng)求的時(shí)候添加偽隨機(jī)碼

何為正確使用GET和POST呢？拿RESTful API舉例來(lái)說(shuō)肺然，GET是獲取資源蔫缸，而POST是提交修改資源。那么我們?cè)诙x一個(gè)url時(shí)际起，遵循這個(gè)規(guī)則拾碌，就可以保證GET的非用戶(hù)請(qǐng)求，無(wú)法對(duì)服務(wù)器資源進(jìn)行修改街望，這樣就可以防止GET的CSRF攻擊校翔。

那么，你可能會(huì)疑惑灾前，要是POST的請(qǐng)求攻擊怎么辦呢防症？這就需要從第二方面下手。

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

• 為每個(gè)用戶(hù)生成一個(gè)cookie token蔫敲，這樣可以保證在每次表單驗(yàn)證時(shí)附帶上同一個(gè)偽隨機(jī)碼。這種方式是最簡(jiǎn)單的炭玫，但是同時(shí)也需要保證cookie的安全奈嘿。往往cookie中的信息是非常容易被盜取的，所以這種方案在保證沒(méi)有XSS的前提下是比較安全的础嫡。

• 每次請(qǐng)求生成驗(yàn)證碼指么。這種方法是安全的，但是相對(duì)于用戶(hù)體驗(yàn)來(lái)說(shuō)榴鼎，并不友好

• 不同表單包含一個(gè)不同的token。有興趣可以去了解一下晚唇，這種是比較安全的POST請(qǐng)求方式巫财。

小結(jié)

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

如果銀行A允許以GET請(qǐng)求的形式來(lái)轉(zhuǎn)賬扣讼，我們這里大多指的不是實(shí)際生活中的缺猛，因?yàn)閷?shí)際生活中銀行不可能只用get請(qǐng)求轉(zhuǎn)賬這么簡(jiǎn)單操作：http://www.mybank.com/Transfer.php?toBankId=11&money=1000

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

<img src=” http://www.mybank.com/Transfer.php?toBankId=11&money=1000”>

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

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

總結(jié)

前端安全销钝，一直以來(lái)都是被關(guān)注的重點(diǎn)對(duì)象有咨。我們?cè)诹私馑麄兊耐瑫r(shí)，應(yīng)該注重他們的防護(hù)蒸健，這就是對(duì)用戶(hù)的包含座享。可以是XSS的漏洞似忧，時(shí)有發(fā)生渣叛，BAT等大廠的產(chǎn)品也不例外。今天總結(jié)了XSS和CSRF的攻擊與防護(hù)橡娄，是警醒自己诗箍，在以后的開(kāi)發(fā)中多加注意，同時(shí)挽唉，也希望和你們一起分享滤祖。

如果你對(duì)我寫(xiě)的有疑問(wèn)，可以評(píng)論瓶籽，如我寫(xiě)的有錯(cuò)誤匠童，歡迎指正。你喜歡我的博客塑顺，請(qǐng)給我關(guān)注Star~呦github博客