在瀏覽器中存儲token的最佳實踐

Web 應用程序不是靜態站點，而是靜態和動態內容的精心組合。更常見的是，Web 應用程序邏輯在瀏覽器中運行。該應用程序不是從服務器獲取所有內容，而是在瀏覽器中運行 JavaScript，從后端 API 獲取數據并相應地更新 Web 應用程序演示。

為了保護對數據的訪問，我們應采用 OAuth 2.0。使用 OAuth 2.0，JavaScript 應用程序需要向 API 的每個請求添加訪問 token 。
出于可用性原因，JavaScript 應用程序通常不會按需請求訪問 token ，而是存儲它。問題是，如何在 JavaScript 中獲取這樣的 token ？當我們獲得 token 時，應用程序應該將 token 存儲在哪里，以便在需要時將其添加到請求中？

本文將討論瀏覽器中可用的不同存儲解決方案，并重點介紹與每個選項相關的安全風險。

獲取訪問 token

在應用程序可以存儲訪問 token 之前，它需要獲取一個。當前的最佳實踐推薦一種獲取訪問 token 的方法：代碼流。代碼流程分為兩步，首先從用戶那里收集授權——授權代碼。然后，應用程序在反向通道請求中用授權代碼交換訪問 token 。此請求稱為 token 請求，如以下示例所示：

const accessToken = await fetch(OAuthServerTokenEndpoint, {
method: "POST",
// 獲取token
body: new URLSearchParams({client_id: "example-client",
grant_type: "authorization_code",
code: authorization_code,code_verifier: pkce_code_verifier
})
})
.then (response => response.json())
.then (tokenResponse => {// 從響應中獲取tokenif (tokenResponse.accessToken) {return tokenResponse.accessToken;}
})

請注意，任何人都可以檢查瀏覽器加載的資源，包括任何JavaScript 代碼。因此，任何用 JavaScript 實現的 OAuth 客戶端都被視為公共客戶端——無法保守秘密，因此無法在 token 請求期間進行身份驗證。

瀏覽器威脅

跨站請求偽造 (CSRF)

在跨站點請求偽造 (CSRF)攻擊中，惡意行為者會誘騙用戶無意中通過瀏覽器執行惡意請求。例如，攻擊者可能會在網站中嵌入精心設計的圖像 src 字符串，從而觸發瀏覽器運行 GET 請求，或者在惡意網站上添加表單來觸發 POST 請求。在任何情況下，瀏覽器都可能會自動向此類請求添加 cookie，包括單點登錄 (SSO) cookie。

CSRF 攻擊通常利用用戶經過身份驗證的會話來執行惡意請求。因此，攻擊者可以代表用戶靜默執行請求并調用用戶可以調用的任何接口。不過，攻擊者無法讀取響應，因此他們通常會提出一次性狀態更改請求，例如更新用戶密碼。

跨站腳本 (XSS)

跨站點腳本 (XSS)漏洞允許攻擊者將惡意客戶端代碼注入到其他受信任的網站中。例如，漏洞可能發生在 Web 應用程序中用戶輸入生成未正確清理的輸出的任何位置。瀏覽器會自動在受信任網站的上下文中運行惡意代碼。

XSS 攻擊可用于竊取訪問和刷新 token 或執行 CSRF 攻擊。不過，XSS 攻擊有一個時間窗口，因為它們只能在有限的時間內運行，例如在 token 的生命周期內或只要存在漏洞的選項卡處于打開狀態。

即使在 XSS 無法用于檢索訪問 token 的情況下，攻擊者也可能利用 XSS 漏洞，使用 CSRF 將經過身份驗證的請求發送到安全的 Web 端點。然后，攻擊者可以冒充用戶，調用用戶可以調用的任何后端接口，并造成嚴重損害。

瀏覽器中的存儲解決方案

當應用程序收到 token 時，它需要存儲該 token 以便在 API 請求中使用它。有多種方法可以在用戶的??瀏覽器中保存數據。應用程序可以使用專用 API（例如 Web Storage API 或 IndexedDB）來存儲 token 。應用程序還可以簡單地將 token 保留在內存中或將它們放入 cookie 中。有些存儲機制是持久性的，而另一些存儲機制在一段時間后或在頁面關閉或刷新時會被擦除。

本地存儲

使用 JavaScript 中的全局對象通過 Web Storage API 訪問本地存儲localStorage。存儲在本地存儲中的數據可跨瀏覽器選項卡和會話使用，這意味著它不會過期，也不會在瀏覽器關閉時被刪除。因此，通過 localStorage 存儲的數據可以在應用程序的所有選項卡中訪問。

// 保存數據
localStorage.setItem("token", accessToken);
// 加載數據
let accessToken = localStorage.getItem("token");

每當應用程序調用 API 時，它都會從存儲中獲取 token 并將其手動添加到請求中。然而，由于本地存儲可通過 JavaScript 獲得，這意味著該解決方案也容易受到跨站點腳本攻擊 (XSS)。

如果我們使用 localStorage 來持久保存訪問 token ，并且攻擊者設法在我們的應用程序中運行外部 JavaScript 代碼，則攻擊者可以竊取任何 token 并直接調用 API。此外，XSS還允許攻擊者操縱應用程序本地存儲中的數據，這意味著攻擊者可以更改 token 。

請注意，本地存儲中的數據是永久存儲的，這意味著存儲在其中的任何 token 都駐留在用戶設備（筆記本電腦、計算機、移動設備或其他設備）的文件系統上，即使在瀏覽器關閉后也可以被其他應用程序訪問。因此，在使用 localStorage 時，請考慮安全性。考慮并防范瀏覽器外部的攻擊媒介，例如惡意軟件、被盜設備或磁盤。

根據上述討論，請遵循以下建議：

不要在本地存儲中存儲 token 等敏感數據。
不要信任本地存儲中的數據（尤其是用于身份驗證和授權的數據）。

會話存儲

會話存儲是Web Storage API 提供的另一種存儲機制。與本地存儲不同，當選項卡或瀏覽器關閉時，使用sessionStorage對象存儲的任何數據都會被擦除。此外，存儲在會話存儲中的數據無法在其他選項卡中訪問。只有當前選項卡和源中的 JavaScript 代碼可以使用相同的會話存儲進行讀寫。

// 存儲token
sessionStorage.setItem("token", accessToken);
// 獲取token
let accessToken = sessionStorage.getItem("token");

會話存儲可以被認為比本地存儲更安全，因為瀏覽器會在窗口關閉時自動刪除任何 token ，因此不會留下任何 token 。此外，由于會話存儲不在選項卡之間共享，攻擊者無法從另一個選項卡（或窗口）讀取 token ，這減少了 XSS 攻擊的影響。

實際上，使用 sessionStorage 存儲 token 時的主要安全問題是 XSS。如果我們的應用程序容易受到 XSS 攻擊，攻擊者可以從存儲中竊取 token 并在 API 調用中重放它。因此，會話存儲不適合存儲 token 等敏感數據。

indexedDB

IndexedDB 是一個用于在瀏覽器中異步存儲大量數據的 API。但是，在存儲 token 時，通常不需要瀏覽器 API 提供的功能。由于應用程序會在每次 API 調用時發送 token ，因此最好將其大小保持在最低限度。

與迄今為止討論的其他客戶端存儲機制一樣，對使用索引數據庫 API 存儲的數據的訪問受到同源策略的限制。只有同源的資源和服務工作者才能訪問數據。從安全角度來看，IndexedDB 與本地存儲相當：

token 可能會通過文件系統泄漏。
token 可能會通過 XSS 攻擊泄漏。

因此，請勿在 IndexedDB 中存儲訪問 token 或其他敏感數據。IndexedDB更適合應用程序離線工作所需的數據，例如圖像。

存儲在內存中

存儲 token 的一種非常安全的方法是將其保存在內存中。與其他方法相比， token 不存儲在文件系統中，從而降低了設備文件系統的風險。

最佳實踐建議將 token 存儲在內存中時將其保留在閉包中。例如，我們可以定義一個單獨的方法來使用 token 調用 API。它不會向主應用程序（主線程）透露 token 。下面是如何使用 JavaScript 處理內存中的 token 的示例。

function protectedCalls(tokenResponse) {const accessToken = tokenResponse.accessToken;return {// 使用內存中的token發送請求getOrders: () => {const req = new Request("https://server.example/orders");req.headers.set("Authorization", accessToken);return fetch(req)}}
}
const apiClient = protectedCalls(tokenResponse);
apiClient.getOrders();

請注意，攻擊者在獲取 token 后可能無法直接訪問 token ，因此可能無法直接使用 token 調用 API。即便如此，他們也可以隨時通過apiClient保存 token 引用的 API 調用 API。然而，任何此類攻擊都僅限于選項卡打開的時間段以及界面提供的功能。

除了與潛在 XSS 漏洞相關的安全問題之外，將 token 保留在內存中對于用戶體驗也有很大的缺點，因為 token 會在頁面重新加載時丟失。然后，應用程序必須獲取新的 token ，這可能會觸發新的用戶身份驗證。安全的設計應該考慮用戶體驗。

當使用 JavaScript 閉包或服務工作人員處理 token 和 API 請求時，XSS 攻擊可能會針對 OAuth 流（例如回調或靜默流）來獲取 token 。他們可能會取消注冊并繞過任何服務，或者使用原型污染通過覆蓋諸如window.fetch. 因此，考慮 JavaScript 閉包是為了方便，而不是安全。

cookie

Cookie 是存儲在瀏覽器中的數據片段。根據設計，瀏覽器會向服務器的每個請求添加 cookie。因此，應用程序必須謹慎使用 cookie。如果配置不仔細，瀏覽器可能會在跨站點請求中附加 cookie，并允許跨站點請求偽造 (CSRF) 攻擊。

Cookie 具有控制其安全屬性的屬性。例如，SameSite 屬性可以幫助降低 CSRF 攻擊的風險。當 Cookie 的 SameSite 屬性設置為時Strict，瀏覽器會將其添加到源自 Cookie 來源站點且目標站點相同的請求中。當請求嵌入任何第三方網站（例如通過鏈接）時，瀏覽器不會添加 cookie。

我們可以通過 JavaScript 設置和檢索 cookie。然而，當使用 JavaScript 讀取 cookie 時，應用程序容易受到 XSS（除了 CSRF 之外）的攻擊。因此，首選方案是使用一個后端組件來設置 cookie 并將其標記為HttpOnly. 該標志可以減少 XSS 攻擊造成的數據泄露，因為它向瀏覽器表明 cookie 不能通過 JavaScript 獲得。

為了防止 cookie 通過中間人攻擊泄漏（這可能會導致會話劫持），cookie 只能通過加密連接 (HTTPS) 發送。要指示瀏覽器僅在 HTTPS 請求中發送 cookie，cookie 必須設置安全屬性。

Set-Cookie:token=myvalue;SameSite=Strict;Secure;HttpOnly

與瀏覽器中的任何其他永久存儲解決方案一樣，即使瀏覽器關閉后，cookie 也可能駐留在文件系統上（例如，cookie 不必過期，或者瀏覽器可以保留會話 cookie 作為恢復會話功能的一部分）。為了降低從文件系統中竊取 token 的風險，請僅將加密 token 存儲在 cookie 中。因此，后端組件必須僅在 Set-Cookie 標頭中返回加密 token 。

帶有 Cookie 的 OAuth 語義

Cookie 仍然是傳輸 token 和充當 API 憑證的最佳選擇，因為即使攻擊者成功利用 XSS 漏洞，也無法從 Cookie 中檢索訪問 token 。然而，要實現這一點，必須正確配置 cookie。

首先，將 cookie 標記為HttpOnly無法通過 JavaScript 訪問，以解決 XSS 攻擊的風險。另一個重要屬性是secure ，可確保 cookie 僅通過 HTTPS 發送，以減輕中間人攻擊。

其次，頒發僅在幾分鐘內有效的短期訪問 token 。在最壞的情況下，具有最短生命周期的訪問 token 只能在可接受的短時間內被濫用。通常認為 15 分鐘的有效時間是合適的。讓 cookie 和 token 大約在同一時間過期。

第三，將 token 視為敏感數據。僅在 cookie 中存儲加密 token 。如果攻擊者設法獲得加密 token ，他們將無法從中解析任何數據。攻擊者也無法將加密的 token 重放給任何其他 API，因為其他 API 無法解密該 token 。加密 token 只是限制了被盜 token 的影響。

第四，限制發送 API 憑證的時間。僅將 cookie 發送到需要 API 憑據的資源。這意味著確保瀏覽器僅將 cookie 添加到實際需要訪問 token 的 API 調用中。為此，cookie 需要具有適當的設置，例如SameSite=Strict指向 API 端點的域和路徑的域屬性。

最后，當使用刷新 token 時，請確保將它們存儲在自己的 cookie 中。無需在每個 API 請求中都發送它們，因此請確保情況并非如此。僅當刷新過期的訪問 token 時才必須添加刷新 token 。這意味著持有刷新 token 的 cookie 與具有訪問 token 的 cookie 的設置略有不同。