最近中文字幕免费2019,在线播放三级,国产亚洲日本

導(dǎo)讀

防范CSRF攻擊對(duì)于互聯(lián)網(wǎng)企業(yè)來說意義重大，本文結(jié)合58金融的實(shí)踐場(chǎng)景，旨在幫助大家共同提高nodejs服務(wù)的安全性。

背景

Web端的跨站點(diǎn)請(qǐng)求偽造(Cross Site Request Forgery)攻擊，簡(jiǎn)稱CSRF攻擊，存在巨大的危害性。CSRF里，攻擊者借用了受害者的身份對(duì)服務(wù)器發(fā)送請(qǐng)求，對(duì)服務(wù)器來說這個(gè)請(qǐng)求是完全合法的，但是卻完成了攻擊者所期望的一個(gè)操作：危害小的如以受害者的名義發(fā)帖子，危害大的可以冒用受害者的賬號(hào)下單甚至轉(zhuǎn)賬。

舉個(gè)例子，受害者無意訪問到了某個(gè)邪惡網(wǎng)頁(yè)，該網(wǎng)頁(yè)里只需要定義一個(gè)圖片：

<img src=” https://hellobank.com/transfer/money/to/?accountId=6225&money=100” />

即可達(dá)到以受害者的名義向helloback的服務(wù)器發(fā)送該請(qǐng)求。如果恰好受害者之前訪問過hellobank，受害者的合法cookie很有可能會(huì)被自動(dòng)帶上一起發(fā)送給hellobank服務(wù)器，進(jìn)而通過后者的身份校驗(yàn)，最終轉(zhuǎn)賬100元給6225賬號(hào)。

上面只是一個(gè)簡(jiǎn)單偽造get請(qǐng)求的例子，事實(shí)上post請(qǐng)求也可以同樣偽造，而且攻擊方式也更為復(fù)雜。例如，CSRF結(jié)合XSS，受害者沒有訪問過任何邪惡網(wǎng)頁(yè)的前提下也會(huì)被CSRF攻擊成功。

由上可見，CSRF攻擊的危害性極大，特別是對(duì)于金融業(yè)務(wù)，很多接口都是和貨幣產(chǎn)品相關(guān)，被攻擊成功的話后果非常嚴(yán)重。58金融的全部web流量都由nodejs承接，由nodejs負(fù)責(zé)防御web相關(guān)的安全攻擊。針對(duì)CSRF攻擊，我們建立了一套專門的防御方案，在此分享給大家，共同提高web服務(wù)安全。

常見認(rèn)知誤區(qū)

網(wǎng)上有很多文章介紹使用Http請(qǐng)求頭的referrer字段檢測(cè)是否CSRF，以及介紹使用Post請(qǐng)求代替Get請(qǐng)求來防御CSRF。其實(shí)這些手段僅僅是增加了CSRF攻擊的難度，并不能真正意義上防御。

想要100%防御CSRF攻擊，不僅涉及到后端（服務(wù)器）的工作，也涉及到前端（瀏覽器）的JAVAScript代碼改造。而且更為重要的是，光靠技術(shù)手段遠(yuǎn)遠(yuǎn)不夠，更需要前后端達(dá)成并遵守一套開發(fā)規(guī)則，才能徹底杜絕CSRF攻擊。

開發(fā)規(guī)則

我們?cè)诒姸鄬?shí)際項(xiàng)目中總結(jié)出如下6條規(guī)則。

規(guī)則1：get請(qǐng)求無需防御CSRF攻擊。

按照HTTP語(yǔ)義來說，get請(qǐng)求僅用于查詢，不能用于提交信息。也就是說任何一個(gè)get請(qǐng)求，都不應(yīng)該導(dǎo)致后端業(yè)務(wù)狀態(tài)及業(yè)務(wù)數(shù)據(jù)的變化。攻擊者一定是希望通過CSRF攻擊造成后端業(yè)務(wù)數(shù)據(jù)的變化，如發(fā)帖購(gòu)物轉(zhuǎn)賬等，沒有變化也就無需防御。（接口防惡意刷數(shù)的除外，不在本文的討論范圍）

該規(guī)則雖看似簡(jiǎn)單，實(shí)際開發(fā)中卻常被接口制定者所忽略。在實(shí)際開發(fā)中我們見到很多開發(fā)中使用get請(qǐng)求提交信息，或者更為隱蔽的漏洞是，雖然get請(qǐng)求沒有提交任何信息，但卻導(dǎo)致了后端服務(wù)狀態(tài)或數(shù)據(jù)庫(kù)數(shù)據(jù)發(fā)生了改變。因此該規(guī)則的重點(diǎn)在于后端同學(xué)正確理解HTTP語(yǔ)義和定義前后端接口。

規(guī)則2：不攜帶業(yè)務(wù)cookie的請(qǐng)求無需防御

這條規(guī)則看似簡(jiǎn)單，但往往最容易被開發(fā)人員所忽略。CSRF的攻擊者一定是希望冒用受害者的身份，通常更準(zhǔn)確的術(shù)語(yǔ)是cookie，去發(fā)送某些請(qǐng)求到服務(wù)器以達(dá)到攻擊者的目的。但如果受害者連業(yè)務(wù)cookie都沒有的話，說明服務(wù)器根本不認(rèn)識(shí)該受害者，攻擊者的目的也就無法實(shí)現(xiàn)了。換句話理解：用戶都沒登錄，不為系統(tǒng)識(shí)別，模擬他沒有任何收益。（接口防惡意刷數(shù)的除外，不在本文的討論范圍）

舉個(gè)例子，新聞網(wǎng)站的列表頁(yè)和詳情頁(yè)，一般都開放給所有人查看。攻擊者誘使其他非登錄用戶訪問某個(gè)新聞頁(yè)面，沒有收益且不會(huì)導(dǎo)致新聞網(wǎng)站后臺(tái)的業(yè)務(wù)和狀態(tài)數(shù)據(jù)改變，因此一般來講無需防范。（當(dāng)然如果考慮到點(diǎn)擊量和曝光率、廣告費(fèi)的話也有必要防御，這些不在本文討論范圍）

規(guī)則3：URL白名單里的post請(qǐng)求無需防范

業(yè)務(wù)中總會(huì)有一些接口，必須設(shè)置為禁止防御CSRF攻擊。比如第三方的回調(diào)請(qǐng)求，一般都是對(duì)方服務(wù)器直接發(fā)起請(qǐng)求到我們的服務(wù)器，根本沒有經(jīng)過瀏覽器，因此肯定無法通過CSRF防御。這類請(qǐng)求一般是靠固定IP、業(yè)務(wù)token頒發(fā)的方式進(jìn)行安全校驗(yàn)。我們?cè)诜?wù)端不做CSRF檢測(cè)和防御。很多銀行類接口如轉(zhuǎn)賬，以及微信公眾號(hào)配置服務(wù)器，這類請(qǐng)求經(jīng)常需要銀行服務(wù)器或微信服務(wù)器異步回調(diào)我們的業(yè)務(wù)服務(wù)器，因此必須配置白名單，繞過CSRF檢測(cè)。

規(guī)則4：瀏覽器端發(fā)送post請(qǐng)求時(shí)，為header添加csrf參數(shù)，其值由業(yè)務(wù)cookie計(jì)算得出

規(guī)則5：服務(wù)器端收到post請(qǐng)求時(shí)，檢查其業(yè)務(wù)cookie及header中的csrf是否正確匹配

為什么最后這倆條規(guī)則要放一起呢？因?yàn)檫@倆條規(guī)則是CSRF防御的技術(shù)核心，前后端代碼配合一起作用，才能防御CSRF攻擊。單獨(dú)僅前端或后端防御肯定行不通。

首先，為什么要給請(qǐng)求增加header呢？因?yàn)槭芎φ咴谠L問邪惡網(wǎng)頁(yè)時(shí)，受害者向我們的服務(wù)器所發(fā)出的請(qǐng)求，該請(qǐng)求和邪惡網(wǎng)頁(yè)的域名一定是不同的，這也是CSRF中的Cross-Site的含義。因此受到跨域的限制，攻擊者無法改變?cè)撜?qǐng)求的任何信息，特別是受害者的業(yè)務(wù)cookie值。

所以我們?cè)跒g覽器端，給合法用戶請(qǐng)求的header上加上csrf的參數(shù)，并且該參數(shù)的值由業(yè)務(wù)cookie計(jì)算得出。如此則攻擊者無法事先知道受害者的cookie，也就無法計(jì)算出header的csrf參數(shù)。

然后在服務(wù)器端獲取業(yè)務(wù)cookie以及header中的csrf值進(jìn)行匹配校驗(yàn)，一致則認(rèn)為是有效請(qǐng)求，不一致則認(rèn)為是CSRF攻擊進(jìn)行攔截。

規(guī)則6：可以使用專門的CSRF cookie替換業(yè)務(wù)cookie，但要保證cookie足夠隨機(jī)、無法被預(yù)測(cè)

針對(duì)某些網(wǎng)站，其業(yè)務(wù)cookie因安全原因或其他歷史原因設(shè)置為httponly，導(dǎo)致JavaScript無法讀取。此時(shí)我們需要在nodejs端生成一個(gè)可以被JavaScript讀取的cookie，專門負(fù)責(zé)處理CSRF邏輯。

具體實(shí)現(xiàn)

上述規(guī)則可以用如下代碼邏輯實(shí)現(xiàn)（代碼僅供邏輯展示，均已脫敏僅供參考）。

這里我們選用了koa2，將判斷邏輯抽象成一個(gè)函數(shù)，返回true時(shí)代表截獲到了CSRF攻擊。