◆王保錦 林 卉 王健如 李桂青

跨站請求偽造攻擊技術(shù)淺析

◆王保錦 林 卉 王健如 李桂青

（山東曲阜師范大學(xué)（軟件學(xué)院） 山東 273100）

隨著WEB應(yīng)用逐漸普及，這提升了用戶的使用體驗，但是隨之而來的安全漏洞時刻威脅著服務(wù)提供商與用戶，引起人們對網(wǎng)絡(luò)安全問題的關(guān)注。本文以“跨站”腳本201D攻擊為例，首先對CSRF攻擊技術(shù)的基本概念進行介紹，分析“跨站”請求偽造攻擊原理，復(fù)現(xiàn)攻擊場景，剖析該類漏洞的利用方法與觸發(fā)條件。根據(jù)“跨站”請求偽造攻擊的特點提出三種防御策略，為服務(wù)器安全體系結(jié)構(gòu)的設(shè)計提供思路。

CSRF攻擊；Web應(yīng)用；“跨站”腳本攻擊

近年來，作為網(wǎng)絡(luò)內(nèi)容傳播和通訊載體的Web應(yīng)用越來越多。在優(yōu)化用戶體驗、提升工作效率的同時，也可能會帶來巨大的隱私泄露風(fēng)險。本文通過使用相關(guān)檢測工具，模擬攻擊場景，評估漏洞風(fēng)險。從對安全策略、攻擊方式的分析中總結(jié)經(jīng)驗，為將來開發(fā)高效防御應(yīng)用打下基礎(chǔ)。

1 “跨站”請求偽造攻擊簡介

CSRF（Cross Site Request Forgery），其攻擊的目的是偽造用戶請求，非法修改數(shù)據(jù)。受害者訪問并登錄存在CSRF漏洞的網(wǎng)站后，獲得服務(wù)器發(fā)送的身份信息，攜帶身份信息訪問攻擊者制作的攻擊頁面，攻擊頁面跨域向原網(wǎng)站提交請求，主流瀏覽器默認(rèn)攜帶受害者的身份信息，存在CSRF漏洞的網(wǎng)站收到請求后，將執(zhí)行攻擊者的請求。

圖1 CSRF攻擊流程

2 “跨站”請求偽造攻擊原因分析

通過剖析安全策略以及瀏覽器對安全策略的執(zhí)行程度，明確如何繞過安全策略，完成CSRF攻擊。在真實的應(yīng)用場景中存在一些安全策略，如cookie策略、同源策略、“跨源”資源共享策略等。本節(jié)將對上述安全策略進行分析，找到可能觸發(fā)CSRF漏洞的部分條件。

2.1 同源策略

同源策略（Same Origin Policy ，SOP），也稱為同域策略。瀏覽器的功能實現(xiàn)基于同源策略。同源策略是指一些動態(tài)腳本只被允許訪問與之同域名、協(xié)議、端口的資源。假設(shè)存在域：http：//csrftest.com/dir/test.html （默認(rèn)80端口），在HTML中，一些標(biāo)簽的“src”屬性可以跨域請求資源，例如＜iframe＞、＜img＞、＜svg＞。這些標(biāo)簽對資源的加載本質(zhì)上是對目標(biāo)資源發(fā)送的請求。另外，XMLHttpRequest（XHR）不能跨域請求資源，但它可以訪問同源的內(nèi)容以及提交跨域請求，CSRF攻擊正是利用了該特性實施攻擊。

2.2 cookie策略

HTTP無法保存用戶狀態(tài)，為了提高用戶使用體驗，出現(xiàn)了cookie技術(shù)。cookie分為臨時cookie和本地cookie。臨時cookie在關(guān)閉瀏覽器后失效，而本地cookie會在到達(dá)響應(yīng)頭中expires屬性[2]指定的時間后自動失效。主流瀏覽器如火狐，chrome等在進行跨域資源請求時默認(rèn)允許攜帶第三方cookie，為CSRF攻擊創(chuàng)造了條件。

2.3 “跨源”資源共享策略

“跨源”資源共享（Cross Origin Resouce Sharing ，CORS）是W3C委員會在制定HTML5標(biāo)準(zhǔn)時，為了解決日益增多的“跨站資源請求而提出來的標(biāo)準(zhǔn)。CORS策略將請求分為簡單請求和非簡單請求[3]。

簡單請求：瀏覽器向網(wǎng)站A發(fā)起簡單請求，網(wǎng)站A根據(jù)自身設(shè)置的相關(guān)字段的值與請求附帶的相關(guān)值進行對比，判斷是否允許該請求。如果通過驗證會返回請求內(nèi)容，否則“HTTP狀態(tài)碼”置為403。

非簡單請求：瀏覽器不會直接發(fā)送用戶的跨域請求，而是先發(fā)送請求方法為option的預(yù)先驗證請求，網(wǎng)站B接收到非簡單請求后，會通過對請求頭的相關(guān)字段進行驗證決定是否允許此跨域請求。如果驗證通過，則瀏覽器發(fā)送跨域請求，否則將“HTTP狀態(tài)碼”置為403。

但是CORS策略也存在安全問題。如果通過XHR對象將WithCredentials屬性的值設(shè)置為true，Content-Type字段的值設(shè)為“multi-part/form-data”的同時，服務(wù)器端將“Access-Control-Allow-Credentials”字段的值設(shè)置為true，則瀏覽器會攜帶cookie直接向服務(wù)器發(fā)送請求，為CSRF攻擊提供了條件。

3 “跨站”請求偽造攻擊實現(xiàn)

3.1 基于GET請求的CSRF攻擊

通過模擬用戶操作進行抓包發(fā)現(xiàn)，請求方式為GET，攜帶cookie，可能存在CSRF攻擊。編寫攻擊頁面，其中，payload為

3.2 基于TOKEN驗證的CSRF攻擊

通過對目標(biāo)網(wǎng)站分析，發(fā)現(xiàn)TOKEN作為其中一個input標(biāo)簽的屬性值隱藏在了表單當(dāng)中。同時，對留言板界面進行測試，發(fā)現(xiàn)如圖2所示XSS漏洞：

圖2 網(wǎng)站存在存儲型XSS漏洞

攻擊者首先在留言板寫入XSS代碼。當(dāng)用戶訪問留言板時， XSS代碼自動獲取當(dāng)前用戶token并向服務(wù)器發(fā)送請求。

4 “跨站”請求攻擊防御

4.1 請求頭驗證

請求頭中的referer字段表明了請求來源[4]。通過在服務(wù)器端添加對請求頭字段的驗證拒絕一切“跨站”請求。

4.2 驗證碼驗證

通過觸發(fā)式、嵌入式、字符式驗證碼易于攔截“跨站”請求偽造攻擊。對敏感操作添加隨機驗證碼，驗證碼強制只有用戶與Web應(yīng)用完成交互后才能實現(xiàn)正常的請求[5]。這種方法防范效率較高，但影響了用戶的使用體驗。

4.3 token驗證

令牌（token）通常作為一種身份標(biāo)識，如果來自瀏覽器請求中的token值與服務(wù)器發(fā)送給用戶的token不匹配或者請求中token不存在，則拒絕該請求。使用token驗證可以有效防止CSRF攻擊，優(yōu)化了用戶體驗。但該方式增加了后端數(shù)據(jù)處理的工作量。

4.4 same-site字段驗證

在HTTP的響應(yīng)頭中，same-site有兩種值：strict或lax。當(dāng)設(shè)置為strict時，則表明該服務(wù)器發(fā)送的cookie值不允許附帶在第三方請求中；當(dāng)設(shè)置為lax時，如果請求類型為同步請求且請求方式為GET，則允許此cookie作為請求頭的附帶信息。將same-site的值設(shè)為strict可破壞產(chǎn)生CSRF攻擊的必要條件。

5 結(jié)束語

本文闡述了CSRF攻擊的概念、產(chǎn)生原因、場景以及常見的防御方法。在防范CSRF攻擊時，應(yīng)選擇折中的方案，既要優(yōu)化用戶體驗，又要考慮服務(wù)器性能，達(dá)到用戶體驗與服務(wù)器負(fù)載的平衡。用戶與網(wǎng)絡(luò)管理員應(yīng)提高安全意識，避免遭到與XSS、社會工程學(xué)結(jié)合的CSRF攻擊。

[1]徐淑芳.服務(wù)器端CSRF防御研究[D].江西師范大學(xué)，2014.

[2]陳萬坡.基于WEB應(yīng)用程序技術(shù)的CSRF攻擊與防御技術(shù)[D].上海交通大學(xué)，2015.

[3]Hosee.CORS與CSRF[EB/OL].https://my.oschin a.net/hosee/blog/903665，2017-5-18.

[4]陳春艷.“跨站”請求偽造攻擊的基本原理與防范[J].電腦知識與技術(shù)，2014，10（05）：902-904.