什么是跨域請(qǐng)求
要明白什么叫跨域請(qǐng)求，首先得知道什么叫域。
域，是指由 協(xié)議+域名+端口號(hào)組成的一個(gè)虛擬概念。
如果兩個(gè)域的協(xié)議、域名、端口號(hào)都一樣，就稱他們?yōu)橥?，但是只要有其中一個(gè)不一樣，就不是同域。
那么 跨域請(qǐng)求又是什么意思呢？
簡單來說，就是在一個(gè)域內(nèi)請(qǐng)求了另一個(gè)域的資源，由于域不一致，會(huì)有安全隱患。
跨域請(qǐng)求的安全隱患
有一個(gè)詞，叫 CSRF （Cross-site request forgery）攻擊，中文名是 跨站請(qǐng)求偽造。
簡單來說呢，就是攻擊者盜用了你的身份，以你的名義發(fā)送惡意請(qǐng)求，它能做的壞事有很多，比如以你的名義發(fā)郵件，發(fā)消息，購物，盜取帳號(hào)等。
CSRF 的實(shí)際工作原理是怎樣的？
比如現(xiàn)在有兩個(gè)網(wǎng)站，A 網(wǎng)站是真實(shí)受信息的網(wǎng)站，而 B網(wǎng)站是危險(xiǎn)網(wǎng)站。
當(dāng)你登陸 A 網(wǎng)站后，瀏覽器會(huì)存儲(chǔ) A 網(wǎng)站服務(wù)器給你生成的 sessionid 存入 cookie，有了這個(gè) cookie ，就擁有了你的帳號(hào)權(quán)限，以后請(qǐng)求資料，就不用再次登陸啦。
對(duì)于真實(shí)用戶來說，是便利，可對(duì)于攻擊者來說，卻是可乘之機(jī)。
他們可以使用各種社工學(xué)引導(dǎo)你點(diǎn)擊他們的鏈接/網(wǎng)站，然后利用你的瀏覽器上存儲(chǔ)的 cookie ，然后在自己的 網(wǎng)站B 發(fā)起對(duì) 網(wǎng)站A 的請(qǐng)求，獲取一些隱私信息，做一些侵害用戶權(quán)益的事情。這便是一個(gè)完整的 CSRF 攻擊。
跨域請(qǐng)求的安全防御
完成一次完整的 CSRF 攻擊，只要兩個(gè)步驟：
登錄受信任網(wǎng)站A，并本地已經(jīng)存儲(chǔ)了 Cookie
在不登出A的情況下，訪問危險(xiǎn)網(wǎng)站B，網(wǎng)站 B 誘導(dǎo)你發(fā) A 發(fā)請(qǐng)求。
很多瀏覽器用戶對(duì)于網(wǎng)絡(luò)安全是無意識(shí)的，因此我們不能指望通過規(guī)范用戶行為來避免CSRF攻擊。
那如何從技術(shù)手段規(guī)避一定的 CSRF 攻擊的風(fēng)險(xiǎn)呢？
利用瀏覽器的同源策略：最基礎(chǔ)的安全策略
對(duì)請(qǐng)求的來源進(jìn)行驗(yàn)證：Referer Check
使用驗(yàn)證碼強(qiáng)制使用戶進(jìn)行交互確認(rèn)，保證請(qǐng)求是用戶發(fā)起
CSRF Token，注意不要使用 cookie 來存儲(chǔ)token
JSON Web Token
以上是我知道的歷史上用來抵御 CSRF 攻擊的方法
有的雖然實(shí)現(xiàn)簡單，但是不夠安全
有的雖然安全，但是用戶體驗(yàn)不好
有的雖然安全，用戶體驗(yàn)好，但是有缺點(diǎn)
具體應(yīng)該選哪一種呢，不妨繼續(xù)往下看。
3.1 同源策略
瀏覽器上有一個(gè)同源策略（SOP，全稱 Same origin policy），它會(huì)在一定程度上禁止這種跨域請(qǐng)求的發(fā)生。
但同源策略是最基本的安全策略，對(duì)于低級(jí)的 CSRF 攻擊 ，它是很有效果的。
可以說 Web 是構(gòu)建在同源策略基礎(chǔ)之上的，瀏覽器只是針對(duì)同源策略的一種實(shí)現(xiàn)。
同源策略在提升了 Web前端的安全性的同時(shí)，也犧牲了Web拓展上的靈活性。
設(shè)想若把html、js、css、flash，image等文件全部布置在一臺(tái)服務(wù)器上，小網(wǎng)站這樣湊活還行，大中網(wǎng)站如果這樣做服務(wù)器根本受不了的，因此同源策略，就像是雙刃劍。不過這些都是有解的。
3.2 Referer Check
在 HTTP 協(xié)議中，有一個(gè)字段叫做 Referer，它記錄了HTTP 請(qǐng)求的來源地址。
當(dāng)發(fā)生 CSRF 攻擊時(shí)，這個(gè)來源地址，會(huì)變成危險(xiǎn)網(wǎng)站 B，因此只要在服務(wù)端校驗(yàn)這個(gè) Referer 是不是和自己同一個(gè)域就可以判斷這個(gè)請(qǐng)求是跨站請(qǐng)求。
但這種方法，也是有局限性的，在一些非主流的瀏覽器，或者使用了那些非常古老的瀏覽器版本，這個(gè) Referer 字段，是有可能會(huì)被篡改的。
退一步講，假設(shè)你使用了最安全的最新版本的瀏覽器，這個(gè)值無法被篡改，依舊還是有安全隱患。
因?yàn)橛行┯脩舫鲇谀承╇[私考慮，會(huì)在瀏覽器設(shè)置關(guān)閉這個(gè) Referer 字段，也有的網(wǎng)站會(huì)使用一些技術(shù)手段使用請(qǐng)求不攜帶 Referer 字段。
因此，當(dāng)你要使用 Referer Check 來做為 防御 CSRF 攻擊的主要手段時(shí)，請(qǐng)確保你的用戶群體使用的一定是最安全的最新版本的瀏覽器，并且默認(rèn)用戶不會(huì)手動(dòng)關(guān)閉 Referer 。
3.3 加驗(yàn)證碼
驗(yàn)證碼，強(qiáng)制用戶必須與應(yīng)用進(jìn)行交互，才能完成最終請(qǐng)求。
其實(shí)加驗(yàn)證碼，是能很好遏制 CSRF 攻擊，但是網(wǎng)站總不能給所有的操作都加上驗(yàn)證碼吧，那樣的話，用戶估計(jì)都跑光光了，因此為了保證用戶體驗(yàn)，驗(yàn)證碼只能作為一種輔助手段，不能作為主要解決方案。
3.4 CSRF Token
CSRF 攻擊之所以能夠成功，是因?yàn)楹诳涂梢酝耆珎卧煊脩舻恼?qǐng)求，該請(qǐng)求中所有的用戶驗(yàn)證信息都是存在于 cookie 中，因此黑客可以在不知道這些驗(yàn)證信息的情況下，直接利用用戶自己的 cookie 來通過安全驗(yàn)證。
所以要抵御 CSRF，關(guān)鍵在于要在請(qǐng)求中放入黑客所不能偽造的信息，并且該信息不存在于 cookie 之中（不然黑客又能拿到了）。
業(yè)界普遍的防御方案是使用 CSRF Token
使用 CSRF Token 根據(jù)token驗(yàn)證方式的不同，也可以分為兩種：
第一種：如圖所示
當(dāng)用戶請(qǐng)求一個(gè)更新用戶名的頁面時(shí)，由服務(wù)端生成一個(gè)隨機(jī)數(shù) Token，然后放入HTML表單中傳給瀏覽器，并且存入 session 中。
當(dāng)用戶提交表單請(qǐng)求時(shí)，表單數(shù)據(jù)會(huì)帶上這個(gè) Token 發(fā)送給服務(wù)端 ；
服務(wù)端收到表單請(qǐng)求后，會(huì)從表單數(shù)據(jù)里取出 Token，然后和 session 里的 token 進(jìn)行對(duì)比，如果是一樣的，就是合法的用戶請(qǐng)求，將新的用戶名存入數(shù)據(jù)庫，如果不一樣，那就是非法的請(qǐng)求，應(yīng)當(dāng)拒絕。
第二種：
當(dāng)用戶請(qǐng)求一個(gè)更新用戶名的頁面時(shí)，由服務(wù)端生成一個(gè)隨機(jī)數(shù) Token，然后放入HTML表單中，并且會(huì)把這個(gè) Token 放在 cookie 里發(fā)給瀏覽器。
當(dāng)用戶提交表單請(qǐng)求時(shí)，表單數(shù)據(jù)會(huì)帶上這個(gè) Token 發(fā)送給服務(wù)端，并且?guī)蠑y帶 token 的 cookie ；
服務(wù)端收到表單請(qǐng)求后，會(huì)從表單數(shù)據(jù)里取出 Token，與 cookie 里的 token 進(jìn)行對(duì)比，如果是一樣的，就是合法的用戶請(qǐng)求，將新的用戶名存入數(shù)據(jù)庫，如果不一樣，那就是非法的請(qǐng)求，應(yīng)當(dāng)拒絕。
3.5 新增 header
使用上面的 CSRF Token 已經(jīng)可以避免 CSRF 攻擊，但是它卻有可能又引入了另一個(gè)問題。
若 CSRF Token 沒有使用 cookie，就必須要將 Token 存儲(chǔ)在服務(wù)端的 Session 中，這樣就會(huì)面臨幾個(gè)問題
服務(wù)端每生成一個(gè) Token，都會(huì)存放入 session 中，而隨著用戶請(qǐng)求的增多，服務(wù)端的開銷會(huì)明顯增大。
如果網(wǎng)站有多個(gè)子域，分別對(duì)應(yīng)不同的服務(wù)器，比如 后臺(tái)是服務(wù)器 a，z 后臺(tái)是 服務(wù)器b， 不同子域要想使用同一個(gè) Token，就要求所有的服務(wù)器要能共享這個(gè) Token。一般要有一個(gè)中心節(jié)點(diǎn)（且應(yīng)是一個(gè)集群）來存儲(chǔ)這個(gè)Token，這樣看下來，架構(gòu)就變得更加復(fù)雜了。
想要解決這些問題，可以使用我們接下來要講的 JWT（全稱：JSON Web Token）
使用了 JWT 后，有了哪些變化呢
服務(wù)器只負(fù)責(zé)生成 Token和校驗(yàn)Token，而不再存儲(chǔ)Token
將服務(wù)器的壓力分?jǐn)偨o了所有的客戶端。
服務(wù)端的 鑒權(quán)不使用 cookie ，而是由新增的 Header 字段：Authorization 里的 JWT 。
JWT 是本篇文章重要知識(shí)點(diǎn)之一，下面我會(huì)詳細(xì)說說關(guān)于 JWT 的內(nèi)容。
JWT 的工作原理及目的
為了讓你直觀感受 JWT 的工作原理，我畫了下面這張圖
用戶以 Web表單 的形式，將自己的用戶名和密碼 POST 到后端的接口。
后端核對(duì)用戶名和密碼成功后，會(huì)計(jì)算生成JWT Payload 字符串（具體計(jì)算方法，后續(xù)會(huì)講），然后返回 response 給瀏覽器。
瀏覽器收到 JWT 后，將其保存在 cookie 里或者 localStorage 或者 sessionStorage 里（具體如何選，后面會(huì)說）。
后續(xù)在該域上發(fā)出的請(qǐng)求，都會(huì)將 JWT放入HTTP Header 中的 Authorization 字段。
后端收到新請(qǐng)求后，會(huì)使用密鑰驗(yàn)證 JWT 簽名。
驗(yàn)證通過后后端使用 JWT 中包含的用戶信息進(jìn)行其他相關(guān)操作，返回相應(yīng)結(jié)果。
JWT 的誕生并不是解決 CSRF 跨域攻擊，而是解決跨域認(rèn)證的難題。
舉例來說，A 網(wǎng)站和 B 網(wǎng)站是同一家公司的關(guān)聯(lián)服務(wù)?，F(xiàn)在要求，用戶只要在其中一個(gè)網(wǎng)站登錄，再訪問另一個(gè)網(wǎng)站就會(huì)自動(dòng)登錄，這應(yīng)該如何實(shí)現(xiàn)呢？
一種解決方案是 session 數(shù)據(jù)持久化，寫入數(shù)據(jù)庫或別的持久層。各種服務(wù)收到請(qǐng)求后，都向持久層請(qǐng)求數(shù)據(jù)。這種方案的優(yōu)點(diǎn)是架構(gòu)清晰，缺點(diǎn)是工程量比較大。另外，持久層萬一掛了，就會(huì)單點(diǎn)失敗。
另一種方案是服務(wù)器索性不保存 session 數(shù)據(jù)了，所有數(shù)據(jù)都保存在客戶端，每次請(qǐng)求都發(fā)回服務(wù)器。
JWT 就是這種方案的一個(gè)優(yōu)秀代表。
JWT 如何生成？
JWT 其實(shí)就是一個(gè)字符串，比如下面這樣
eyJ
仔細(xì)觀察，會(huì)發(fā)現(xiàn)它里面有三個(gè) .，以.為分界，可以將 JWT 分為三部分。
第一部分：頭部（Header）
第二部分：載荷（Payload）
第三部分：簽名（Signature）
5.1 頭部（Header）
JWT 的頭部承載兩部分信息：
聲明類型：這里是 JWT
聲明加密的算法：通常直接使用 HMAC SHA256
完整的頭部就像下面這樣的JSON：
{
"typ": "JWT",
"alg": "HS256"
}
然后將頭部進(jìn)行 Base64URL 算法編碼轉(zhuǎn)換，構(gòu)成了第一部分
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
5.2 載荷（Payload）
載荷，同樣也是個(gè) JSON 對(duì)象，它是存放有效信息的地方，但不建議存放密碼等敏感信息。
JWT 規(guī)定了7個(gè)官方字段，供選用：
iss (issuer)：簽發(fā)人
exp (expiration time)：過期時(shí)間
sub (subject)：主題
aud (audience)：受眾
nbf (Not Before)：生效時(shí)間
iat (Issued At)：簽發(fā)時(shí)間
jti (JWT ID)：編號(hào)
除了官方字段，你還可以在這個(gè)部分定義私有字段，下面就是一個(gè)例子。
注意，JWT 默認(rèn)是不加密的，任何人都可以讀到，所以不要把秘密信息放在這個(gè)部分。
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
然后將其進(jìn)行 Base64URL 算法轉(zhuǎn)換，得到 JWT 的第二部分。
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
5.3 簽名（Signature）
Signature 部分是對(duì)前兩部分的簽名，防止數(shù)據(jù)篡改。
首先，需要指定一個(gè)密鑰（secret）。這個(gè)密鑰只有服務(wù)器才知道，不能泄露給用戶。然后，使用 Header 里面指定的簽名算法（默認(rèn)是 HMAC SHA256），按照下面的公式產(chǎn)生簽名。
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
算出簽名以后，把 Header、Payload、Signature 三個(gè)部分拼成一個(gè)字符串，每個(gè)部分之間用"點(diǎn)"（.）分隔，就可以返回給用戶。
如何手動(dòng)生成 JWT？
如果你想手動(dòng)生成一個(gè) JWT 用于測(cè)試，有兩種方法
第一種：使用 這個(gè)網(wǎng)站 。
我使用前面的 header 和 payload，然后使用 secret 密鑰：Python
最后生成的 JWT 結(jié)果如下
eyJ0eXAiOiJKV1QiLCJ
第二種：使用 Python 代碼生成
首先安裝一下 pyjwt 這個(gè)庫
$pip install pyjwt
然后就可以在代碼中使用它
import jwt
import datetime
import uuid
salt = 'minggezuishuai'
# 構(gòu)造header ， 這里不寫默認(rèn)的也是
headers = {
'typ': 'JWT',
'alg': 'HS256'
}
# 構(gòu)造payload
payload = {
'user_id': str), # 自定義用戶ID
'username': "wangbm", # 自定義用戶名
'exp': da + da(minutes=5) # 超時(shí)時(shí)間，取現(xiàn)在時(shí)間，五分鐘后token失效
}
token = jwt.encode(payload=payload, key=salt, algorithm="HS256", headers=headers).decode('utf-8')
# token: eyJ0eXAiOiJKV1QiLCJ
如果你只是測(cè)試使用，完全不用寫那么多代碼，用命令行即可
$ pyjwt --key="minggezuishuai" encode user_id=888f20d9-07ed-41bd-b329-17c6f058a14e username=wangbm exp=+120
eyJ0eXAiOiJKV1QiLCJ
Base64URL 算法
前面提到，Header 和 Payload 串型化的算法是 Base64URL。這個(gè)算法跟 Base64 算法基本類似，但有一些小的不同。
JWT 作為一個(gè)令牌（token），有些場(chǎng)合可能會(huì)放到 URL（比如 a）。Base64 有三個(gè)字符+、/和=，在 URL 里面有特殊含義，所以要被替換掉：=被省略、+替換成-，/替換成_ 。這就是 Base64URL 算法。
JWT 如何保存？
關(guān)于瀏覽器應(yīng)該將 JWT 保存在哪？這個(gè)問題，其實(shí)也困擾了我很久。
如果使用搜索引擎去查，我相信你也一定會(huì)被他們繞暈。
比如在這篇帖子（When and how to use it ）里，作者的觀點(diǎn)是，不應(yīng)該保存在 localstorage 和 session storage，因?yàn)檫@樣，第三方的腳本就能直接獲取到。
作者推薦的做法是，將 JWT 保存在 cookie 里，并設(shè)置 HttpOnly。
再比如這一篇帖子（JWT(JSON Web Token) : Implementation with Node）提到了要把 JWT 保存到 local-storage。
因此，我決定不再看網(wǎng)絡(luò)上關(guān)于 『應(yīng)將 JWT 保存的哪？』的文章。而是自己思考，以下是我個(gè)人觀點(diǎn)，不代表一定正確，僅供參考 。
JWT 的保存位置，可以分為如下四種
保存在 localStorage
保存在 sessionStorage
保存在 cookie
保存在 cookie 并設(shè)置 HttpOnly
第一種和第二種其實(shí)可以歸為一類，這一類有個(gè)特點(diǎn)，就是該域內(nèi)的 js 腳本都可以讀取，這種情況下 JWT 通過 js 腳本放入 Header 里的 Authorization 字段，會(huì)存在 XSS 攻擊風(fēng)險(xiǎn)。
第三種，與第四種相比，區(qū)別在于 cookie 有沒有標(biāo)記 HttpOnly，沒有標(biāo)記 HttpOnly 的 cookie ，客戶端可以將 JWT 通過 js 腳本放入 Header 里的 Authorization 字段。這么看好像同時(shí)存在CSRF 攻擊風(fēng)險(xiǎn)和 XSS 攻擊風(fēng)險(xiǎn)，實(shí)則不然，我們雖然將 JWT 存儲(chǔ)在 cookie 里，但是我們的服務(wù)端并沒有利用 cookie 里的 JWT 直接去鑒權(quán)，而是通過 header 里的 Authorization 去鑒權(quán)，因此這種方法只有 XSS 攻擊風(fēng)險(xiǎn)，而沒有 CSRF 攻擊風(fēng)險(xiǎn)。
而第四種，加了 HttpOnly 標(biāo)記，意味著這個(gè) cookie 無法通過js腳本進(jìn)行讀取和修改，杜絕了 XSS 攻擊的發(fā)生。與此同時(shí)，網(wǎng)站自身的 js 腳本也無法利用 cookie 設(shè)置 header 的Authorization 字段，因此只能通過 cookie 里的 JWT 去鑒權(quán)，所以不可避免還是存在 CSRF 攻擊風(fēng)險(xiǎn)。
如此看來，好像不管哪一種都有弊端，沒有一種完美的解決方案。
是的，事實(shí)也確實(shí)如此。
所以我的觀點(diǎn)是，開發(fā)人員應(yīng)當(dāng)根據(jù)實(shí)際情況來選擇 JWT 的存儲(chǔ)位置。
當(dāng)訪問量/業(yè)務(wù)量不是很大時(shí)，可以使用 CSRF Token 來防止 CSRF 攻擊
而如果訪問量/業(yè)務(wù)量對(duì)服務(wù)器造成很大壓力，或覺得服務(wù)器共享 token 對(duì)架構(gòu)要求太高了，那就拋棄CSRF Token 的方式，而改用 JWT。選擇了 JWT ，就面臨著要將 JWT 存儲(chǔ)在哪的問題。
若選擇了 JWT ，那么請(qǐng)不要使用 cookie HttpCookie 來存儲(chǔ)它，因?yàn)槭褂盟€是會(huì)有 CSRF 攻擊風(fēng)險(xiǎn)。
那另外三種如何選擇呢？這三種無論使用哪種，都不可避免有 XSS 攻擊風(fēng)險(xiǎn)。我的思路是，XSS 攻擊通過其他的手段來規(guī)避，這里使用JWT 只有 防御 CSRF 攻擊與服務(wù)器性能的優(yōu)化，這兩個(gè)目標(biāo)。
那我剩下的三種，我建議是使用 cookie 存儲(chǔ)，但不使用 cookie 來鑒權(quán)。服務(wù)器鑒權(quán)還是通過請(qǐng)求里的 Authorization 字段（通過js寫入 Header 的）。
當(dāng)然，如果你覺得你通過 Referer Check、加驗(yàn)證碼等其他手段，已經(jīng)可以保證不受 CSRF 攻擊的威脅，此時(shí)你使用 JWT ，就可以選擇使用 JWT + cookie HttpOnly，扼殺 XSS 攻擊的可能。
JWT 如何發(fā)送？
通過上面第七節(jié)的描述，其實(shí)我也講到了 JWT 根據(jù)不同場(chǎng)景可以選擇兩種發(fā)送方式
第一種：將 JWT 放在 Header 里的
Authorization字段，并使用Bearer標(biāo)注
'Authorization': 'Bearer ' + ${token}
第二種：把 JWT 放入 cookie ，發(fā)送給服務(wù)端，雖然發(fā)送。但是不使用它來鑒權(quán)。
JWT 如何校驗(yàn)？
后端收到請(qǐng)求后，從 Header 中取出 Authorization里的 JWT ，使用之前的簽名算法對(duì) header 和 payload 再次計(jì)算生成新的簽名，并與 JWT 里的簽名進(jìn)行對(duì)比，如果一樣，說明校驗(yàn)通過，是個(gè)合法的 Token。
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
驗(yàn)證是個(gè)合法的 Token 后，還要檢查這個(gè) Token 是否過期，在 JWT 里的 payload 中，有 Token 的過期時(shí)間，可以通過它來檢查 Token 是否可以用？
payload 里同時(shí)還有用戶的相關(guān)信息，有了這些信息后，后端就可以知道這是哪個(gè)用戶的請(qǐng)求了，到這里一切都驗(yàn)證通過，就可以執(zhí)行相關(guān)的業(yè)務(wù)邏輯了。
前面我使用了 pyjwt這個(gè)來生成 JWT ，事實(shí)上，這個(gè)庫也可以用來驗(yàn)證 token。
使用 jwt 的 decode 會(huì)先驗(yàn)簽再解碼取得 payload 的信息。
>>> import jwt
>>> token="eyJ0eXAiOiJKV1QiLCJ"
>>> jwt.decode(token, 'minggezuishuai', algorithms=['HS256'])
{'user_id': '888f20d9-07ed-41bd-b329-17c6f058a14e', 'username': 'wangbm', 'exp': 1594434326}
>>>
驗(yàn)簽同樣也可以使用命令行
$ pyjwt --key="minggezuishuai" decode eyJ0eXAiOiJKV1QiLCJ
{"user_id": "888f20d9-07ed-41bd-b329-17c6f058a14e", "username": "wangbm", "exp": 1594434859}
如果不想驗(yàn)證簽名及有效期，而只是想取下payload，只需加個(gè)--no-verify參數(shù)即可
$pyjwt --key="minggezuishuai" decode --no-verify {token}
更的詳細(xì)使用方法，可以執(zhí)行 pyjwt --help學(xué)習(xí)或者前往官方文檔：
JWT 的最佳搭配
在真正的業(yè)務(wù)中，是有可能使用 payload 來存放一些用戶的敏感信息的，由于 payload 是采用 Base64URL 轉(zhuǎn)換而成，它是可逆的，因此當(dāng)你在 payload 存放敏感信息時(shí)，需要保證 JWT 的安全性，不能讓其暴露在 『陽光』下。
為此，JWT 最好與 HTTPS 配合使用，利用 HTTPS 的非對(duì)稱加密來保證 JWT 的安全。
具體是如何保障的呢？
HTTPS 是基于 SSL/TLS 的非對(duì)稱加密算法工作的。
在非對(duì)稱加密算法的規(guī)則下，服務(wù)器會(huì)擁有一個(gè)叫做『私鑰』的東西，它是私有的，除了服務(wù)器之外，不能再有第二個(gè)人知道它。
而相對(duì)的，所有的客戶端（瀏覽器）同時(shí)也會(huì)有一個(gè)叫做『公鑰』的東西，它是對(duì)所有人公開的，任何人都可以擁有它。它與『私鑰』合稱為一個(gè)密鑰對(duì)。
公鑰和私鑰的規(guī)則是：
公鑰加密的東西，只有私鑰能解。因此如果 JWT 的 payload 里有你的敏感信息，那也不要緊，只要把 JWT 用公鑰（前提是這個(gè)公鑰得是正確的，下面會(huì)說到）加密一下，那黑客就算拿到了這個(gè)密文，也無法解密，因?yàn)樗借€只有服務(wù)器才有。
私鑰加密的東西，所有的公鑰也都能解。因此服務(wù)器發(fā)給客戶端的 JWT 的payload 盡量不要有敏感信息。
那么問題又來了，如果客戶端拿到的公鑰，是黑客偽造的，客戶端拿著這個(gè)假公鑰加密自己的敏感信息，然后發(fā)出去，黑客在拿到這個(gè)用自己偽造的公鑰加密的數(shù)據(jù)，非常開心，因?yàn)檫@個(gè)公鑰對(duì)應(yīng)的私鑰在自己手里，自己是可以解密得到里面的數(shù)據(jù)的。
因此如何保證服務(wù)器發(fā)給客戶端（瀏覽器）的公鑰是正確的呢？
答案是通過數(shù)字證書來保證。但是由于這個(gè)不是本文的重點(diǎn)，因此我將這塊內(nèi)容放在后面的文章詳細(xì)解釋。
寫在最后
最后，我總結(jié)一下，本文的要點(diǎn)：
CSRF 攻擊的產(chǎn)生，需要cookie 的『助攻』，否則無法完成。
CRSF 是利用 cookie，而不是盜取 cookie，這點(diǎn)一定要明白。
但也并不是使用了 cookie 就會(huì)有 CSRF 風(fēng)險(xiǎn)，而應(yīng)該說是用 cookie 去做鑒權(quán)才會(huì)有 CSRF 風(fēng)險(xiǎn)，參考 CSRF Token （把 token 存儲(chǔ)在 cookie 的情況）和 JWT （把 token 存儲(chǔ)在 cookie 的情況）。
CSRF Token 和 JWT 雖然都可以做到防御 CSRF 攻擊，但其實(shí)無論是哪個(gè)都無法同時(shí)做到防御 CSRF 和 XSS 攻擊，在阻止了 CSRF 攻擊后， 需要再通過其他手段來減少 XSS 攻擊的可能性。
JWT 就是一個(gè)由服務(wù)端按照一定的規(guī)則生成的字符串，
JWT 的目的是為了做一個(gè)無狀態(tài)的 session，避免去頻繁查詢 session，減少了對(duì)服務(wù)器產(chǎn)生的壓力，簡化后端架構(gòu)模型。它的主要用途是解決跨域認(rèn)證的問題，而解決 CSRF 跨域攻擊只是它的附帶功能。
payload 是經(jīng)過 base64URL 算法轉(zhuǎn)換而成的字符串，是可逆的，因此盡量不要存放敏感數(shù)據(jù)，如若非要存放敏感數(shù)據(jù)，最好與 HTTPS 協(xié)議搭配使用，避免數(shù)據(jù)泄露。
JWT 的保存位置與方式，沒有絕對(duì)的方案，具體如何選擇要視情況而定。
1.《azhibo com，干貨看這篇!手繪10張圖，把CSRF跨域攻擊、JWT跨域認(rèn)證說得明明白白的》援引自互聯(lián)網(wǎng)，旨在傳遞更多網(wǎng)絡(luò)信息知識(shí)，僅代表作者本人觀點(diǎn)，與本網(wǎng)站無關(guān)，侵刪請(qǐng)聯(lián)系頁腳下方聯(lián)系方式。
2.《azhibo com，干貨看這篇!手繪10張圖，把CSRF跨域攻擊、JWT跨域認(rèn)證說得明明白白的》僅供讀者參考，本網(wǎng)站未對(duì)該內(nèi)容進(jìn)行證實(shí)，對(duì)其原創(chuàng)性、真實(shí)性、完整性、及時(shí)性不作任何保證。
3.文章轉(zhuǎn)載時(shí)請(qǐng)保留本站內(nèi)容來源地址，http://f99ss.com/tiyu/2148651.html
