回顧CSRF (Cross Site Request Forgery)

以前項目中遇到了SameSite的使用, SameSite主要解決CSRF (Cross Site Request Forgery)問題，順便也回顧下CSRF吧。

1、原理

利用被攻擊網站服務器對用戶網頁瀏覽器的信任。

1. 用戶對合法網站的認證cookie(登陸態等）會保存在瀏覽器端；
2. 跨站請求時瀏覽器會攜帶相關cookie的；

當用戶瀏覽惡意網頁時，攻擊者經過一些技術手段欺騙用戶的瀏覽器去訪問一個用戶曾經認證過的網站並運行一些操做（如發郵件，發消息，甚至財產操做如轉帳和購買商品）。由於請求也是攜帶認證cookie信息的，服務端沒有合適的防護措施的話就很難識別請求是用戶正常請求仍是CSRF請求。

1.1 特色：

結合原理和CSRF命名能夠看出CSRF的特色：

1. Cross Site： 攻擊方在第三方站點；
2. Request Forgery： 當用戶瀏覽惡意站點時向被攻擊的服務器發送操做請求。

攻擊者不要獲取用戶的信息（cookie等），直接欺騙用戶的瀏覽器，讓其以用戶的名義運行操。

2、攻擊手段

直接引入前端安全系列之二：如何防止CSRF攻擊？的DEMO：

受害者登陸a.com，並保留了登陸憑證（Cookie）。
攻擊者引誘受害者訪問了b.com。
b.com 向 a.com 發送了一個請求：a.com/act=xx。瀏覽器會默認攜帶a.com的Cookie。
a.com接收到請求後，對請求進行驗證，並確認是受害者的憑證，誤覺得是受害者本身發送的請求。
a.com以受害者的名義執行了act=xx。
攻擊完成，攻擊者在受害者不知情的狀況下，冒充受害者，讓a.com執行了本身定義的操做。

3、防護

針對CSRF的攻擊原理，制定防護策略：

1. 攻擊來自第三方站點：

   • sameSite cookie：告訴瀏覽器禁止跨站請求攜帶cookie；
   • 同源檢測（驗證HTTP Referer字段）：服務器加強校驗。
2. 僞造請求
   生成沒法僞造的數據，服務器加強校驗，識別僞造請求。

3.1 驗證HTTP Referer字段

方案

[[科普]跨站請求僞造-CSRF防禦方法](https://www.freebuf.com/artic...

缺點

1. 雖然在CSRF攻擊中，Referer是沒法僞造的，可是維護比較困難；
2. Referer配置不許確的話，很容易阻斷正常請求；
3. 後期維護困難，隨着url的變化需不斷修改Referer；

總之不推薦使用

3.2 在請求地址中添加token並驗證

方案

[[科普]跨站請求僞造-CSRF防禦方法](https://www.freebuf.com/artic...
利用token標記合法請求。

CSRF token的生成，下發，上送，校驗

1. 生成

1. 由服務端生成隨機惟一的字符串（GUID, UUID等），並保存到服務端的session或者其餘服務端緩存（如Redis）;

   • token的緩存最好有過時時間；
2. 若是但願提升token的安全性能夠對生成的token進行對稱加密。

2. 下發

下發是服務端如何把生成的CSRF token傳給客戶端，方式不少了，看客戶端怎麼方便提取並傳給後端。

1. 千萬別，千萬別，千萬別經過Set-Cookie下發；
2. 噴到頁面裏做爲約定的全局變量；
3. 最好和後端一塊兒肯定一個標準的下發和上送方式。

3. 上送

上送：是客戶端調用接口時提取CSRF token並傳給服務。看請求接口類型也後不少上送方式。

1. 針對GET請求能夠放入queryString裏；
2. Form POST請求能夠添加隱藏域；
3. AJAX, fetch請求還能夠採用放入request header裏；
4. 最好和後端一塊兒肯定一個標準的上送方式。

4. 校驗

1. 服務端從請求裏獲取客戶端上送的token；
2. 解密（若是以前有加密的話）；
3. 再跟緩存（Session/Redis）的值對比。

4、哪些場景須要考慮CSFR

重要的場景都須要而且建議採用token方案，一些常見的case有：

1. 支付類場景（支付，轉帳，充值）；
2. 取消/關注好友，轉發，刪除（日誌，帖子等），發郵件等操做；
3. 信息更改類（更改手機號，郵箱等）。

參考：

整理自GitHub筆記：CSRF