關於CSRF跨域請求僞造的解決辦法

中秋節時候咱們的應用在短信驗證碼這塊被惡意刷單，好比被用來作垃圾短信之類的，若是大規模被刷也能形成不小的損失。這還只是短信驗證碼，若是重要的API遭到CSRF的攻擊，損失不可估量。因此緊急加班解決了CSRF的攻擊問題。

CSRF是什麼鬼？

CSRF（Cross-site request forgery），中文名稱：跨站請求僞造，也被稱爲：one click attack/session riding，縮寫爲：CSRF/XSRF。

CSRF能幹嗎？

你這能夠這麼理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求。CSRF可以作的事情包括：以你名義發送郵件，發消息，盜取你的帳號，甚至於購買商品，虛擬貨幣轉帳......形成的問題包括：我的隱私泄露以及財產安全。

CSRF特性？

依靠用戶標識危害網站

利用網站對用戶標識的信任

欺騙用戶的瀏覽器發送HTTP請求給目標站點

另外能夠經過IMG標籤會觸發一個GET請求，能夠利用它來實現CSRF攻擊。

 

CSRF原理

 

簡單來講，CSRF必須通過兩個步驟：

一、用戶訪問可信任站點A，併產生了相關的cookie；

二、用戶在訪問A站點時沒有退出，同時訪問了危險站點B；

你們同時訪問多個網站是很正常的事情，因此也很容易遭到CSRF的攻擊。

 

舉個栗子：

某電商網站A，你購買時候支付的操做是：http://www.market.com/Transfer.php?bankId=11&money=1000;
某危險網站B，他有段代碼是 <img src=http://www.market.com/Transfer.php?bankId=11&money=1000>

訪問A支付後你會發現銀行卡里面多扣了1000塊錢，why？經過get方式，你在訪問A網站進行支付操做時，A網站保存了你的cookie信息，若是B網站拿到了你的cookie或者他僞造的數據恰好就是cookie裏的，就能僞造你的請求，進行一樣的支付操做。

也許你會說，我換成post請求不就好了，可是若是你的server代碼沒有處理，同樣能夠進行僞造。

 

So，如何進行防護？

 

一、服務器端表單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泄露到其餘網站。

咱們就是採用的這種方法，由於基本上全部的請求都是經過ajax，咱們經過從新封裝ajax，在ajax頭部添加一個token，server去識別這個token，若是請求沒有這個token或者錯誤就拒絕。

 

四、CSRF攻擊是有條件的，當用戶訪問惡意連接時，認證的cookie仍然有效，因此當用戶關閉頁面時要及時清除認證cookie，對支持TAB模式(新標籤打開網頁)的瀏覽器尤其重要。

 

五、儘可能少用或不要用request()類變量，獲取參數指定request.form()仍是request. querystring ()，這樣有利於阻止CSRF漏洞攻擊，此方法只不能徹底防護CSRF攻擊，只是必定程度上增長了攻擊的難度。

 

六、 經過圖形驗證碼

相對來講圖形驗證碼應該是最安全的，可是咱們不可能在全部的API上去加上這麼個玩意兒，通常是在表單，好比註冊，登陸等，當用戶頻繁操做時出現，避免影響用戶體驗

 

因此建議之後ajax請求都儘可能加上token驗證，雖然不必定能防護全部的CSRF攻擊，可是能夠大幅度提高接口的安全性，中秋節加班經過緊急修復後，CSRF攻擊基本沒有了。