胡文生

關(guān)鍵詞： CSRF；網(wǎng)絡(luò)攻擊；智慧救援；攻擊防御；LBS

中圖分類號：TP393 文獻(xiàn)標(biāo)識碼：A

文章編號：1009-3044（2023）20-0100-03

0 引言

CSRF的全稱為Cross Site Request Forgery，即跨站點請求偽造[1]。該漏洞于2000年由國外網(wǎng)絡(luò)安全人員首次發(fā)現(xiàn)并提出，在2006年，CSRF攻擊才引起了國內(nèi)安全從業(yè)人員的極大關(guān)注，2008年是CSRF漏洞集中爆發(fā)年，一些著名網(wǎng)站，如NYTimes.com、Metafilter、YouTube 和百度HI均報道發(fā)現(xiàn)網(wǎng)站上存在CSRF 漏洞[2-3]， 2013年OWASP（開放式Web應(yīng)用程序安全項目，一個致力于解決網(wǎng)絡(luò)安全挑戰(zhàn)的開放式Web社區(qū)）將CSRF評價為世界十大網(wǎng)絡(luò)安全漏洞之一[4]。但是相對于XSS（跨站腳本攻擊）比較受關(guān)注來說，由于CSRF很難識別和緩解，所以長期以來CSRF不被網(wǎng)絡(luò)從業(yè)人員重視，CSRF攻擊在某些Web安全威脅分類中沒有出現(xiàn)過，甚至有些人可能會有一種錯誤的印象，即針對XSS（跨站腳本攻擊）問題的防御也可能針對CSRF攻擊提供保護(hù)。其實XSS與CSRF攻擊原理、攻擊過程、防范措施以及造成的后果有很大不同，由于長期對CSRF了解的欠缺，很多Web應(yīng)用系統(tǒng)在開發(fā)過程中沒有對CSRF做有效的防范，導(dǎo)致目前有大量的網(wǎng)站存在CSRF漏洞，而且網(wǎng)站一旦存在該漏洞受到攻擊時就很難進(jìn)行防范，隨時都有可能爆發(fā)，所以CSRF也被稱為“沉睡的巨人”[5]。

1 CSRF 攻擊原理

從圖1可以看出，CSRF攻擊過程中Cookie扮演很重要的角色，Cookie用于記錄用戶登錄信息，使得用戶不需要每次訪問網(wǎng)站時都要輸入用戶名和密碼信息，當(dāng)用戶登錄某個網(wǎng)站成功后，Cookie用于實現(xiàn)客戶端與服務(wù)器端之間的狀態(tài)保持。用戶C通過可信任的瀏覽器向可信任的服務(wù)端網(wǎng)站A發(fā)送連接請求，一旦用戶C的賬號和密碼通過服務(wù)器端網(wǎng)站A驗證后，用戶C的瀏覽器就接受服務(wù)器端反饋回來的響應(yīng)報文，該報文包含有用戶登錄信息的Cookies值，客戶端瀏覽器通過獲取報文中Set-Cookie首部字段信息并保存Cookie信息，形成一個小型的純文本文件，下次客戶端C再次向服務(wù)器端網(wǎng)站發(fā)送請求時會自動在請求報文中加入Cookie值，服務(wù)器端通過Cookie識別出發(fā)送請求的客戶端是否為身份驗證過程的用戶。當(dāng)用戶成功登錄網(wǎng)站A，在沒有關(guān)閉登錄網(wǎng)站A頁面的瀏覽器時，不小心或者被攻擊者誘導(dǎo)點擊了攻擊者偽造的一個Web應(yīng)用網(wǎng)站B，而網(wǎng)站B可能包含有一段使用img、iframe等標(biāo)簽向可信任服務(wù)器端Web應(yīng)用網(wǎng)站A發(fā)送的請求報文，此時，發(fā)送的請求報文帶上了用戶C的Cookie，于是攻擊者通過偽造的Web應(yīng)用網(wǎng)站B達(dá)到模擬合法用戶C的目的，實現(xiàn)攻擊者的目的。

2 CSRF 防范措施

攻擊者可以使用CSRF攻擊冒充合法用戶執(zhí)行屬于合法用戶權(quán)限的任何操作。因此，網(wǎng)站給予用戶的權(quán)利越多，CSRF攻擊就越危險，如目標(biāo)用戶的賬戶具有完全權(quán)限，這可能會破壞整個Web應(yīng)用程序。然而，如果能夠理解Web應(yīng)用程序受到CSRF攻擊的所有步驟，就可以設(shè)計對策來阻止它。為了克服CSRF 攻擊，可以使用多種技術(shù)來保護(hù)服務(wù)器端的Web應(yīng)用程序和客戶端最終用戶免受CSRF攻擊。從CSRF攻擊原理來看，該類攻擊最主要的特點就是“冒充”合法用戶達(dá)到登錄Web應(yīng)用程序修改數(shù)據(jù)、盜取用戶信息的目的，因此，對CSRF攻擊的防御主要圍繞如何識別和預(yù)防合法用戶的身份被攻擊者“冒用”，客戶端和服務(wù)器端是防御CSRF攻擊的重點，從這個意義上來說CSRF保護(hù)和預(yù)防技術(shù)從宏觀上可分為三大類，即客戶端保護(hù)技術(shù)、服務(wù)器端保護(hù)技術(shù)、混合型保護(hù)技術(shù)[6]：1） 客戶端保護(hù)技術(shù)：客戶端在與服務(wù)器交互過程中主要涉及兩類信息，即從客戶端傳出去的HTTP請求以及由服務(wù)器反饋回來的響應(yīng)信息，因此客戶端保護(hù)技術(shù)可以通過監(jiān)視傳出HTTP請求和傳入響應(yīng)來保護(hù)用戶免受CSRF攻擊。客戶端保護(hù)技術(shù)與用戶使用網(wǎng)絡(luò)聯(lián)系緊密，用戶必須養(yǎng)成良好的上網(wǎng)習(xí)慣，如不輕易點擊不信任的網(wǎng)址、及時退出已經(jīng)登錄的賬戶、使用HTTP代理、安裝瀏覽器插件或反惡意軟件等方式。這些解決方案涉及僅在需要CSRF保護(hù)的單個計算機上運行的應(yīng)用程序（如客戶端瀏覽器），而無須服務(wù)器端的網(wǎng)站干預(yù)?，F(xiàn)有的客戶端對策過于嚴(yán)格，它們應(yīng)用暴力技術(shù)，阻止或剝離特定類型的所有跨源請求（包括GET、POST 等）的標(biāo)頭，這實際上可以防止CSRF攻擊，但這也會破壞用戶與許多依賴于經(jīng)過身份驗證的跨源請求的有效網(wǎng)站的會話。例如，使用第三方支付系統(tǒng)的網(wǎng)站或使用云計算平臺的公司使用的單點登錄解決方案。僅限客戶端的解決方案非常少見，也不完整[7]。

2） 服務(wù)端保護(hù)技術(shù)：相對于客戶端保護(hù)技術(shù)來說，服務(wù)器端保護(hù)技術(shù)可以采用的手段會更多一些，如使用Origin字段或Referer字段、添加token值、建立白名單、增加驗證碼等方式來防止CSRF攻擊。根據(jù)HTTP協(xié)議，在HTTP 請求頭部中包含有一個Refer字段，該字段記錄了合法用戶要訪問的目標(biāo)網(wǎng)站URL地址，服務(wù)端通過對該字段的校驗可以區(qū)分該請求是同域下還是跨站發(fā)起的，從而做出接受請求或拒絕請求的響應(yīng)，但是該種防御方式有時候也可能會失效或者誤傷，如有些瀏覽器或者攻擊者利用工具可以篡改 Referer字段的值達(dá)到攻擊的目的，同時用戶也可以通過對瀏覽器設(shè)置發(fā)送HTTP請求時不提供 Referer字段，甚至單點登錄時對用戶一個合法的請求也做出拒絕響應(yīng)。Origin字段防御原理與Referer字段類似，只不過HTML5中XHR2.0新增的功能，一般與服務(wù)端建立的白名單一起使用，不在白名單內(nèi)的http請求就會遭到拒絕，該字段在一定程度上能夠減輕 Referer字段引起的隱私問題，但大多數(shù)瀏覽器不支持該字段。添加token值比校驗Referer字段效果要更可靠，為了防止攻擊者冒用合法用戶經(jīng)過服務(wù)器端驗證的身份信息（即http請求中的cookie值），可以在http請求中以參數(shù)的形式添加一個隨機產(chǎn)生的token值，客戶端每次發(fā)送http請求時都要帶上token值，服務(wù)器端驗證請求中的token值是否為服務(wù)器產(chǎn)生的并發(fā)送給客戶端的隨機數(shù)，若驗證不通過，有可能是CSRF攻擊而拒絕該請求。而驗證碼機制是所有服務(wù)器端防御CSRF 攻擊最好的方法，該方法強制要求用戶與Web應(yīng)用程序之間進(jìn)行實時交互，每次發(fā)送http請求之前先需要輸入基于服務(wù)端判斷的驗證碼，兩者一致才能完成最終請求，攻擊者很難獲取驗證碼的值，因此該方法成為目前防御CSRF攻擊的最佳方法為大多數(shù)商業(yè)網(wǎng)站所采用。

3） 混合型保護(hù)技術(shù)：包括客戶端和基于服務(wù)器的解決方案的組合。支持CSRF的客戶端應(yīng)用程序可識別Web服務(wù)器漏洞，并可能阻止此類攻擊。在這里，服務(wù)器應(yīng)用程序同樣涉及令人信服的大規(guī)模不斷發(fā)展的編程工作。

從上面闡述的CSRF攻擊原理和防范措施可以發(fā)現(xiàn)CSRF攻擊者雖然需要借助于經(jīng)過身份認(rèn)證的合法用戶的瀏覽器實施網(wǎng)絡(luò)攻擊，但是本質(zhì)上還是對Web 服務(wù)器的攻擊，這一事實導(dǎo)致許多防御CSRF攻擊的措施都是針對服務(wù)器端的解決方案。而且現(xiàn)有的客戶端對策需要用戶的廣泛參與，例如要求用戶定義受信任站點的白名單或彈出用戶確認(rèn)對話框，很多商業(yè)網(wǎng)站的用戶并不具備做出準(zhǔn)確安全決策的能力。就嚴(yán)重程度來說，攻擊者攻擊服務(wù)器所獲得的利益最大，對Web應(yīng)用程序傷害也是最大的，因此服務(wù)器端的保護(hù)技術(shù)尤為迫切。一般Web應(yīng)用程序都是由互聯(lián)網(wǎng)企業(yè)開發(fā)并搭建服務(wù)器，作為服務(wù)提供者有義務(wù)為用戶提供安全的網(wǎng)絡(luò)服務(wù)。綜合上述原因，CSRF 攻擊最好的解決方案是在服務(wù)器端解決。

3 基于CSRF防御的智慧道路救援系統(tǒng)設(shè)計與實現(xiàn)

基于LBS（Location Based Services，簡稱LBS） 的智慧救援公共服務(wù)平臺是基于現(xiàn)實社會需求開發(fā)設(shè)計一款Web應(yīng)用系統(tǒng)，該系統(tǒng)圍繞汽車救援行業(yè)的車主救援呼叫、救援過程、救援調(diào)度、救援評價、救援?dāng)?shù)據(jù)管理和應(yīng)用服務(wù)等場景，重點突破車輛故障信息快速獲取、救援位置服務(wù)自動獲取、服務(wù)過程安全監(jiān)督、評價信用機制建立、異構(gòu)信息資源集成、關(guān)鍵過程數(shù)據(jù)信息加密存儲等關(guān)鍵技術(shù)；探索適合汽車救援行業(yè)與互聯(lián)網(wǎng)、大數(shù)據(jù)等信息技術(shù)的融合發(fā)展，行業(yè)信息化服務(wù)內(nèi)容、模式和技術(shù)支撐體系；構(gòu)建科學(xué)、準(zhǔn)確、實時、安全的行業(yè)專業(yè)信息化服務(wù)平臺；實現(xiàn)救援“呼叫簡單化、過程可視化、調(diào)度智能化、體系標(biāo)準(zhǔn)化”?；贚BS的智慧救援公共服務(wù)平臺的服務(wù)端部署在第三方云服務(wù)商提供的云平臺上。除了云平臺提供相應(yīng)的安全保護(hù)外，Web應(yīng)用程序的所有者也必須根據(jù)自己系統(tǒng)的業(yè)務(wù)需求采取相應(yīng)的安全措施，確保系統(tǒng)能夠安全運行。

從系統(tǒng)的整個流程圖來看，涉及注冊登錄、下單/ 接單、支付結(jié)算、評價等功能，作為一個Web應(yīng)用程序來說，也面臨其他Web應(yīng)用程序所遇到的安全風(fēng)險，尤其是如XSS、SQL注入、中間人、網(wǎng)絡(luò)釣魚、CSRF等網(wǎng)絡(luò)攻擊風(fēng)險。在本系統(tǒng)中注冊/登錄、下單/接單、支付結(jié)算、評價等環(huán)節(jié)很容易受到CSRF攻擊，為了保證系統(tǒng)安全運行，必須結(jié)合開發(fā)過程中使用的技術(shù)、云平臺部署等因素綜合設(shè)計一個合理的防御CSRF攻擊的方案。本系統(tǒng)有兩個地方特別需要對CSRF攻擊進(jìn)行預(yù)防，一個是用戶注冊登錄階段，另一個是與社交賬號綁定的過程。前者可以采用CSRF最常用的隨機生成的token進(jìn)行驗證的方式來進(jìn)行預(yù)防。而后者則稍微復(fù)雜一些，利用OAuth2.0認(rèn)證技術(shù)提供綁定功能將系統(tǒng)用戶與其他社交賬號（如微信、QQ、微博等）綁定，提升用戶使用該系統(tǒng)快速登錄的用戶體驗，但是OAuth2.0技術(shù)如果使用不當(dāng)，很容易受到CSRF攻擊[8]。OAuth2.0在整個認(rèn)證流程中，攻擊者將自己提前從OAuth2.0服務(wù)器中獲得code 值設(shè)置為Authorization code參數(shù)的值并構(gòu)造攻擊網(wǎng)頁，誘導(dǎo)受害者點擊網(wǎng)頁，從而使得受害者將自己在Web應(yīng)用程序中的賬號與攻擊者的社交賬號綁定，使得攻擊者達(dá)到冒充受害者的合法身份登錄Web 應(yīng)用程序從事非法操作的目的。為防止OAuth2.0環(huán)境下的CSRF攻擊，Web應(yīng)用程序的開發(fā)者在設(shè)計OAuth2.0認(rèn)證請求時在URL中加入值為隨機字符串的state參數(shù)，OAuth2.0服務(wù)提供者返回Authorization code時，驗證一起返回的state參數(shù)值，若一致，則綁定社交賬號，否則拒絕。在整個過程中，OAuth2.0服務(wù)提供者相當(dāng)于服務(wù)器代理，具體防范CSRF攻擊過程見圖5。

4 結(jié)論

跨站點請求偽造（CSRF） 攻擊中，Web應(yīng)用程序?qū)ζ湟羊炞C用戶的信任被利用，從而允許攻擊者以受害者的名義進(jìn)行任意HTTP請求。CSRF防范措施有很多種，然而每一種都有相應(yīng)的缺陷、有一定的限制條件，當(dāng)前的CSRF緩解技術(shù)存在限制其普遍適用性的缺點。因此，解決CSRF攻擊問題，必須結(jié)合具體項目做出相應(yīng)的安排。本文結(jié)合具體的項目，利用OAuth2.0、Node.js 等平臺的特點設(shè)計一個綜合防范CSRF攻擊的解決方案，該解決方案提供了對CSRF攻擊的多方安全保護(hù)。