我們所有人都知道如果攻擊者發現我們的用戶憑據（電子郵件和密碼）會發生什麼：他們可以登錄我們的帳戶並造成嚴重破壞。 但是很多現代應用程序都在使用JSON Web令牌（JWT）來管理用戶會話 - 如果JWT被洩露會發生什麼？ 由於越來越多的應用程序正在使用基於令牌的身份驗證，因此這個問題與開發人員越來越相關，並且對於瞭解是否構建使用基於令牌的身份驗證的任何類型的應用程序至關重要。
為了幫助完整地解釋這些概念，我將向您介紹令牌是什麼，它們如何被使用以及當它們被盜時會發生什麼。 最後：如果你的令牌被盜，我會介紹你應該做什麼，以及如何在將來防止這種情況。
這篇文章的靈感來自StackOverflow這個問題。 我對這個問題的回答已成為我迄今為止對StackOverflow最受歡迎的回覆之一！
什麼是令牌？
Web開發上下文中的標記只不過是表示會話的任意值。 標記可以是“abc123”之類的字符串，也可以是隨機生成的ID，如“48ff796e-8c8a-46b9-9f25-f883c14734ea”。
令牌的目的是幫助服務器記住某人是誰。 以API服務為例：如果您有一個API密鑰，可以讓您通過服務器端應用程序與API服務進行通信，那麼API密鑰就是API服務用來“記住”您的身份的密鑰，請查看您的帳戶詳細信息 ，並允許（或禁止）您提出請求。 在此示例中，您的API密鑰是您的“令牌”，它允許您訪問API。
然而，當大多數人今天談論令牌時，他們實際上是指JWT（無論好壞）。
什麼是JSON Web令牌（JWT）？
JSON Web令牌是特殊類型的令牌，其結構使得它們便於在Web上使用。 他們有一些定義特徵：
- 它們表示為普通字符串。 這是一個真正的JWT：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IlJhbmRhbGwgRGVnZ2VzIiwiaWF0IjoxNTE2MjM5MDIyfQ.sNMELyC8ohN8WF_WRnRtdHMItOVizcscPiWsQJX9hmw
因為JWT只是URL安全字符串，所以它們很容易通過URL參數等傳遞。
- 它們包含JSON編碼的數據。這意味著您可以根據需要為JWT存儲儘可能多的JSON數據，並且可以將令牌字符串解碼為JSON對象。這使它們便於嵌入信息。
- 它們是加密簽名的。瞭解它的工作原理本身就是一個主題。現在，只要知道這意味著擁有JWT的任何可信方都可以判斷令牌是否已被修改或更改。這意味著，如果您的應用程序或API服務生成一個令牌，表明某人是“免費”用戶，而某人稍後會更改令牌以表明他們是“管理員”用戶，您將能夠檢測到並採取相應行動。此屬性使JWT對於在難以獲得信任的Web上的各方之間共享信息非常有用。
這是一個小代碼片段，它使用njwt庫在JavaScript中創建和驗證JWT。這個例子純粹是為了讓您一眼就能看到如何創建JWT，在其中嵌入一些JSON數據並驗證它。
const njwt = require("njwt");
const secureRandom = require("secure-random");
// This is a "secret key" that the creator of the JWT must keep private.
var key = secureRandom(256, { type: "Buffer" });
// This is the JSON data embedded in the token.
var claims = {
iss: "https://api.com",
sub: "someuserid",
scope: "freeUser",
favoriteColor: "black"
};
// Create a JWT
var jwt = njwt.create(claims, key);
// Log the JWT
console.log(jwt);
// Jwt {
// header: JwtHeader { typ: 'JWT', alg: 'HS256' },
// body:
// JwtBody {
// iss: 'https://api.com',
// sub: 'someuserid',
// scope: 'freeUser',
// favoriteColor: 'black',
// jti: '903c5447-ebfd-43e8-8f4d-b7cc5922f5ec',
// iat: 1528824349,
// exp: 1528827949 },
// signingKey: <buffer> }/<buffer>
// The JWT in compacted form (ready for sending over the network)
var token = jwt.compact();
// Log the compacted JWT
console.log(jwt.compact());
// eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczovL2FwaS5jb20iLCJzdWIiOiJzb21ldXNlcmlkIiwic2NvcGUiOiJmcmVlVXNlciIsImZhdm9yaXRlQ29sb3IiOiJibGFjayIsImp0aSI6IjkwM2M1NDQ3LWViZmQtNDNlOC04ZjRkLWI3Y2M1OTIyZjVlYyIsImlhdCI6MTUyODgyNDM0OSwiZXhwIjoxNTI4ODI3OTQ5fQ.y7ad-nUsHAkI8a5bixYnr_v0vStRqnzsT4bbWGAM2vw
// Verify the JWT using the secret key
njwt.verify(token, key, (err, verifiedJwt) => {
if (err) throw err;
console.log("The JWT has been verified and can be trusted!");
// The JWT has been verified and can be trusted!
});
如何使用JSON Web令牌？
JWT通常用作Web應用程序，移動應用程序和API服務的會話標識符。但是，與傳統會話標識符不同，傳統會話標識符只是指向服務器端實際用戶數據的指針，JWT通常直接包含用戶數據。
JWT近年來變得流行的主要原因（自2014年以來僅存在）是它們可以包含任意JSON數據。 JWT相對於傳統會話ID的好處是：
- JWT是無狀態的，可以直接包含用戶數據
- 因為JWT是無狀態的，所以不需要實現服務器端會話（沒有會話數據庫，會話緩存等）
因為JWT是無狀態的，所以當服務器端應用程序收到JWT時，它可以僅使用用於創建它的“密鑰”來驗證它 - 從而避免與後端數據庫或緩存通信的性能損失，增加每個請求的延遲。
話雖如此，讓我們來看看JWT通常如何在現代Web應用程序中使用。
- 客戶端（通常是瀏覽器或移動客戶端）將訪問某種登錄頁面
- 客戶端將其憑據發送到服務器端應用程序
- 服務器端應用程序將驗證用戶的憑據（通常是電子郵件地址和密碼），然後生成包含用戶信息的JWT。嵌入在JWT中的信息通常是：
- 用戶的名字和姓氏
- 用戶的電子郵件地址或用戶名
- 用戶的ID（如有必要，用於服務器端查找）
- 用戶的權限（他們允許做什麼？）
- 與正在使用的應用程序相關的任何其他數據
- 服務器端應用程序將此令牌返回給客戶端
- 然後，客戶端將存儲此令牌，以便將來可以用它來標識自己。對於Web應用程序，這可能意味著客戶端將令牌存儲在HTML5本地存儲中。對於服務器端API客戶端，這可能意味著將令牌存儲在磁盤或秘密存儲中。
- 當客戶端將來向服務器發出請求時，它會將JWT嵌入到HTTP Authorization標頭中以標識自己
- 當服務器端應用程序收到新的傳入請求時，它將檢查是否存在HTTP Authorization標頭，如果存在，它將解析標記並使用“密鑰”驗證它
- 最後，如果令牌有效並且循環將完成，則服務器端應用程序將處理請求
簡而言之：JWT用於識別客戶端。就客戶而言，它們是王國的關鍵。
如果您的JSON Web令牌被盜，會發生什麼？
簡而言之：它很糟糕，真的很糟糕。
由於JWT用於識別客戶端，如果其中一個被盜或受到攻擊，攻擊者可以完全訪問用戶的帳戶，就像攻擊者破壞用戶的用戶名和密碼一樣。
例如，如果攻擊者獲得了您的JWT，他們可以開始向服務器發送請求，將自己標識為您，並執行諸如進行服務更改，用戶帳戶更新等操作。一旦攻擊者擁有您的JWT，就會結束遊戲。
但是，有一件事使得被盜的JWT比被盜的用戶名和密碼稍微不那麼糟糕：時機。由於JWT可以配置為在設定的時間（一分鐘，一小時，一天等）後自動過期，因此攻擊者只能使用您的JWT訪問該服務，直到它過期。
從理論上講，這聽起來很棒，對嗎？據稱令牌認證的一種方式是使認證更加“安全”，這是通過短期令牌實現的。這是近年來基於令牌的身份驗證真正起步的核心原因之一：您可以自動使令牌過期並降低依賴永久緩存的“無狀態”令牌的風險。
畢竟，在安全領域，依靠緩存數據做出敏感決策，例如誰可以登錄服務以及他們可以做什麼被認為是一件壞事。因為令牌是無狀態的並且允許比傳統會話認證有一些速度改進，所以它們保持某種程度上“安全”的唯一方式是限制它們的壽命，以便它們在受到危害時不會造成太大的傷害。
這裡唯一的問題是，如果攻擊者首先能夠竊取您的令牌，那麼一旦獲得新令牌，他們很可能會這樣做。這種情況最常見的方式是通過中間人（MITM）連接或直接訪問客戶端或服務器。不幸的是，在這些情況下，即使是最短壽命的JWT也根本無法幫助你。
通常，令牌應被視為密碼並受到保護。它們永遠不應公開共享，並應保存在安全的數據存儲中。對於基於瀏覽器的應用程序，這意味著永遠不會將您的令牌存儲在HTML5本地存儲中，而是將令牌存儲在JavaScript無法訪問的服務器端cookie中。
通常，基於令牌的身份驗證不會提供依賴於不透明會話標識符的典型基於會話的身份驗證的任何額外安全性。雖然基於令牌的身份驗證肯定有很多用例，但瞭解技術的工作原理以及弱點的位置至關重要。
另一個有趣的事情是，在某些情況下，被盜的JWT實際上可能比被盜的用戶名和密碼更糟糕。
讓我們暫時假裝您的用戶名和密碼已被盜用。在這種情況下，如果您登錄的應用程序受多因素身份驗證保護，則攻擊者需要繞過其他身份驗證機制才能訪問您的帳戶。
雖然猜測或暴力破解用戶名和密碼是一個非常現實的場景，但是能夠危及用戶的多因素身份驗證設置可能非常困難。繞過基於應用程序的授權，短信驗證，面部識別碼，觸摸ID等因素比猜測用戶密碼更具挑戰性。
因此，受損的JWT實際上可能比受損的用戶名和密碼具有更大的安全風險。想象一下上面的場景，用戶登錄的應用程序受多因素身份驗證的保護。一旦用戶通過多因素登錄並驗證自己，就會為他們分配一個JWT來證明他們是誰。如果JWT被盜，攻擊者不再需要直接繞過MFA（就像他們只有用戶的用戶名和密碼一樣） - 他們現在可以直接向用戶發出請求而無需額外的身份證明。相當大的風險。
如果您的JWT被盜，該怎麼辦？
一旦JWT被盜，您將陷入困境：攻擊者現在可以冒充客戶並在未經客戶同意的情況下訪問您的服務。但是，即使你處境糟糕，你仍然需要充分利用它。
如果客戶的令牌被盜，可以採取以下步驟。這些建議不適用於所有類型的應用，但應為您提供一些好主意，以幫助您從此安全事件中恢復：
- 立即撤銷受損的令牌。如果您在服務器上使用撤銷列表來使令牌無效，則撤消令牌可立即將攻擊者從系統中啟動，直到他們獲得新令牌為止。雖然這是一個臨時解決方案，但它會讓攻擊者的生活變得更加困難。
- 強制您的客戶立即更改密碼。在Web或移動應用程序的上下文中，強制您的用戶立即重置其密碼，最好通過某種多因素身份驗證流程，如Okta提供的那樣。如果攻擊者試圖使用受感染的令牌修改用戶登錄憑據，則強制用戶更改其密碼可能會使攻擊者遠離其帳戶。通過要求多因素身份驗證，您可以更自信地重置其憑據的用戶是他們所聲稱的人而不是攻擊者。
- 檢查客戶的環境。用戶的手機是否被盜，以便攻擊者可以訪問預先認證的移動應用程序？客戶端是否從受感染的設備（如移動電話或受感染的計算機）訪問您的服務？發現攻擊者如何獲得令牌是完全理解錯誤的唯一方法。
- 檢查您的服務器端環境。攻擊者是否能夠從您的角色中妥協令牌？如果是這樣，這可能需要更多的工作來修復，但越早開始就越好。
一旦完成了這些步驟，您應該更好地瞭解令牌是如何被洩露的，以及需要採取哪些措施來防止令牌在未來發生。
如何檢測令牌妥協
當令牌妥協確實發生時，它可能會導致重大問題。特別是如果您（作為服務提供商）無法快速檢測到攻擊者已經破壞了客戶端的令牌。
如果您能夠自動識別令牌被洩露的情況怎麼辦？這將極大地提高您服務的安全性，因為您可以主動防止可疑請求得到滿足，從而保護您的服務和用戶。
雖然不容易，但這絕對是可能的。像TensorFlow這樣的現代機器學習工具包允許您構建功能（雖然複雜）的管道，以檢測異常模式並主動負責這種情況。
例如，您可以使用機器學習來檢測不尋常的客戶端位置。假設您運行一個網站，並且您的用戶已從舊金山登錄並且已經提出了幾個小時的請求。如果您發現請求在短時間內開始來自不同的地理區域，您可以立即阻止這些請求被執行，撤消令牌，並聯系用戶以重置其密碼等。
以類似的方式，您可以使用機器學習來檢測異常的客戶端行為。如果令牌遭到入侵，攻擊者很可能會採取措施以某種方式濫用您的服務。如果您的用戶通常在您的網站上每分鐘發出五個請求，但突然之間您會注意到用戶每分鐘發出50多個請求的大幅提升，這可能是攻擊者獲得保留的良好指標用戶的令牌，因此您可以撤消令牌並聯系用戶以重置其密碼。
通過機器學習進行模式檢測和識別是處理這些更復雜問題的一種奇妙的現代方法。
這正是我們在Okta所做的 - 我們運行一個API服務，允許您在我們的服務中存儲用戶帳戶，我們提供開發人員庫來處理身份驗證，授權，社交登錄，單點登錄，多因素等事務當用戶登錄由Okta提供支持的應用程序時，我們會分析一些數據點以檢測帳戶是否已被盜用，提示進行多因素身份驗證，執行用戶外展等。
積極主動地保護您的安全性有很多複雜性，但準備比準備好要好得多。
閱讀更多 智能時刻 的文章
關鍵字: 發生 JavaScript 什麼
