跨站請求偽造（CSRF）

概念

CSRF，全稱為Cross-Site Request Forgery，跨站請求偽造，是一種網路攻擊方式，它可以在使用者毫不知情的情況下，以使用者的名義偽造請求傳送給被攻擊站點，從而在未授權的情況下進行許可權保護內的操作。

具體來講，可以這樣理解CSRF。攻擊者借用使用者的名義，向某一伺服器傳送惡意請求，對伺服器來講，這一請求是完全合法的，但攻擊者確完成了一個惡意操作，比如以使用者的名義傳送郵件，盜取賬號，購買商品等等。

原理

CSRF攻擊原理比較簡單，例如Web A為存在CSRF漏洞的網站，Web B為攻擊者構建的惡意網站，User C為Web A網站的合法使用者。

• 使用者C開啟瀏覽器，訪問受信任網站A，輸入使用者名稱和密碼請求登入網站A； 　　
• 在使用者資訊通過驗證後，網站A產生Cookie資訊並返回給瀏覽器，此時使用者登入網站A成功，可以正常傳送請求到網站A；並且，此後從使用者瀏覽器傳送請求給網站A時都會預設帶上使用者的Cookie資訊； 　　
• 使用者未退出網站A之前，在同一瀏覽器中，開啟一個TAB頁訪問網站B； 　　
• 網站B接收到使用者請求後，返回一些攻擊性程式碼，併發出一個請求要求訪問第三方站點A； 　　
• 瀏覽器在接收到這些攻擊性程式碼後，根據網站B的請求，在使用者不知情的情況下攜帶Cookie資訊，向網站A發出請求。網站A並不知道該請求其實是由B發起的，所以會根據使用者C的Cookie資訊以C的許可權處理該請求，導致來自網站B的惡意程式碼被執行。

簡單來說，CSRF必須經過兩個步驟：

1、使用者訪問可信任站點A，併產生了相關的cookie;

2、使用者在訪問A站點時沒有退出，同時訪問了危險站點B。 疑問：為什麼網站A不能退出呢？

解決方法

伺服器端表單hash認證

在所有的表單裡面隨機生成一個hash，server在表單處理時去驗證這個hash值是否正確，這樣工作量比較大。

驗證http Referer欄位

根據HTTP協議，HTTP頭中的欄位Referer記錄了HTTP請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求必須來自於同一個網站。比如某銀行的轉賬是通過使用者訪問http://bank.test/test?page=10&userID=101&money=10000

頁面完成，使用者必須先登入bank.test，然後通過點選頁面上的按鈕來觸發轉賬事件。當用戶提交請求時，該轉賬請求的Referer值就會是轉賬按鈕所在頁面的URL（本例中，通常是以bank. test域名開頭的地址）。而如果攻擊者要對銀行網站實施CSRF攻擊，他只能在自己的網站構造請求，當用戶通過攻擊者的網站傳送請求到銀行時，該請求的Referer是指向攻擊者的網站。因此，要防禦CSRF攻擊，銀行網站只需要對於每一個轉賬請求驗證其Referer值，如果是以bank. test開頭的域名，則說明該請求是來自銀行網站自己的請求，是合法的。如果Referer是其他網站的話，就有可能是CSRF攻擊，則拒絕該請求。

在HTTP頭中自定義屬性並驗證

自定義屬性的方法也是使用token並進行驗證，和前一種方法不同的是，這裡並不是把token以引數的形式置於HTTP請求之中，而是把它放到HTTP頭中自定義的屬性裡。通過XMLHttpRequest這個類，可以一次性給所有該類請求加上csrftoken這個HTTP頭屬性，並把token值放入其中。這樣解決了前一種方法在請求中加入token的不便，同時，通過這個類請求的地址不會被記錄到瀏覽器的位址列，也不用擔心token會通過Referer洩露到其他網站。

--------------------- 本文來自 JiajiaAz 的CSDN 部落格 ，全文地址請點選：https://blog.csdn.net/qq_32657025/article/details/79476452?utm_source=copy