SpringSecurity CSRF引發的思考Cookie、Session、Token和JWT

目錄

1.最重要的問題：

1.CSRF攻擊是怎樣跨域拿到cookie的？

2.怎樣阻止CSRF攻擊？

2.CSRF 跨站偽造請求

3.Cookie和Session

4.Cookie和Session的區別

5.什么是Token（重點）

僅僅用seesion＋cookie存在的問題

【疑問？】token放在客戶端哪里？客戶端是怎么每次取到token的

6.JSON Web Token（JWT）

Token和JWT：

1.最重要的問題：

1.CSRF攻擊是怎樣跨域拿到cookie的？

【疑問？】瀏覽器對于 cookie 也是存在同源限制的，也就是與 cookie（domain）處于不同源的網站，瀏覽器是不會讓該網站獲取到這個 cookie，那為什么csrf攻擊是可行的？

原因是瀏覽器使用 cookie 的情況

除了跨域 XHR 請求情況下，瀏覽器在發起請求的時候會把符合要求的 cookie 自動帶上，(域名，有效期，路徑，secure 屬性)，跨域 XHR 的請求的情況下，也可以攜帶 Cookie，同時瀏覽器允許跨域提交表單，也就是說，向同一個服務器發請求時會自動帶上瀏覽器保存的對于那個服務器的cookie，而不管你從哪個網站發請求，因為每次請求都會攜帶在http頭上，也是造成帶寬浪費的一個原因，但是讀取cookie是讀取不了的，攻擊者沒辦法知道cookie的內容

2.怎樣阻止CSRF攻擊？

1. 驗證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攻擊，則拒絕該請求，

2. 在請求地址中添加token并驗證

攻擊者在攻擊網站放一個src是被攻擊網站的轉賬表單，在session+cookie的情況下，用戶打開惡意網頁的時候就已經上當了了.因為form 發起的 POST 請求并不受到瀏覽器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域發送 POST 請求，形成 CSRF 攻擊，在post請求的瞬間，cookie會被瀏覽器自動添加到請求頭中，

解決思路：提交時要附加本域才能獲得資訊（token只有你正確輸入密碼之后才返還）

CSRF的一個特征是，攻擊者無法直接竊取到用戶的資訊（Cookie，Header，網站內容等），僅僅是冒用Cookie中的資訊，

而CSRF攻擊之所以能夠成功，是因為服務器誤把攻擊者發送的請求當成了用戶自己的請求，那么我們可以要求所有的用戶請求都攜帶一個CSRF攻擊者無法獲取到的Token，服務器通過校驗請求是否攜帶正確的Token，來把正常的請求和攻擊的請求區分開，也可以防范CSRF的攻擊，token是開發者為了防范csrf而特別設計的令牌，瀏覽器不會自動添加到headers里，攻擊者也無法訪問用戶的token，所以提交的表單無法通過服務器過濾，也就無法形成攻擊，

可以使用JWT來完成這個功能，拿Spring Security來說，可以將Spring Security中的CSRF功能關掉，因為我們已經使用了JWT，這已經能夠阻止CSRF攻擊，如果不用JWT呢？那么就會用session (配合sessionId放在cookie中)，此時需要用csrf-token.

另外：Token或者JWT可以放到cookie中，但是發送任何請求的時候，需要從cookie中獲取到token（客戶端從 cookie 中獲取，同源策略限制在其它域中對cookie 操作，也能防止CSRF攻擊），然后將token放到請求的header或者是引數中，但就是怕XSS攻擊，所以最安全的方法是將token放入local storage，可以同時防止CSRF和XSS攻擊

CSRF攻擊之所以能夠成功，是因為攻擊者可以偽造用戶的請求，該請求中所有的用戶驗證資訊都存在于Cookie中，因此攻擊者可以在不知道這些驗證資訊的情況下直接利用用戶自己的Cookie來通過安全驗證，由此可知，抵御CSRF攻擊的關鍵在于：在請求中放入攻擊者所不能偽造的資訊，并且該資訊不存在于Cookie之中，鑒于此，系統開發者可以在HTTP請求中以引數的形式加入一個隨機產生的token，并在服務器端建立一個攔截器來驗證這個token，如果請求中沒有token或者token內容不正確，則認為可能是CSRF攻擊而拒絕該請求，

3. 在HTTP頭中自定義屬性并驗證

攻擊者在攻擊網站放一個src是被攻擊網站的轉賬表單，在session+cookie的情況下，用戶打開惡意網頁的時候就已經上當了了.因為form 發起的 POST 請求并不受到瀏覽器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域發送 POST 請求，形成 CSRF 攻擊，在post請求的瞬間，cookie會被瀏覽器自動添加到請求頭中，

解決思路：提交時要附加本域才能獲得資訊（token只有你正確輸入密碼之后才返還）

CSRF的一個特征是，攻擊者無法直接竊取到用戶的資訊（Cookie，Header，網站內容等），僅僅是冒用Cookie中的資訊，

而CSRF攻擊之所以能夠成功，是因為服務器誤把攻擊者發送的請求當成了用戶自己的請求，那么我們可以要求所有的用戶請求都攜帶一個CSRF攻擊者無法獲取到的Token，服務器通過校驗請求是否攜帶正確的Token，來把正常的請求和攻擊的請求區分開，也可以防范CSRF的攻擊，token是開發者為了防范csrf而特別設計的令牌，瀏覽器不會自動添加到headers里，攻擊者也無法訪問用戶的token，所以提交的表單無法通過服務器過濾，也就無法形成攻擊，

可以使用JWT來完成這個功能，拿Spring Security來說，可以將Spring Security中的CSRF功能關掉，因為我們已經使用了JWT，這已經能夠阻止CSRF攻擊，如果不用JWT呢？那么就會用session(配合sessionId放在cookie中)，此時需要用csrf-token.

另外：Token或者JWT可以放到cookie中，但是發送任何請求的時候，需要從cookie中獲取到token（客戶端從 cookie 中獲取，同源策略限制在其它域中對cookie 操作，也能防止CSRF攻擊），然后將token放到請求的header或者是引數中，但就是怕XSS攻擊，所以最安全的方法是將token放入local storage，可以同時防止CSRF和XSS攻擊

自定義屬性的方法也是使用token并進行驗證，和前一種方法不同的是，這里并不是把token以引數的形式置于HTTP請求之中，而是把它放到HTTP頭中自定義的屬性里，通過XMLHttpRequest這個類，可以一次性給所有該類請求加上csrftoken這個HTTP頭屬性(當然也可以使用自定義header，根據自己需要)，并把token值放入其中，這樣解決了前一種方法在請求中加入token的不便，同時，通過這個類請求的地址不會被記錄到瀏覽器的地址欄，也不用擔心token會通過Referer泄露到其他網站，

2.CSRF 跨站偽造請求

攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊網站發送跨站請求，利用受害者在被攻擊網站已經獲取的注冊憑證，繞過后臺的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操作的目的，
一般流程如下：

該攻擊特點：

①攻擊一般發起在第三方網站，而不是被攻擊的網站，被攻擊的網站無法防止攻擊發生，
②攻擊利用受害者在被攻擊網站的登錄憑證，冒充受害者提交操作；而不是直接竊取資料，
③整個程序攻擊者并不能獲取到受害者的登錄憑證，僅僅是“冒用”，
④跨站請求可以用各種方式：圖片URL、超鏈接、CORS、Form提交等等，部分請求方式可以直接嵌入在第三方論壇、文章中，難以進行追蹤，
⑤CSRF通常是跨域的，因為外域通常更容易被攻擊者掌控，但是如果本域下有容易被利用的功能，比如可以發圖和鏈接的論壇和評論區，攻擊可以直接在本域下進行，而且這種攻擊更加危險，

針對其攻擊特點也是有一些列防護措施的，之后會講~

3.Cookie和Session

HTTP 是無狀態的協議（對于事務處理沒有記憶能力，每次客戶端和服務端會話完成時，服務端不會保存任何會話資訊）：每個請求都是完全獨立的，服務端無法確認當前訪問者的身份資訊，無法分辨上一次的請求發送者和這一次的發送者是不是同一個人，所以服務器與瀏覽器為了進行會話跟蹤（知道是誰在訪問我），就必須主動的去維護一個狀態，這個狀態用于告知服務端前后兩個請求是否來自同一瀏覽器，

而這個狀態需要通過 cookie 或者 session 去實作，

cookie 存盤在客戶端： cookie 是服務器發送到用戶瀏覽器并保存在本地的一小塊資料，它會在瀏覽器下次向同一服務器再發起請求時被攜帶并發送到服務器上，

cookie 是不可跨域的： 每個 cookie 都會系結單一的域名，無法在別的域名下獲取使用，一級域名和二級域名之間是允許共享使用的

session 是另一種記錄服務器和客戶端會話狀態的機制

session 是基于 cookie 實作的，session 存盤在服務器端，sessionId 會被存盤到客戶端的cookie 中

cookie只是實作session的其中一種方案，雖然是最常用的，但并不是唯一的方法，禁用cookie后還有其他方法存盤，比如放在url中

現在大多都是Session + Cookie，但是只用session不用cookie，或是只用cookie，不用session在理論上都可以保持會話狀態，可是實際中因為多種原因，一般不會單獨使用

用session只需要在客戶端保存一個id，實際上大量資料都是保存在服務端，如果全部用cookie，資料量大的時候客戶端是沒有那么多空間的，

如果只用cookie不用session，那么賬戶資訊全部保存在客戶端，一旦被劫持，全部資訊都會泄露，并且客戶端資料量變大，網路傳輸的資料量也會變大

4.Cookie和Session的區別

①安全性： Session 比 Cookie 安全，Session 是存盤在服務器端的，Cookie 是存盤在客戶端的，
②存取值的型別不同：Cookie 只支持存字串資料，想要設定其他型別的資料，需要將其轉換成字串，Session 可以存任意資料型別，
③有效期不同： Cookie 可設定為長時間保持，比如我們經常使用的默認登錄功能，Session 一般失效時間較短，客戶端關閉（默認情況下）或者 Session 超時都會失效，
④存盤大小不同： 單個 Cookie 保存的資料不能超過 4K，Session 可存盤資料遠高于 Cookie，但是當訪問量過多，會占用過多的服務器資源，

【疑問？】瀏覽器對于 cookie 也是存在同源限制的，也就是與 cookie（domain）處于不同源的網站，瀏覽器是不會讓該網站獲取到這個 cookie，那為什么csrf攻擊是可行的？

原因是瀏覽器使用 cookie 的情況

除了跨域 XHR 請求情況下，瀏覽器在發起請求的時候會把符合要求的 cookie 自動帶上，(域名，有效期，路徑，secure 屬性)，跨域 XHR 的請求的情況下，也可以攜帶 Cookie，同時瀏覽器允許跨域提交表單，也就是說，向同一個服務器發請求時會自動帶上瀏覽器保存的對于那個服務器的cookie，而不管你從哪個網站發請求，因為每次請求都會攜帶在http頭上，也是造成帶寬浪費的一個原因，但是讀取cookie是讀取不了的，攻擊者沒辦法知道cookie的內容

5.什么是Token（重點）

訪問資源介面（API）時所需要的資源憑證

簡單 token 的組成： uid(用戶唯一的身份標識)、time(當前時間的時間戳)、sign（簽名，token 的前幾位以哈希演算法壓縮成的一定長度的十六進制字串）

特點：
①服務端無狀態化（）、可擴展性好
②支持移動端設備
③安全
④支持跨程式呼叫

token 的身份驗證流程：

每一次請求都需要攜帶 token，需要把 token 放到 HTTP 的 Header 里

基于 token 的用戶認證是一種服務端無狀態的認證方式，服務端不用存放 token 資料，用決議 token 的計算時間換取 session 的存盤空間，從而減輕服務器的壓力，減少頻繁的查詢資料庫

token 完全由應用管理，所以它可以避開同源策略

僅僅用seesion＋cookie存在的問題

①session就會面對負載均衡問題
session是有狀態的，，當服務器采用分布式或集群時，session就會面對負載均衡問題，負載均衡多服務器的情況，不好確認當前用戶是否登錄，因為多服務器不共享session，這個問題也可以將session存在一個服務器中來解決，但是就不能完全達到負載均衡的效果，

解決思路：服務器無狀態化

客戶端登陸傳遞資訊給服務端，服務端收到后把用戶資訊加密（token）傳給客戶端，客戶端將token存放于localStroage等容器中，客戶端每次訪問都傳遞token，服務端解密token，就知道這個用戶是誰了，通過cpu加解密，服務端就不需要存盤session占用存盤空間，就很好的解決負載均衡多服務器的問題了，這個方法叫做JWT(Json Web Token)（和token這個概念區別一下）

②無法防止csrf攻擊

攻擊者在攻擊網站放一個src是被攻擊網站的轉賬表單，在session+cookie的情況下，用戶打開惡意網頁的時候就已經上當了了.因為form 發起的 POST 請求并不受到瀏覽器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域發送 POST 請求，形成 CSRF 攻擊，在post請求的瞬間，cookie會被瀏覽器自動添加到請求頭中，

解決思路：提交時要附加本域才能獲得資訊（token只有你正確輸入密碼之后才返還）

CSRF的一個特征是，攻擊者無法直接竊取到用戶的資訊（Cookie，Header，網站內容等），僅僅是冒用Cookie中的資訊，

而CSRF攻擊之所以能夠成功，是因為服務器誤把攻擊者發送的請求當成了用戶自己的請求，那么我們可以要求所有的用戶請求都攜帶一個CSRF攻擊者無法獲取到的Token，服務器通過校驗請求是否攜帶正確的Token，來把正常的請求和攻擊的請求區分開，也可以防范CSRF的攻擊，token是開發者為了防范csrf而特別設計的令牌，瀏覽器不會自動添加到headers里，攻擊者也無法訪問用戶的token，所以提交的表單無法通過服務器過濾，也就無法形成攻擊，

【疑問？】token放在客戶端哪里？客戶端是怎么每次取到token的

①輸出到客戶端頁面上，服務端將 token 渲染到 html 中，
也就是通過一個 dom 結點保存 token 資訊，客戶端就可以通過 dom 操作獲取到該 token 內容，（同源策略會限制腳本 API 操作）

如果是get請求的話可以直接附加在請求后面，每次頁面加載時，使用JS遍歷整個DOM樹，對于DOM中所有的a和form標簽后加入Token，這樣可以解決大部分的請求，但是對于在頁面加載之后動態生成的HTML代碼，這種方法就沒有作用，還需要程式員在編碼時手動添加Token，

如果是post請求還可以加一個隱藏表單

 <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>

②如果你能保證攻擊者沒辦法得到cookie的內容，放在里面也沒關系，
客戶端從 cookie 中獲取（同源策略限制 cookie 操作），就是怕XSS攻擊，

③放在localstorage里面，跨域無法操作
也是受同源策略影響，和cookie不同，僅僅在客戶端中保存，不會進行服務器通信，

6.JSON Web Token（JWT）

是目前最流行的跨域認證解決方案，是一種認證授權機制，上面也提到了，針對負載均衡的解決方案

教程（阮一峰）：http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html

Token和JWT：

相同：
● 都是訪問資源的令牌
● 都可以記錄用戶的資訊
● 都是使服務端無狀態化
● 都是只有驗證成功后，客戶端才能訪問服務端上受保護的資源

區別：
● Token：服務端驗證客戶端發送過來的 Token 時，還需要查詢資料庫獲取用戶資訊，然后驗證 Token 是否有效，
● JWT：將 Token 和 Payload 加密后存盤于客戶端，服務端只需要使用密鑰解密進行校驗（校驗也是 JWT 自己實作的）即可，不需要查詢或者減少查詢資料庫，因為 JWT 自包含了用戶資訊和加密的資料，