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