前言：

夏洛：大爺，樓上322住的是馬冬梅家吧？
大爺：馬都什么？
夏洛：馬冬梅。
大爺：什么都沒?。?br> 夏洛：馬冬梅啊。
大爺：馬什么沒？
夏洛：行，大爺你先涼快著吧。

基于 http 協(xié)議的 web 應用程序是請求——應答模式是無狀態(tài)的，我們可以這樣理解：每次的請求都是獨立的，它的執(zhí)行情況和結(jié)果與前面的請求和之后的請求是無直接關(guān)系的，它不會受前面的請求應答情況直接影響，也不會直接影響后面的請求應答情況。
為了讓Web服務器有記憶，有狀態(tài)，有以下幾種方法。

Cookie

1. 瀏覽器第一次訪問服務端時，服務器此時肯定不知道他的身份，所以創(chuàng)建一個獨特的身份標識數(shù)據(jù)，格式為key=value，放入到Set-Cookie字段里，隨著響應報文發(fā)給瀏覽器。
2. 瀏覽器看到有Set-Cookie字段以后就知道這是服務器給的身份標識，于是就保存起來，下次請求時會自動將此key=value值放入到Cookie字段中發(fā)給服務端。
3. 服務端收到請求報文后，發(fā)現(xiàn)Cookie字段中有值，就能根據(jù)此值識別用戶的身份然后提供個性化的服務。

image.png

Cookie就是服務器委托瀏覽器存儲在客戶端里的一些數(shù)據(jù)，而這些數(shù)據(jù)通常都會記錄用戶的關(guān)鍵識別信息。所以Cookie需要用一些其他的手段用來保護，防止外泄或者竊取，這些手段就是Cookie的屬性。

Path

設(shè)置為cookie.setPath("/testCookies")，接下來我們訪問http://localhost:8005/testCookies，我們可以看到在左邊和我們指定的路徑是一樣的，所以Cookie才在請求頭中出現(xiàn)，接下來我們訪問http://localhost:8005，我們發(fā)現(xiàn)沒有Cookie字段了，這就是Path控制的路徑。

Domain

設(shè)置為cookie.setDomain("localhost")，接下來我們訪問http://localhost:8005/testCookies我們發(fā)現(xiàn)下圖中左邊的是有Cookie的字段的，但是我們訪問http://172.16.42.81:8005/testCookies，看下圖的右邊可以看到?jīng)]有Cookie的字段了。這就是Domain控制的域名發(fā)送Cookie。

Session

Cookie是存儲在客戶端方，Session是存儲在服務端方，客戶端只存儲SessionId

image.png

@RequestMapping("/testSession")
@ResponseBody
public String testSession(HttpSession session){
    session.setAttribute("testSession","this is my session");
    return "testSession";
}


@RequestMapping("/testGetSession")
@ResponseBody
public String testGetSession(HttpSession session){
    Object testSession = session.getAttribute("testSession");
    return String.valueOf(testSession);
}

我們在請求參數(shù)中加上HttpSession session，然后再瀏覽器中輸入http://localhost:8005/testSession進行訪問可以看到在服務器的返回頭中在Cookie中生成了一個SessionId。然后瀏覽器記住此SessionId下次訪問時可以帶著此Id，然后就能根據(jù)此Id找到存儲在服務端的信息了。

image.png

過期時間：

客戶端：和Cookie過期一致，如果沒設(shè)置，默認是關(guān)了瀏覽器就沒了，即再打開瀏覽器的時候初次請求頭中是沒有SessionId了。
服務端：服務端的過期是真的過期，即服務器端的Session存儲的數(shù)據(jù)結(jié)構(gòu)多久不可用了，默認是30分鐘。

Session是存儲在Tomcat(以此為例)的容器中，所以如果后端機器是多臺的話，因此多個機器間是無法共享Session的，此時可以使用Spring提供的分布式Session的解決方案，是將Session放在了Redis中。

Token

Session是將要驗證的信息存儲在服務端，并以SessionId和數(shù)據(jù)進行對應，SessionId由客戶端存儲，在請求時將SessionId也帶過去，因此實現(xiàn)了狀態(tài)的對應。而Token是在服務端將用戶信息經(jīng)過Base64Url編碼過后傳給在客戶端，每次用戶請求的時候都會帶上這一段信息，因此服務端拿到此信息進行解密后就知道此用戶是誰了，這個方法叫做JWT(Json Web Token)。

image.png

Token相比較于Session的優(yōu)點在于，當后端系統(tǒng)有多臺時，由于是客戶端訪問時直接帶著數(shù)據(jù)，因此無需做共享數(shù)據(jù)的操作。

Token的優(yōu)點

1. 簡潔：可以通過URL,POST參數(shù)或者是在HTTP頭參數(shù)發(fā)送，因為數(shù)據(jù)量小，傳輸速度也很快
2. 自包含：由于串包含了用戶所需要的信息，避免了多次查詢數(shù)據(jù)庫
3. 因為Token是以Json的形式保存在客戶端的，所以JWT是跨語言的
4. 不需要在服務端保存會話信息，特別適用于分布式微服務

CSRF攻擊

image.png

可以這么理解：有一個人發(fā)給你一個搞(mei)笑(nv)圖片鏈接，你打開這個鏈接之后，便立刻收到了短信：你的銀行里的錢已經(jīng)轉(zhuǎn)移到這個人的帳戶了。

1.登錄受信任網(wǎng)站A，并在本地生成Cookie。
2.在不登出A的情況下，訪問危險網(wǎng)站B。

CSRF 攻擊的對象

在討論如何抵御 CSRF 之前，先要明確 CSRF 攻擊的對象，也就是要保護的對象。從以上的例子可知，CSRF 攻擊是黑客借助受害者的 cookie 騙取服務器的信任，但是黑客并不能拿到 cookie，也看不到 cookie 的內(nèi)容。另外，對于服務器返回的結(jié)果，由于瀏覽器同源策略的限制，黑客也無法進行解析。因此，黑客無法從返回的結(jié)果中得到任何東西，他所能做的就是給服務器發(fā)送請求，以執(zhí)行請求中所描述的命令，在服務器端直接改變數(shù)據(jù)的值，而非竊取服務器中的數(shù)據(jù)。所以，我們要保護的對象是那些可以直接產(chǎn)生數(shù)據(jù)改變的服務，而對于讀取數(shù)據(jù)的服務，則不需要進行 CSRF 的保護。比如銀行系統(tǒng)中轉(zhuǎn)賬的請求會直接改變賬戶的金額，會遭到 CSRF 攻擊，需要保護。而查詢余額是對金額的讀取操作，不會改變數(shù)據(jù)，CSRF 攻擊無法解析服務器返回的結(jié)果，無需保護。

當前防御 CSRF 的幾種策略

1. 驗證 HTTP Referer 字段
   服務器驗證Referer 字段，如果不是受信網(wǎng)站則拒絕請求。

問題：使用驗證 Referer 值的方法，就是把安全性都依賴于第三方（即瀏覽器）來保障，從理論上來講，這樣并不安全。事實上，對于某些瀏覽器，比如 IE6 或 FF2，目前已經(jīng)有一些方法可以篡改 Referer 值。如果 bank.example 網(wǎng)站支持 IE6 瀏覽器，黑客完全可以把用戶瀏覽器的 Referer 值設(shè)為以 bank.example 域名開頭的地址，這樣就可以通過驗證，從而進行 CSRF 攻擊。并且用戶可以設(shè)置不使用Referer。非100%安全。

2. 用戶操作限制，比如驗證碼
   嚴重影響了用戶體驗，而且還有額外的開發(fā)成本

3. Token驗證的CSRF防御機制是公認最合適的方案

參考文檔

1. cookie session token
   https://segmentfault.com/a/1190000021185229
2. CSRF攻擊和跨域
   https://segmentfault.com/a/1190000021029334
   https://segmentfault.com/a/1190000005125790
   https://segmentfault.com/a/1190000006944760
   https://segmentfault.com/a/1190000003716037
   https://www.ibm.com/developerworks/cn/web/1102_niugang_csrf/
   3.web安全周刊
   https://segmentfault.com/a/1190000007564080