基于CSRF防御的智慧道路救援系統設計

胡文生

關鍵詞： CSRF；網絡攻擊；智慧救援；攻擊防御；LBS

中圖分類號：TP393 文獻標識碼：A

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

0 引言

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

1 CSRF 攻擊原理

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

2 CSRF 防范措施

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

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

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

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

3 基于CSRF防御的智慧道路救援系統設計與實現

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

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

4 結論

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