什么是CSRF

CSRF（Cross-site request forgery），中文名稱：跨站請(qǐng)求偽造，也被稱為：one click attack/session riding，縮寫(xiě)為：CSRF/XSRF。

那么CSRF到底能夠干嘛呢？你可以這樣簡(jiǎn)單的理解：攻擊者可以盜用你的登陸信息，以你的身份模擬發(fā)送各種請(qǐng)求。攻擊者只要借助少許的社會(huì)工程學(xué)的詭計(jì)，例如通過(guò)QQ等聊天軟件發(fā)送的鏈接(有些還偽裝成短域名，用戶無(wú)法分辨)，攻擊者就能迫使Web應(yīng)用的用戶去執(zhí)行攻擊者預(yù)設(shè)的操作。例如，當(dāng)用戶登錄網(wǎng)絡(luò)銀行去查看其存款余額，在他沒(méi)有退出時(shí)，就點(diǎn)擊了一個(gè)QQ好友發(fā)來(lái)的鏈接，那么該用戶銀行帳戶中的資金就有可能被轉(zhuǎn)移到攻擊者指定的帳戶中。

所以遇到CSRF攻擊時(shí)，將對(duì)終端用戶的數(shù)據(jù)和操作指令構(gòu)成嚴(yán)重的威脅；當(dāng)受攻擊的終端用戶具有管理員帳戶的時(shí)候，CSRF攻擊將危及整個(gè)Web應(yīng)用程序。

CSRF的原理

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

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

1. 登錄受信任網(wǎng)站A，并在本地生成Cookie 。
2. 在不退出A的情況下，訪問(wèn)危險(xiǎn)網(wǎng)站B。

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

• 你不能保證你登錄了一個(gè)網(wǎng)站后，不再打開(kāi)一個(gè)tab頁(yè)面并訪問(wèn)另外的網(wǎng)站，特別現(xiàn)在瀏覽器都是支持多tab的。
• 你不能保證你關(guān)閉瀏覽器了后，你本地的Cookie立刻過(guò)期，你上次的會(huì)話已經(jīng)結(jié)束。
• 上圖中所謂的攻擊網(wǎng)站，可能是一個(gè)存在其他漏洞的可信任的經(jīng)常被人訪問(wèn)的網(wǎng)站。

因此對(duì)于用戶來(lái)說(shuō)很難避免在登陸一個(gè)網(wǎng)站之后不點(diǎn)擊一些鏈接進(jìn)行其他操作，所以隨時(shí)可能成為CSRF的受害者。

CSRF攻擊主要是因?yàn)閃eb的隱式身份驗(yàn)證機(jī)制，Web的身份驗(yàn)證機(jī)制雖然可以保證一個(gè)請(qǐng)求是來(lái)自于某個(gè)用戶的瀏覽器，但卻無(wú)法保證該請(qǐng)求是用戶批準(zhǔn)發(fā)送的。

如何預(yù)防CSRF

過(guò)上面的介紹，讀者是否覺(jué)得這種攻擊很恐怖，意識(shí)到恐怖是個(gè)好事情，這樣會(huì)促使你接著往下看如何改進(jìn)和防止類似的漏洞出現(xiàn)。

CSRF的防御可以從服務(wù)端和客戶端兩方面著手，防御效果是從服務(wù)端著手效果比較好，現(xiàn)在一般的CSRF防御也都在服務(wù)端進(jìn)行。

服務(wù)端的預(yù)防CSRF攻擊的方式方法有多種，但思想上都是差不多的，主要從以下2個(gè)方面入手：

1. 正確使用GET,POST和Cookie；
2. 在非GET請(qǐng)求中增加偽隨機(jī)數(shù)；

我們上一章介紹過(guò)REST方式的Web應(yīng)用，一般而言，普通的Web應(yīng)用都是以GET、POST為主，還有一種請(qǐng)求是Cookie方式。我們一般都是按照如下方式設(shè)計(jì)應(yīng)用：

• GET常用在查看，列舉，展示等不需要改變資源屬性的時(shí)候；
• POST常用在下達(dá)訂單，改變一個(gè)資源的屬性或者做其他一些事情；

接下來(lái)我就以Go語(yǔ)言來(lái)舉例說(shuō)明，如何限制對(duì)資源的訪問(wèn)方法：

mux.Get("/user/:uid", getuser)
mux.Post("/user/:uid", modifyuser)

這樣處理后，因?yàn)槲覀兿薅诵薷闹荒苁褂肞OST，當(dāng)GET方式請(qǐng)求時(shí)就拒絕響應(yīng)，所以上面圖示中GET方式的CSRF攻擊就可以防止了，但這樣就能全部解決問(wèn)題了嗎？當(dāng)然不是，因?yàn)镻OST也是可以模擬的。

因此我們需要實(shí)施第二步，在非GET方式的請(qǐng)求中增加隨機(jī)數(shù)，這個(gè)大概有三種方式來(lái)進(jìn)行：

• 為每個(gè)用戶生成一個(gè)唯一的cookie token，所有表單都包含同一個(gè)偽隨機(jī)值，這種方案最簡(jiǎn)單，因?yàn)楣粽卟荒塬@得第三方的Cookie(理論上)，所以表單中的數(shù)據(jù)也就構(gòu)造失敗，但是由于用戶的Cookie很容易由于網(wǎng)站的XSS漏洞而被盜取，所以這個(gè)方案必須要在沒(méi)有XSS的情況下才安全。
• 每個(gè)請(qǐng)求使用驗(yàn)證碼，這個(gè)方案是完美的，因?yàn)橐啻屋斎腧?yàn)證碼，所以用戶友好性很差，所以不適合實(shí)際運(yùn)用。
• 不同的表單包含一個(gè)不同的偽隨機(jī)值，我們?cè)?.4小節(jié)介紹“如何防止表單多次遞交”時(shí)介紹過(guò)此方案，復(fù)用相關(guān)代碼，實(shí)現(xiàn)如下：

生成隨機(jī)數(shù)token

h := md5.New()
io.WriteString(h, strconv.FormatInt(crutime, 10))
io.WriteString(h, "ganraomaxxxxxxxxx")
token := fmt.Sprintf("%x", h.Sum(nil))

t, _ := template.ParseFiles("login.gtpl")
t.Execute(w, token)

輸出token

<input type="hidden" name="token" value="{{.}}">

驗(yàn)證token

r.ParseForm()
token := r.Form.Get("token")
if token != "" {
	//驗(yàn)證token的合法性
} else {
	//不存在token報(bào)錯(cuò)
}

這樣基本就實(shí)現(xiàn)了安全的POST，但是也許你會(huì)說(shuō)如果破解了token的算法呢，按照理論上是，但是實(shí)際上破解是基本不可能的，因?yàn)橛腥嗽?jì)算過(guò)，暴力破解該串大概需要2的11次方時(shí)間。

總結(jié)

跨站請(qǐng)求偽造，即CSRF，是一種非常危險(xiǎn)的Web安全威脅，它被Web安全界稱為“沉睡的巨人”，其威脅程度有此“美譽(yù)”便可見(jiàn)一斑。本小節(jié)不僅對(duì)跨站請(qǐng)求偽造本身進(jìn)行了簡(jiǎn)單介紹，還詳細(xì)說(shuō)明造成這種漏洞的原因所在，然后以此提了一些防范該攻擊的建議，希望對(duì)讀者編寫(xiě)安全的Web應(yīng)用能夠有所啟發(fā)。