1. 從一次滲透測試中的“意外”發(fā)現(xiàn)說起最近在復(fù)盤一個內(nèi)部靶場環(huán)境時遇到了一個關(guān)于JWTJSON Web Token的典型場景讓我想起了之前“隴劍杯”網(wǎng)絡(luò)安全競賽中一道非常經(jīng)典的題目。那道題沒有復(fù)雜的漏洞鏈也沒有高深的免殺技巧核心就是考察對JWT這一現(xiàn)代Web應(yīng)用身份驗證“基石”的深入理解。很多剛接觸安全的朋友包括當(dāng)時的我都曾以為JWT就是一個加密過的、不可篡改的字符串拿到手只能干瞪眼。但事實恰恰相反JWT的設(shè)計哲學(xué)是“簽名”而非“加密”這為安全測試人員打開了一扇充滿可能性的窗戶。今天我就結(jié)合這道競賽題把JWT從原理到攻擊面掰開揉碎了講清楚讓你下次再遇到時能像老師傅一樣一眼看穿其中的門道。簡單來說JWT就是一個用于在各方之間安全傳輸信息的“令牌”。它由三部分組成頭部Header、載荷Payload和簽名Signature中間用點號.分隔形如xxxxx.yyyyy.zzzzz。它被廣泛用于單點登錄SSO、API鑒權(quán)和分布式會話管理。這道題的核心就是利用我們對JWT各部分處理邏輯的誤解或配置缺陷去偽造一個擁有更高權(quán)限的令牌。這不僅僅是CTF的技巧在真實的滲透測試和紅隊評估中對JWT的審計和測試是Web應(yīng)用安全中不可或缺的一環(huán)。2. JWT的結(jié)構(gòu)拆解遠(yuǎn)不止“三個點”那么簡單要攻擊一個東西首先得徹底理解它。JWT的三個部分每一部分都藏著玄機(jī)。2.1 頭部Header算法聲明與格式把戲頭部通常是一個JSON對象經(jīng)過Base64Url編碼后形成JWT的第一部分。它最關(guān)鍵的字段是alg用于聲明簽名所使用的算法。常見的值有HS256使用HMAC SHA-256的對稱加密算法。這意味著簽名和驗證使用同一個密鑰secret。這是最常用但也最需要保護(hù)密鑰的場景。RS256使用RSA SHA-256的非對稱加密算法。使用私鑰private key簽名使用公鑰public key驗證。公鑰可以安全分發(fā)更適合分布式場景。ES256使用ECDSA的橢圓曲線數(shù)字簽名算法同樣是非對稱的。none一個特殊值表示“無簽名”。在某些早期的JWT庫實現(xiàn)中如果服務(wù)器配置不當(dāng)允許alg為none的令牌通過驗證這將導(dǎo)致嚴(yán)重的安全漏洞。除了alg頭部還可能包含typ類型通常為JWT、kid密鑰ID用于在多個密鑰中指定一個等字段。這里第一個攻擊點就出現(xiàn)了算法混淆攻擊Algorithm Confusion Attack。如果服務(wù)器端代碼在驗證簽名時邏輯是“從令牌頭部讀取alg字段然后用該算法去驗證簽名”那么攻擊者就可以將alg改為none或者從RS256改為HS256從而繞過驗證。例如服務(wù)器本應(yīng)使用RS256非對稱公鑰是公開的。攻擊者將頭部改為{alg:HS256,typ:JWT}然后用服務(wù)器的公鑰作為HMAC的密鑰secret去偽造簽名。如果服務(wù)器驗證邏輯有缺陷它會用公鑰作為HMAC密鑰去驗證這個簽名從而誤判令牌有效。2.2 載荷Payload承載信息的“聲明集”載荷同樣是一個JSON對象包含所謂的“聲明”Claims。聲明分為三種注冊聲明Registered Claims預(yù)定義的一些有特定含義的聲明非強(qiáng)制但建議使用。例如iss簽發(fā)者sub主題aud接收方exp過期時間Expiration Time這是一個時間戳Unix epoch。nbf生效時間iat簽發(fā)時間公共聲明Public Claims可以自定義但為避免沖突應(yīng)定義在IANA JSON Web Token Registry或使用防沖突命名空間如包含一個域名。私有聲明Private Claims在提供方和消費方之間約定使用的自定義聲明用于傳遞業(yè)務(wù)信息如username、role、userid等。載荷部分經(jīng)過Base64Url編碼后成為JWT的第二部分。這里的關(guān)鍵在于載荷本身是未加密的僅做了編碼。任何人都可以輕松地將eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9Header和eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQPayload解碼看到原始內(nèi)容。因此絕對不要在JWT的載荷中存放任何敏感信息如密碼、信用卡號等。攻擊面也隨之而來如果服務(wù)器僅僅依賴JWT中的userid或role字段來判斷權(quán)限而沒有在服務(wù)端進(jìn)行二次校驗?zāi)敲创鄹妮d荷并相應(yīng)重簽就能直接實現(xiàn)越權(quán)。2.3 簽名Signature完整性的守護(hù)者簽名是JWT安全的核心。它的生成方式取決于頭部聲明的算法。對于HS256簽名是這樣生成的HMACSHA256(base64UrlEncode(header) . base64UrlEncode(payload), secret)對于RS256則是RSASHA256(base64UrlEncode(header) . base64UrlEncode(payload), private_key)簽名的目的是驗證消息在傳輸過程中未被篡改。驗證方使用頭部聲明的算法和相應(yīng)的密鑰對稱算法的secret或非對稱算法的公鑰對“頭部.載荷”部分重新計算簽名并與JWT中的第三部分進(jìn)行比對。如果一致則證明令牌有效且未被修改。3. 實戰(zhàn)攻擊手法詳解以“[隴劍杯 2021]jwt”為例理解了原理我們來看實戰(zhàn)。這類題目的常見解題路徑往往圍繞以下幾個關(guān)鍵攻擊面展開。我們假設(shè)題目環(huán)境是一個Web應(yīng)用登錄后獲得一個JWT目標(biāo)是提升權(quán)限如從普通用戶user提升為管理員admin。3.1 第一步信息收集與令牌解碼拿到題目首先用瀏覽器開發(fā)者工具或Burp Suite抓取登錄后的請求找到Authorization: Bearer your_jwt_token這個Header或者Cookie中的jwt、token字段拿到JWT字符串。接著進(jìn)行解碼。雖然可以手動Base64Url解碼但更推薦使用工具如在線網(wǎng)站jwt.io注意不要在真實敏感令牌上使用不可信的在線工具。命令行工具jwt-tool。Burp Suite擴(kuò)展JSON Web Tokens。解碼后我們重點關(guān)注頭部alg是什么有沒有不常見的字段如jwk、kid載荷有哪些聲明特別是自定義的username、role、isAdmin等。exp字段的值是多少一個時間戳它過期了嗎假設(shè)我們解碼后得到Header: {alg: HS256, typ: JWT} Payload: {sub: user123, username: guest, role: user, exp: 1698765432}顯然我們的目標(biāo)是修改username或role為管理員身份。3.2 攻擊面一弱密鑰Weak Secret爆破如果算法是HS256、HS384等對稱算法那么密鑰secret的強(qiáng)度至關(guān)重要。許多開發(fā)者在測試或初期會使用弱密鑰如secret、password、123456甚至是空字符串。jwt-tool工具內(nèi)置了強(qiáng)大的爆破功能。使用命令python3 jwt_tool.py your_jwt_token -C -d /path/to/wordlist.txt-C代表“Crack”-d指定字典文件。工具會嘗試用字典中的每一個詞作為secret去驗證簽名。如果爆破成功它會直接輸出正確的secret。拿到secret后我們就可以用任何JWT庫或jwt.io網(wǎng)站修改載荷并用這個secret重新生成合法的簽名。實操心得爆破字典的選擇很重要。除了常見的弱口令字典可以嘗試結(jié)合目標(biāo)應(yīng)用名稱、公司名、項目代號等生成專屬字典。有時密鑰就是dev、test、changeme這類簡單單詞。3.3 攻擊面二算法混淆攻擊CVE-2015-9235等這是歷史悠久的經(jīng)典漏洞。如果服務(wù)器端的JWT驗證庫存在邏輯缺陷可能會接受alg: none的令牌。攻擊步驟修改頭部為{alg: none, typ: JWT}。修改載荷如將role: user改為role: admin。將簽名部分即第三個點號后的內(nèi)容直接刪除或者置空。將修改后的Header.Payload.注意最后有一個點號提交給服務(wù)器。另一種混淆是RS256到HS256。如果服務(wù)器公鑰可獲取有時通過/jwks.json端點或網(wǎng)頁源碼泄露且服務(wù)器驗證邏輯有缺陷攻擊步驟為獲取服務(wù)器RSA公鑰通常為PEM格式。修改JWT頭部將alg從RS256改為HS256。修改載荷。使用這個公鑰作為HMAC的secret對新的Header.Payload進(jìn)行HS256簽名。發(fā)送偽造的令牌。使用jwt-tool可以自動化嘗試多種混淆攻擊python3 jwt_tool.py your_jwt_token -X a-X a代表“Exploit - All tests”它會自動嘗試none算法、混淆攻擊等多種方式。3.4 攻擊面三無效簽名繞過“None”漏洞的變種有些服務(wù)器端的驗證邏輯可能只檢查簽名是否存在或者解析JWT結(jié)構(gòu)失敗時默認(rèn)通過。我們可以嘗試簽名格式錯誤比如簽名部分不是Base64Url編碼包含、/等非法字符。簽名部分長度不對。在簽名后附加額外的點號或字符如Header.Payload.Signature.或Header.Payload.Signature.extra。這些手法的成功率取決于后端使用的具體JWT庫及其版本和配置。3.5 攻擊面四密鑰文件泄露與JKU/JWK/KID濫用這是更高級的攻擊面常出現(xiàn)在配置不當(dāng)或?qū)WT擴(kuò)展特性理解不深的場景。JKU頭部中的jku參數(shù)是一個URL指向一個包含驗證密鑰的JSON密鑰集JWKS。如果攻擊者能控制這個URL通過SSRF、域名劫持或上傳功能就可以指向自己控制的惡意JWKS從而使用自己的私鑰簽發(fā)任意令牌。JWK頭部中直接嵌入一個jwk參數(shù)包含用于驗證的公鑰。攻擊者可以替換成自己的公鑰。KIDkid是密鑰標(biāo)識符用于在服務(wù)器的多個密鑰中選擇一個。攻擊可能包括目錄遍歷如果kid參數(shù)未經(jīng)過濾像../../../../etc/passwd這樣的值可能導(dǎo)致服務(wù)器使用文件內(nèi)容作為密鑰可能被預(yù)測或利用。SQL注入如果kid用于從數(shù)據(jù)庫查詢密鑰可能引發(fā)SQL注入。命令注入極少數(shù)情況下kid可能被用于動態(tài)加載密鑰導(dǎo)致命令注入。對于“[隴劍杯 2021]jwt”這類題目往往需要綜合判斷。例如題目可能提示“密鑰就在服務(wù)器上”結(jié)合弱密鑰爆破和kid路徑遍歷如kid: /proc/self/cmdline泄露進(jìn)程信息進(jìn)而找到密鑰文件路徑來解題。3.6 攻擊面五時間戳攻擊exp, nbf, iat載荷中的exp、nbf、iat都是時間戳。服務(wù)器庫通常會驗證exp是否過期和nbf是否已生效。攻擊可能包括時鐘偏移利用如果服務(wù)器時間配置不同步存在較大偏移可能使一個本應(yīng)過期的令牌仍然有效。篡改時間戳直接修改exp為一個未來的時間戳。但這需要同時能繞過簽名驗證通常需要結(jié)合其他漏洞如弱密鑰、算法混淆一起使用。4. 工具鏈與手動操作不只是點按鈕雖然jwt-tool是瑞士軍刀但理解手動過程能加深認(rèn)知。這里以“弱密鑰爆破成功后的令牌偽造”為例展示完整流程。場景我們通過爆破發(fā)現(xiàn)目標(biāo)的HS256密鑰是supersecret。原始令牌eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwidXNlcm5hbWUiOiJndWVzdCIsInJvbGUiOiJ1c2VyIiwiZXhwIjoxNjk4NzY1NDMyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c解碼分析使用Pythonpyjwt庫或在線工具Header:{alg: HS256, typ: JWT}Payload:{sub: user123, username: guest, role: user, exp: 1698765432}修改載荷我們將role: user改為role: admin。注意exp如果已過期也需要改為一個未來的時間戳如9999999999。新的Payload JSON為{ sub: user123, username: guest, role: admin, exp: 9999999999 }手動生成新令牌使用Pythonimport jwt import time # 已知密鑰 secret supersecret # 構(gòu)造新的載荷 payload { sub: user123, username: guest, role: admin, exp: 9999999999 # 一個很遠(yuǎn)的未來時間 } # 生成新的JWT使用HS256算法和已知密鑰 new_token jwt.encode(payload, secret, algorithmHS256) print(new_token)運行后會得到一個新的、使用正確密鑰簽名的令牌。替換與測試在Burp Suite中用這個新令牌替換原請求中的令牌重放請求。觀察響應(yīng)看是否成功獲取了管理員權(quán)限的訪問例如訪問/admin頁面或響應(yīng)中返回了更多數(shù)據(jù)。踩坑記錄在手動編碼時務(wù)必確保JSON格式完全正確沒有多余的逗號字符串使用雙引號。一個常見的錯誤是exp的值沒有引號在JSON中它是數(shù)字但在某些庫的encode函數(shù)中載荷是字典類型庫會自動處理。如果手動拼接字符串進(jìn)行Base64編碼則必須嚴(yán)格遵守JSON格式。5. 防御視角開發(fā)中如何避免這些坑作為攻擊者我們尋找漏洞作為開發(fā)者或安全工程師我們則要堵上這些漏洞。以下是一些關(guān)鍵防御措施使用強(qiáng)算法和強(qiáng)密鑰優(yōu)先使用非對稱算法如RS256、ES256。私鑰妥善保存在服務(wù)器端公鑰可以安全分發(fā)。如果必須使用對稱算法HS256密鑰必須是高強(qiáng)度的隨機(jī)字符串如通過密碼學(xué)安全隨機(jī)數(shù)生成器生成并像保護(hù)密碼一樣保護(hù)它絕不能硬編碼在客戶端或前端代碼中。嚴(yán)格驗證算法在服務(wù)器端驗證簽名時不要依賴客戶端提供的alg頭。應(yīng)該有一個應(yīng)用配置明確指定期望接受的算法列表如只接受RS256。在驗證時使用配置中指定的算法和對應(yīng)的密鑰去驗證而不是讀取令牌頭中的alg值。這是防止算法混淆攻擊的根本方法。全面驗證聲明必須驗證exp、nbf、iat。驗證iss簽發(fā)者是否可信。驗證aud受眾是否包含本服務(wù)。對于自定義聲明如role、userid必須在服務(wù)端進(jìn)行二次校驗。例如根據(jù)userid從數(shù)據(jù)庫或緩存中查詢用戶最新的權(quán)限信息而不是完全信任JWT中的role字段。JWT應(yīng)作為會話狀態(tài)的“引用”而非“權(quán)威數(shù)據(jù)源”。安全處理JKU/JWK/KID如果使用jku或jwk必須嚴(yán)格驗證URL是否來自可信的白名單域名并對獲取的密鑰進(jìn)行完整性驗證。對kid參數(shù)進(jìn)行嚴(yán)格的輸入驗證防止路徑遍歷、SQL注入等攻擊。使用最新的、經(jīng)過安全審計的庫避免使用已過時或有已知漏洞的JWT庫。關(guān)注社區(qū)安全公告及時更新。設(shè)置合理的令牌生命周期訪問令牌Access Token有效期宜短如15分鐘配合刷新令牌Refresh Token使用減少令牌泄露后的風(fēng)險窗口。6. 拓展思考JWT在真實紅隊評估中的位置在真實的滲透測試中JWT漏洞很少孤立存在。它往往是橫向移動或權(quán)限提升鏈條中的一環(huán)。我們可能需要結(jié)合其他漏洞來獲取攻擊JWT的初始條件信息泄露通過源碼泄露、目錄遍歷、錯誤配置的.git目錄等找到硬編碼的JWT密鑰或公鑰/私鑰文件。SSRF利用服務(wù)器端請求偽造讓服務(wù)器從內(nèi)網(wǎng)或攻擊者控制的地址獲取JWKSjku從而注入惡意公鑰。邏輯漏洞例如注冊或密碼重置功能處可能允許我們設(shè)置自己的username為admin如果JWT的username直接來自用戶輸入且未做過濾然后再通過JWT重放獲得管理員上下文。中間件配置問題某些API網(wǎng)關(guān)或反向代理如Kong, APISIX在配置JWT驗證插件時如果配置不當(dāng)也可能引入類似alg: none的漏洞。因此拿到一個JWT后不要僅僅盯著令牌本身。要思考這個令牌從哪里來登錄接口、OAuth回調(diào)服務(wù)器用什么庫驗證密鑰可能存儲在哪里是否有其他接口或頁面泄露了關(guān)鍵信息這種關(guān)聯(lián)性思維才是將CTF技巧轉(zhuǎn)化為實戰(zhàn)能力的關(guān)鍵。回到“[隴劍杯 2021]jwt”這道題它像是一個精致的微縮景觀集中展示了JWT最常見的安全問題。通過手動或工具輔助的逐步測試——從解碼觀察、嘗試none算法、爆破弱密鑰、檢查kid路徑遍歷到最終偽造高權(quán)限令牌——我們完成了一次完整的JWT安全審計流程。掌握它你不僅能在CTF中得分更能在真實的Web應(yīng)用安全評估中多一雙發(fā)現(xiàn)漏洞的銳利眼睛。記住令牌只是表象背后的驗證邏輯和系統(tǒng)配置才是真正的戰(zhàn)場。