導讀
防范CSRF攻擊對于互聯(lián)網企業(yè)來說意義重大，本文結合58金融的實踐場景，旨在幫助大家共同提高nodejs服務的安全性。
背景
Web端的跨站點請求偽造(Cross Site Request Forgery)攻擊，簡稱CSRF攻擊，存在巨大的危害性。CSRF里，攻擊者借用了受害者的身份對服務器發(fā)送請求，對服務器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作：危害小的如以受害者的名義發(fā)帖子，危害大的可以冒用受害者的賬號下單甚至轉賬。
舉個例子，受害者無意訪問到了某個邪惡網頁，該網頁里只需要定義一個圖片：
<img src=” https://hellobank.com/transfer/money/to/?accountId=6225&money=100” />
即可達到以受害者的名義向helloback的服務器發(fā)送該請求。如果恰好受害者之前訪問過hellobank，受害者的合法cookie很有可能會被自動帶上一起發(fā)送給hellobank服務器，進而通過后者的身份校驗，最終轉賬100元給6225賬號。
上面只是一個簡單偽造get請求的例子，事實上post請求也可以同樣偽造，而且攻擊方式也更為復雜。例如，CSRF結合XSS，受害者沒有訪問過任何邪惡網頁的前提下也會被CSRF攻擊成功。
由上可見，CSRF攻擊的危害性極大，特別是對于金融業(yè)務，很多接口都是和貨幣產品相關，被攻擊成功的話后果非常嚴重。58金融的全部web流量都由nodejs承接，由nodejs負責防御web相關的安全攻擊。針對CSRF攻擊，我們建立了一套專門的防御方案，在此分享給大家，共同提高web服務安全。
常見認知誤區(qū)
網上有很多文章介紹使用Http請求頭的referrer字段檢測是否CSRF，以及介紹使用Post請求代替Get請求來防御CSRF。其實這些手段僅僅是增加了CSRF攻擊的難度，并不能真正意義上防御。
想要100%防御CSRF攻擊，不僅涉及到后端（服務器）的工作，也涉及到前端（瀏覽器）的JAVAScript代碼改造。而且更為重要的是，光靠技術手段遠遠不夠，更需要前后端達成并遵守一套開發(fā)規(guī)則，才能徹底杜絕CSRF攻擊。
開發(fā)規(guī)則
我們在眾多實際項目中總結出如下6條規(guī)則。
規(guī)則1：get請求無需防御CSRF攻擊。
按照HTTP語義來說，get請求僅用于查詢，不能用于提交信息。也就是說任何一個get請求，都不應該導致后端業(yè)務狀態(tài)及業(yè)務數(shù)據(jù)的變化。攻擊者一定是希望通過CSRF攻擊造成后端業(yè)務數(shù)據(jù)的變化，如發(fā)帖購物轉賬等，沒有變化也就無需防御。（接口防惡意刷數(shù)的除外，不在本文的討論范圍）
該規(guī)則雖看似簡單，實際開發(fā)中卻常被接口制定者所忽略。在實際開發(fā)中我們見到很多開發(fā)中使用get請求提交信息，或者更為隱蔽的漏洞是，雖然get請求沒有提交任何信息，但卻導致了后端服務狀態(tài)或數(shù)據(jù)庫數(shù)據(jù)發(fā)生了改變。因此該規(guī)則的重點在于后端同學正確理解HTTP語義和定義前后端接口。
規(guī)則2：不攜帶業(yè)務cookie的請求無需防御
這條規(guī)則看似簡單，但往往最容易被開發(fā)人員所忽略。CSRF的攻擊者一定是希望冒用受害者的身份，通常更準確的術語是cookie，去發(fā)送某些請求到服務器以達到攻擊者的目的。但如果受害者連業(yè)務cookie都沒有的話，說明服務器根本不認識該受害者，攻擊者的目的也就無法實現(xiàn)了。換句話理解：用戶都沒登錄，不為系統(tǒng)識別，模擬他沒有任何收益。（接口防惡意刷數(shù)的除外，不在本文的討論范圍）
舉個例子，新聞網站的列表頁和詳情頁，一般都開放給所有人查看。攻擊者誘使其他非登錄用戶訪問某個新聞頁面，沒有收益且不會導致新聞網站后臺的業(yè)務和狀態(tài)數(shù)據(jù)改變，因此一般來講無需防范。（當然如果考慮到點擊量和曝光率、廣告費的話也有必要防御，這些不在本文討論范圍）
規(guī)則3：URL白名單里的post請求無需防范
業(yè)務中總會有一些接口，必須設置為禁止防御CSRF攻擊。比如第三方的回調請求，一般都是對方服務器直接發(fā)起請求到我們的服務器，根本沒有經過瀏覽器，因此肯定無法通過CSRF防御。這類請求一般是靠固定IP、業(yè)務token頒發(fā)的方式進行安全校驗。我們在服務端不做CSRF檢測和防御。很多銀行類接口如轉賬，以及微信公眾號配置服務器，這類請求經常需要銀行服務器或微信服務器異步回調我們的業(yè)務服務器，因此必須配置白名單，繞過CSRF檢測。
規(guī)則4：瀏覽器端發(fā)送post請求時，為header添加csrf參數(shù)，其值由業(yè)務cookie計算得出
規(guī)則5：服務器端收到post請求時，檢查其業(yè)務cookie及header中的csrf是否正確匹配
為什么最后這倆條規(guī)則要放一起呢？因為這倆條規(guī)則是CSRF防御的技術核心，前后端代碼配合一起作用，才能防御CSRF攻擊。單獨僅前端或后端防御肯定行不通。
首先，為什么要給請求增加header呢？因為受害者在訪問邪惡網頁時，受害者向我們的服務器所發(fā)出的請求，該請求和邪惡網頁的域名一定是不同的，這也是CSRF中的Cross-Site的含義。因此受到跨域的限制，攻擊者無法改變該請求的任何信息，特別是受害者的業(yè)務cookie值。
所以我們在瀏覽器端，給合法用戶請求的header上加上csrf的參數(shù)，并且該參數(shù)的值由業(yè)務cookie計算得出。如此則攻擊者無法事先知道受害者的cookie，也就無法計算出header的csrf參數(shù)。
然后在服務器端獲取業(yè)務cookie以及header中的csrf值進行匹配校驗，一致則認為是有效請求，不一致則認為是CSRF攻擊進行攔截。
規(guī)則6：可以使用專門的CSRF cookie替換業(yè)務cookie，但要保證cookie足夠隨機、無法被預測
針對某些網站，其業(yè)務cookie因安全原因或其他歷史原因設置為httponly，導致JavaScript無法讀取。此時我們需要在nodejs端生成一個可以被JavaScript讀取的cookie，專門負責處理CSRF邏輯。
具體實現(xiàn)
上述規(guī)則可以用如下代碼邏輯實現(xiàn)（代碼僅供邏輯展示，均已脫敏僅供參考）。
這里我們選用了koa2，將判斷邏輯抽象成一個函數(shù)，返回true時代表截獲到了CSRF攻擊。
然后在業(yè)務代碼里應用該方法，對CSRF攻擊返回403狀態(tài)碼。需要注意的是根據(jù)koa2的洋蔥模型，下面代碼應該放置在post路由中間件之前。
這里可以根據(jù)業(yè)務需要，適當拓展防御措施，如根據(jù)CSRF攻擊的頻次考慮增加校驗碼流程，或對IP進行限制。此處不做詳述。
作者簡介：
賈建容，58金融前端負責人，主要負責金融中后臺系統(tǒng)架構和建設。
