01 JWT簡介

JWT全稱為JSON Web Token,將json對象作為載體來傳輸信息，一般被用在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便于從資源服務器獲取資源，也可以增加一些額外的業(yè)務邏輯所必須聲明信息，該token可被直接用于認證，也可用作加密。

JSON Web令牌（JWT）是一種標準化的格式，用于在系統(tǒng)之間發(fā)送經(jīng)過加密簽名的JSON數(shù)據(jù)。理論上JWT可以包含任何類型的數(shù)據(jù)，但最常用于進行身份認證、會話處理和訪問控制。與傳統(tǒng)的會話令牌不同，服務器需要的所有數(shù)據(jù)都存儲在JWT本身的客戶端。這使得JWT成為高度分布式網(wǎng)站的熱門選擇，在這些網(wǎng)站中，用戶需要與多個后端服務器進行無縫交互。

1.1 JWT格式

JWT由3部分組成：頭部、載荷和簽名。這些部分之間用點號隔開，如下所示：

eyJraWQiOiI5MTM2ZGRiMy1jYjBhLTRhMTktYTA3ZS1lYWRmNWE0NGM4YjUiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJwb3J0c3dpZ2dlciIsImV4cCI6MTY0ODAzNzE2NCwibmFtZSI6IkNhcmxvcyBNb250b3lhIiwic3ViIjoiY2FybG9zIiwicm9sZSI6ImJsb2dfYXV0aG9yIiwiZW1haWwiOiJjYXJsb3NAY2FybG9zLW1vbnRveWEubmV0IiwiaWF0IjoxNTE2MjM5MDIyfQ.SYZBPIBg2CRjXAJ8vCER0LA_ENjII1JakvNQoP-Hw6GG1zfl4JyngsZReIfqRvIAEi5L4HV0q7_9qGhQZvy9ZdxEJbwTxRs_6Lb-fZTDpW6lKYNdMyjw45_alSCZ1fypsMWz_2mTpQzil0lOtps5Ei_z7mM7M8gCwe_AGpI53JxduQOaB5HkT5gVrv9cKu9CsW5MS6ZbqYXpGyOG5ehoxqm8DL5tFYaW3lB50ELxi0KsuTKEbD0t5BCl0aCR2MBJWAbN-xeLwEenaqBiwPVvKixYleeDQiBEIylFdNNIMviKRgXiYuAvMziVPbwSgkZVHeEdF5MQP1Oe2Spac-6IfA

JWT的頭部和載荷部分其實就是用base64url編碼的JSON對象。其中頭部包含關于令牌本身的元數(shù)據(jù)，而載荷包含關于用戶的實際“聲明”?？梢詫ι鲜隽钆频妮d荷進行解碼，結果如下：

{

"iss": "portswigger",

"exp": 1648037164,

"name": "Carlos Montoya",

"sub": "carlos",

"role": "blog_author",

"email": "carlos@carlos-montoya.net",

"iat": 1516239022

}

大多數(shù)情況下，任何有權訪問令牌的人都可以輕松地讀取或修改這些數(shù)據(jù)。因此任何基于JWT機制的安全性都嚴重依賴于密碼簽名。

1.2 JWT簽名

頒發(fā)令牌的服務器通常通過對頭部和載荷計算哈希值來生成簽名。有時會對產(chǎn)生的哈希值進行加密處理。但是無論哪種方式，這個過程都涉及一個秘密密鑰。如果密鑰未知，就無法為給定的頭部和載荷生成有效的簽名。這實際上就為服務器提供了一種驗證令牌頒發(fā)以來數(shù)據(jù)是否被篡改的機制，因為任何對頭部或載荷部分的修改都會使簽名不再匹配。

02 JWT、JWS與JWE

JWT規(guī)范的約束實際上是非常有限的。因為它只定義了將信息（“聲明”）表示為可以在雙方之間傳輸?shù)腏SON對象的格式。在實際使用中，JWT并沒有真正作為一個獨立的實體使用。JWT規(guī)范由JSON Web簽名(JWS)和JSON Web加密(JWE)規(guī)范組成，共同定義了實際實現(xiàn)JWT的具體方法。

也就是說，JWT通常是指JWS或JWE令牌，JWE同理，只是令牌的實際內(nèi)容是經(jīng)過加密的。

2.1 JWT攻擊

JWT攻擊是指用戶向服務器發(fā)送修改過的JWT，執(zhí)行惡意操作。通常情況下，比較常見的是冒充已經(jīng)通過身份認證的用戶，繞過認證和訪問控制。如果攻擊者能夠用任意值創(chuàng)建自己的有效令牌，他們就能夠提升自己的權限或冒充其他用戶，從而完全接管這些用戶的賬戶。

2.2 攻擊原理

JWT漏洞通常是由于應用程序本身對JWT的處理有缺陷而產(chǎn)生的。與JWT有關的各種規(guī)范在設計上相對靈活，例如允許網(wǎng)站開發(fā)人員自行決定許多實現(xiàn)細節(jié)。但這也可能會引發(fā)一些安全問題。這些實現(xiàn)缺陷通常意味著JWT的簽名沒有被正確驗證。即使嚴格檢查簽名，攻擊者也可以通過令牌的載荷篡改傳遞給應用程序的值。簽名是否可以信任在很大程度上也取決于服務器的秘鑰是否仍然是安全的。如果這個密鑰被泄露或者破解，那么攻擊者就可以為任意令牌生成有效的簽名，從而攻陷整個機制。

2.3 JWT簽名驗證

根據(jù)設計，一般情況下服務器不存儲任何關于頒發(fā)的JWT的信息。因此每個令牌都是一個完全獨立的實體。雖然這樣做有許多優(yōu)點，但也導致了一個隱患，即服務器實際上不知道關于令牌的原始內(nèi)容，甚至不知道原始簽名是什么。正因如此，如果服務器沒有正確效驗簽名，也就無法阻止攻擊者對令牌的其他部分任意篡改。

例如，一個包含以下聲明的JWT如下：

{

"username": "carlos",

"isAdmin": false

}

如果服務器是根據(jù)username來識別會話，那么攻擊者就能夠通過修改用戶名來冒充其他已登錄的用戶。同樣，如果isAdmin值被用于訪問控制，攻擊者也可以提通過篡改這個值來實現(xiàn)提權。

03 JWT相關漏洞類型

3.1 接受任意簽名

JWT庫通常會提供一個驗證令牌的方法，同時提供對其解碼的方法。例如，對于Node.js庫jsonwebtoken來說，這兩個方法分別是verify()和decode()。

但有時開發(fā)人員會混淆這兩個方法，只把傳入的令牌傳給decode()方法。這實際上意味著應用程序根本就沒有對簽名進行驗證。

3.2 接受未簽名的令牌

JWT頭部還包含一個alg參數(shù)。該參數(shù)的作用就是告訴服務器對令牌進行簽名時使用的是哪種算法，換句話說就是在驗證簽名時需要使用哪種算法。

{

"alg": "HS256",

"typ": "JWT"

}

但本質(zhì)上這種方法存在安全隱患，因為服務器只能隱式地信任提供令牌的用戶的輸入（注意，這些輸入受控于該用戶），而該令牌根本沒有被驗證過。換句話說攻擊者可以直接影響服務器檢查令牌是否值得信任的方式。

JWT既可以使用一系列不同的算法進行簽名，也可以不簽名。在這種情況下，alg參數(shù)被設置為None，表示所謂的 "不安全的JWT"。由于這種情況明顯存在安全問題，因此服務器通常會拒絕沒有簽名的令牌。但由于這種過濾依賴于字符串解析，所以攻擊者可以使用混淆技術繞過這些過濾器，如混合大寫和非預期的編碼等。（需要注意的是，即使令牌是未簽名的，載荷部分也必須以點號結尾。）

3.3 暴力破解密鑰

某些簽名算法，例如HS256（HMAC + SHA-256），會像密碼一樣使用一個任意的、獨立的字符串作為秘密密鑰。需要保證這個秘鑰不被輕易猜到或暴力破解，否則攻擊者能以任意的頭部和載荷值來創(chuàng)建JWT，然后用密鑰重新給令牌簽名。

在實現(xiàn)JWT應用時，開發(fā)人員有時會忘記改變默認或占位的密碼，甚至可能復制和粘貼在網(wǎng)上找到的代碼片段，然后忘記改變作為示例提供的硬編碼的密碼。在這種情況下，攻擊者使用流行的密碼本，可以輕松對服務器的登陸憑據(jù)進行暴力破解。

3.4 JWT頭部參數(shù)注入

根據(jù)JWS規(guī)范，只有頭部參數(shù)alg是必需的。然而實際中JWT頭部（也稱為JOSE頭部）通常包含其他幾個參數(shù)。以下是攻擊者特別感興趣的參數(shù)：

jwk（JSON Web Key）：提供一個表示密鑰的嵌入式JSON對象。

jku（JSON Web Key Set URL）：提供一個URL，服務器可以從中獲取一組包含正確密鑰的密鑰。

kid（Key ID）：提供一個ID，在有多個密鑰可供選擇的情況下，服務器可以使用該ID來識別正確的密鑰。根據(jù)密鑰的格式可能還有一個匹配的kid參數(shù)。

如上，這些用戶可控制的參數(shù)用于告訴接收方服務器在驗證簽名時使用哪些密鑰。

3.5 jwk參數(shù)注入

JSON Web簽名（JWS）規(guī)范描述了一個可選的jwk頭部參數(shù)，服務器可以用它將其公鑰直接嵌入JWK格式的令牌本身。JWK（JSON Web密鑰）是一種標準化的格式，用于將密鑰表示為JSON對象。

JWT頭部示例如下：

{

"kid": "ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG",

"typ": "JWT",

"alg": "RS256",

"jwk": {

"kty": "RSA",

"e": "AQAB",

"kid": "ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG",

"n": "yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9m"

}

}

理想情況下，服務器應該只使用有限的公鑰白名單來驗證JWT簽名。然而配置錯誤的服務器有時會使用jwk參數(shù)中嵌入的任何密鑰來驗證簽名。

因此攻擊者可以利用這種行為，用自己的RSA私鑰對修改過的JWT進行簽名，然后在jwk頭部中嵌入對應的公鑰。

雖然也可以在Burp中手動添加或修改jwk參數(shù)，但JWT編輯器擴展提供了一個非常方便的功能，用于幫助研究人員測試這個漏洞：

在加載該擴展后，在Burp的主選項卡欄中，轉(zhuǎn)到JWT Editor Keys選項卡。

創(chuàng)建一個新的RSA密鑰。

向Burp Repeater發(fā)送一個包含JWT的請求。

在消息編輯器中，切換到擴展生成的JSON Web Token選項卡，并以你喜歡的方式修改令牌的載荷。

點擊Attack按鈕，然后選擇Embedded JWK。當收到提示時，選擇新生成的RSA密鑰。

發(fā)送請求，測試服務器的響應情況。

有些服務器并不會直接使用jwk頭部參數(shù)來嵌入公鑰，而是使用jku（JWK Set URL）頭部參數(shù)來引用一個包含密鑰的JWK Set。當驗證簽名時，服務器會從這個URL中獲取相關的密鑰。

實際上所謂JWK Set就是一個JSON對象，其中包含一組表示密鑰的JWK，例如：

{

"keys": [

{

"kty": "RSA",

"e": "AQAB",

"kid": "75d0ef47-af89-47a9-9061-7c02a610d5ab",

"n": "o-yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9mk6GPM9gNN4Y_qTVX67WhsN3JvaFYw-fhvsWQ"

},

{

"kty": "RSA",

"e": "AQAB",

"kid": "d8fDFo-fS9-faS14a9-ASf99sa-7c1Ad5abA",

"n": "fc3f-yy1wpYmffgXBxhAUJzHql79gNNQ_cb33HocCuJolwDqmk6GPM4Y_qTVX67WhsN3JvaFYw-dfg6DH-asAScw"

}

]

}

像這樣的JWK集有時會通過一個標準的端點對外公開，如/.known/jwks.json，攻擊者有時可以利用URL解析的差異來繞過這種過濾機制。

3.7 kid參數(shù)注入

服務器可能會使用多個加密密鑰來為不同類型的數(shù)據(jù)進行簽名。出于這個原因，JWT的頭部可能包含一個kid（密鑰ID）參數(shù)，用來幫助服務器識別在驗證簽名時要使用的密鑰。

驗證密鑰通常被存儲為JWK Set。在這種情況下，服務器可以直接尋找與令牌具有相同kid參數(shù)的JWK。然而JWS規(guī)范并沒有為這個ID定義具體的結構，它只是開發(fā)人員任意選擇的一個字符串。例如可以使用kid參數(shù)來指向數(shù)據(jù)庫中的一個特定條目，甚至文件名稱。

如果該參數(shù)受到目錄遍歷的影響，攻擊者就有可能迫使服務器使用其文件系統(tǒng)中的任意文件作為驗證密鑰。

{

"kid": "../../path/to/file",

"typ": "JWT",

"alg": "HS256",

"k": "asGsADas3421-dfh9DGN-AFDFDbasfd8-anfjkvc"

}

如果服務器也支持使用對稱算法為JWT簽名，攻擊者可以將kid參數(shù)指向一個可預測的靜態(tài)文件，然后用一個與該文件內(nèi)容相匹配的秘密來給JWT簽名，簡單的方法之一是使用/dev/null。該文件是一個空文件，讀取時將返回null，可以用一個Base64編碼的null字節(jié)來給令牌簽名將得到一個有效的簽名。

如果服務器將其驗證密鑰存儲在數(shù)據(jù)庫中，kid頭部參數(shù)也是一個潛在的SQL注入攻擊的載體。

3.8其他JWT頭部參數(shù)

cty（內(nèi)容類型）：用來聲明JWT載荷中內(nèi)容的媒體類型。通常情況下會省略該參數(shù)，但底層解析庫可能還是支持它。如果攻擊者已經(jīng)找到了繞過簽名驗證的方法，可能會嘗試注入cty參數(shù)，將內(nèi)容類型改為text/xml或application/x-java-serialized-object，這有可能為XXE和反序列化攻擊提供新的向量。

x5c（X.509證書鏈）：用于傳遞用于對JWT進行數(shù)字簽名的X.509公鑰證書或證書鏈。這個頭部參數(shù)可用于注入自簽證書，類似于上面討論的jwk頭部注入攻擊。由于X.509格式及其擴展的復雜性，解析這些證書也很可能會引入漏洞。

3.9 JWT算法混淆

即使服務器使用了攻擊者無法破解的強密碼，對方仍然可以使用開發(fā)人員沒有預料到的算法簽名令牌來偽造有效的JWT，這就是所謂的算法混淆攻擊。

04 防御JWT攻擊

使用最新的庫來處理JWT，并確保開發(fā)人員對相關安全問題足夠了解。現(xiàn)代代碼庫的使用降低了在代碼實現(xiàn)中引入安全漏洞的可能性，但由于相關規(guī)范固有的靈活性，也并非萬無一失。

確保對收到的任何JWT進行嚴格的簽名驗證，并考慮邊緣情況，如使用非預期的算法簽名的JWT。

為jku頭部提供允許主機白名單，并嚴格執(zhí)行。

確保不會受到kid頭部參數(shù)路徑穿越或SQL注入的影響。

05 參考鏈接

https://portswigger.net/web-security/jwt

https://blog.csdn.net/cdyunaq/article/details/122561096