20170813-CSRF 跨站請求僞造

CSRF

CSRF是Cross Site Request Forgery的縮寫，翻譯過來就是跨站請求僞造。

1. 跨站：顧名思義，就是從一個網站到另外一個網站。
2. 請求：即HTTP請求。
3. 僞造：在這裏能夠理解爲仿造、假裝。

• 綜合起來的意思就是：從一個網站A中發起一個到網站B的請求，而這個請求是通過了假裝的，假裝操做達到的目的就是讓請求看起來像是從網站B中發起的，也就是說，讓B網站所在的服務器端誤覺得該請求是從本身網站發起的，而不是從A網站發起的。
• CSRF 攻擊是黑客藉助受害者的 cookie 騙取服務器的信任，可是黑客並不能拿到 cookie，也看不到 cookie 的內容。另外，對於服務器返回的結果，因爲瀏覽器同源策略的限制，黑客也沒法進行解析。所以，黑客沒法從返回的結果中獲得任何東西，他所能作的就是給服務器發送請求，以執行請求中所描述的命令，在服務器端直接改變數據的值，而非竊取服務器中的數據。因此，咱們要保護的對象是那些能夠直接產生數據改變的服務，而對於讀取數據的服務，則不須要進行 CSRF 的保護。

原理

圖片來源： CSRF攻擊原理以及nodejs的實現和防護

　從上圖能夠看出，要假裝成從A網站發起請求，必須依次完成兩個步驟：

　　1.登陸受信任網站A，並在本地生成Cookie。

　　2.在不登出A的狀況下，訪問危險網站B。
　　

• 之因此要假裝成從A網站發起，是由於Cookie是不能跨域發送的。結合上面這個例子來講就是：若是從A網站直接發送請求到B網站服務器的話，是沒法將A網站中產生的Cookie一塊兒發給B服務器的。
• 爲何要發送Cookie呢？這是由於服務器在用戶登陸後會將用戶的一些信息放到Cookie中返回給客戶端，而後客戶端在請求一些須要認證的資源的時候會把Cookie一塊兒發給服務器，服務器經過讀取Cookie中的信息來進行用戶認證，認證經過後纔會作出正確的響應。
• B網站訪問A網站服務器的一些須要認證的資源的時候，若是沒有Cookie信息，服務器是拒絕訪問的，那麼B網站就沒法進行惡意操做。而僞形成AB網站的請求，就能夠將A網站的Cookie一塊兒發到A服務器，這個時候就服務器就認爲該請求是合法的，就會給出正確的響應，這個時候，B網站就達到目的了。

危害

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

如何防止CSRF攻擊

CSRF攻擊之因此可以成功，是由於黑客能夠徹底僞造用戶請求，該請求中全部的用戶驗證信息都是存在於cookie中，所以黑客能夠在不知道這些驗證信息的狀況下直接利用用戶的cookie來經過安全驗證。要抵禦CSRF，關鍵在於在請求中放入黑客沒法僞造的信息。

對於關鍵操做使用post方法：

如今的瀏覽器出於安全考慮，默認都作了必定的限制，form標籤發送到其餘網站的請求會被攔截

使用驗證碼：

強制用戶必須與應用進行交互，才能完成最終的請求。例如：用戶的每次提交表單行爲都須要填寫一個驗證碼

在請求地址中添加token並驗證 Anti CSRF Token

1. 服務端在收到路由請求時，生成一個隨機數，在渲染請求頁面時把隨機數埋入頁面（通常埋入 form 表單內，<input type="hidden" name="_csrf_token" value="xxxx">）
2. 服務端設置setCookie，把該隨機數做爲cookie或者session種入用戶瀏覽器
3. 當用戶發送 GET 或者 POST 請求時帶上_csrf_token參數（對於 Form 表單直接提交便可，由於會自動把當前表單內全部的 input 提交給後臺，包括_csrf_token）
4. 後臺在接受到請求後解析請求的cookie獲取_csrf_token的值，而後和用戶請求提交的_csrf_token作個比較，若是相等表示請求是合法的。

注意：

1. Token 最好保存在 Session 中。假如 Token 保存在 Cookie 中，用戶瀏覽器開了不少頁面(同一頁面打開了屢次)。在一些頁面 Token 被使用消耗掉後新的Token 會被從新種入，但那些老的 Tab 頁面對應的 HTML 裏仍是老 Token。這會讓用戶以爲爲啥幾分鐘前打開的頁面不能正常提交
2. 儘可能少用 GET。假如攻擊者在咱們的網站上傳了一張圖片，用戶在加載圖片的時候其實是向攻擊者的服務器發送了請求，這個請求會帶有referer表示當前圖片所在的頁面的 url。 而若是使用 GET 方式接口的話這個 URL 就形如：
   https://xxxx.com/gift?giftId=...

，那至關於攻擊者就獲取了_csrf_token，短期內可使用這個 token 來操做其餘 GET 接口。

1. 因爲用戶的Cookie很容易因爲網站的XSS漏洞而被盜取，因此這個方案必需要在沒有XSS的狀況下才安全。

檢測Referer：

Referer，根據 HTTP 協議，在 HTTP 頭中有一個字段叫 Referer，它記錄了該HTTP請求的來源地址。服務器經過檢查Referer的值，若是判斷
出Referer並不是本站頁面，而是一個外部站點的頁面，那麼咱們就能夠判斷出這個請求是非法的

這個方法是實現防止圖片盜鏈的原理

• 優勢：這種方法的顯而易見的好處就是簡單易行，網站的普通開發人員不須要操心 CSRF 的漏洞，只須要在最後給全部安全敏感的請求統一增長一個攔截器來檢查 Referer 的值就能夠。特別是對於當前現有的系統，不須要改變當前系統的任何已有代碼和邏輯，沒有風險，很是便捷。
• 缺點：Referer 的值是由瀏覽器提供的，雖然 HTTP 協議上有明確的要求，可是每一個瀏覽器對於 Referer 的具體實現可能有差異，並不能保證瀏覽器自身沒有安全漏洞。使用驗證 Referer 值的方法，就是把安全性都依賴於第三方（即瀏覽器）來保障，從理論上來說，這樣並不安全。對於某些低版本瀏覽器，目前已經有一些方法能夠篡改 Referer 值

在HTTP頭中自定義屬性

這種方法也是使用token並進行驗證，和上一種方法不一樣的是，這裏並非把 token 以參數的形式置於 HTTP 請求之中，而是把它放到 HTTP 頭中自定義的屬性裏。經過 XMLHttpRequest 這個類，能夠一次性給全部該類請求加上 csrftoken 這個 HTTP 頭屬性，並把 token 值放入其中。

參考：

對CSRF（跨站請求僞造）的理解

淺談CSRF攻擊方式

XSS跨站腳本攻擊與CSRF跨站請求僞造攻擊的學習總結。\

CSRF攻擊原理以及nodejs的實現和防護

CSRF 攻擊的應對之道