作者：王菲，單位：中移物聯(lián)網(wǎng)有限公司

JSON Web Token（縮寫JWT）是當前被廣泛采用的跨域認證解決方案，通常被用來在身份提供者和服務平臺提供者間傳遞已經(jīng)認證的用戶，進行身份管理，以便于從資源服務器中獲取所需的企業(yè)資源，但是如果未對JWT做好防護，會造成一系列安全風險。

Part 01●??什么是JWT？

在JWT官網(wǎng)的基本概念中，JSON Web Token (JWT)定義了一個在各方之間通過 JSON 對象安全傳輸信息的方式，它將用戶信息加密保存在JSON格式的token中，服務端將不會保存任何與用戶認證的相關配置信息，只保存校驗token簽名的密鑰，通過簽名的校驗來判斷用戶身份是否合法。此時，這種基于token的身份驗證方法能夠代替?zhèn)鹘y(tǒng)的cookie+session身份驗證方法。

1.1 傳統(tǒng)的cookie+session身份驗證方法認證流程

- 用戶端在瀏覽器中輸入用戶名和密碼，發(fā)送到服務器。

- 服務器通過密碼校驗后生成session并保存到數(shù)據(jù)庫中。

- 為用戶端生成一個sessionid，并在瀏覽器中存放擁有sessionid的cookie，當再次發(fā)出請求時均會有對這個cookie信息的訪問。

- 服務器獲取用戶cookie，根據(jù)其中的sessionid在數(shù)據(jù)庫中查找，進而判斷請求是否有效。

- 這種session+cookie的模式，是互聯(lián)網(wǎng)應用中最為流行的用戶認證模式，但是這種模式的擴展性并不好，如何解決這個問題呢？接下來讓我們繼續(xù)認識擴展性更好的JWT認證。

1.2 基于JWT的認證流程

JWT保存在客戶端，服務器端只需要通過密鑰解密技術對JWT進行分析和驗證，不需要再繁瑣地進行數(shù)據(jù)庫查詢和管理。也就是說服務器不用負擔保存任何保存session數(shù)據(jù)的任務，減輕服務器壓力，因此比較容易實現(xiàn)擴展。

JWT認證流程：

用戶端在瀏覽器中輸入用戶名和密碼，服務器通過密碼校驗后生成JWT。

客戶端獲取到token，存儲到cookie或local storage中，當再次發(fā)出請求時均會有對這個token信息的訪問。

用戶在request請求頭中包含JWT，并發(fā)給服務器。

服務端將會檢查請求頭中的 JWT 信息，如果正確，則返回響應并允許用戶操作。

圖1 JWT認證流程

Part 02●??JWT格式?

物聯(lián)網(wǎng)安全是JWT由三部分組成，中間用點（.）分隔，依次如下：Header（頭部）、Payload（負載）、Signature（簽名）。JWT格式如下圖2所示。

圖2 JWT格式

2.1 Header（頭部）

JWT的頭部其實就是個JSON對象，它承載著兩部分信息：

- 聲明類型

- 聲明加密的算法

將頭部信息通過Base64URL加密轉成字符串即為JWT頭部。

2.2 Payload（負載）

負載就是存放有效信息的地方，這些有效信息包含三個部分：

標準中注冊的聲明

公共的聲明

私有的聲明

同樣將上面的JSON對象使用Base64URL加密轉成字符串即為JWT負載。

2.3 Signature（簽名）

服務器通常通過散列header和payload來生成簽名。在一些情況下，還會加密生成的哈希值，無論是否加密，過程中都會涉及到簽名密鑰。服務器通過讀取header中指定的簽名算法，按照下表中的公式產(chǎn)生簽名。

簽名機制為服務器提供防篡改的驗證方法：

因為簽名是直接從令牌的前兩部分派生的，因此更改header或payload的單個字節(jié)，都會導致簽名失配。

在不知道服務器的簽名密鑰的情況下，不能為已經(jīng)給定的header或payload生成正確的簽名。

JWT三個組成部分的解碼展示如下圖3所示。

圖3 JWT解碼展示

Part 03●? 什么是JWT攻擊？

3.1 JWT攻擊

JWT攻擊是指攻擊者向服務器發(fā)送篡改過的JWT，實施惡意操作的行為。一般情況下，攻擊的目的是偽造身份認證的用戶，來繞過身份驗證和訪問控制的阻攔。而如果攻擊者能夠生成任意的有效令牌，就能夠提升用戶權限或假冒其他合法用戶的身份，從而對這些偽造的用戶賬戶實施完全的接管。

3.2 攻擊原理

JSON Web Token（JWT）存在的漏洞往往源于應用程序對JWT的處理存在缺陷，進而影響了其安全性。JWT及其相關規(guī)范的設計賦予了網(wǎng)站開發(fā)人員較大的自由度，允許自主決定許多實現(xiàn)細節(jié)，但是這種自由度也可能導致安全問題的出現(xiàn)。

這些實現(xiàn)缺陷往往直接關聯(lián)于JWT簽名的驗證，即便進行了嚴格的簽名驗證，攻擊者仍有可能通過篡改JWT負載中的數(shù)據(jù)，傳遞惡意值給應用程序，從而干擾正常業(yè)務流程。此外，關于傳遞簽名的可信性，主要取決于密鑰的安全性，但是如果服務器的密鑰存在泄漏或被破解，攻擊者將能夠生成合法的簽名，進而偽造令牌并嚴重威脅整個身份驗證與授權機制的完整性。

Part 04●? JWT常見安全漏洞?●

了解了JWT攻擊原理，再讓我們繼續(xù)了解一下JWT相關常見漏洞，主要有以下類型：

1.Accepting arbitrary signatures -- 接受任意簽名

2.Accepting tokens with no signature -- 沒有簽名的令牌

3.Brute-forcing secret keys -- 暴力破解密鑰

4.JWT header parameter injections -- JWT 頭參數(shù)注入

Injecting self-signed JWTs via the jwk parameter --jwk參數(shù)注入自簽名

Injecting self-signed JWTs via the kid parameter -- kid參數(shù)注入自簽名

Injecting self-signed JWTs via the jku parameter --jku參數(shù)注入自簽名

4.1 Accepting arbitrary signatures -- 接受任意簽名

JWT庫通常會提供一個驗證token的方法，同時也會提供對其解碼的方法。例如Node.js庫jsonwebtoken的兩個方法：verify()、decode()。如果開發(fā)只把decode()方法傳給token而沒有傳遞verify()方法，這意味著攻擊者可以將隨意修改payload后的JWT發(fā)送給服務器，服務器僅僅會對JWT進行解碼解析卻沒有驗證簽名是否正確，從而造成偽造用戶、越權訪問等安全問題。

4.2 Accepting tokens with no signature -- 沒有簽名的令牌

JWT頭部有一個重要參數(shù)“alg”，它會指明JWT簽名所采用的算法。JWT支持多種算法來進行簽名，也可以不進行簽名。通過修改alg參數(shù)為“none”，此時簽名為空，這就是生成了“不安全的JWT”。

圖4 修改JWT的header頭部alg參數(shù)為“none”

圖5 修改前后的JWT

4.3 Brute-forcing secret keys -- 暴力破解密鑰

某些簽名算法，會使用一個字符串作為密鑰，而當我們知道JWT簽名算法的時候，就必須要保證這個密鑰不能被腳本輕易猜測或暴力破解，否則攻擊者可以用任意header和payload來簽名創(chuàng)建合法JWT。

4.4 JWT header parameter injections -- JWT頭參數(shù)注入

根據(jù)JWS規(guī)范，只有頭部參數(shù)alg是一定要有的。但是在實際生產(chǎn)中，JWT頭部不僅僅有alg參數(shù)，往往還包含其它參數(shù)。以下三個是實際生活中通常測試攻擊的參數(shù)：

? jwk（JSON Web Key）：是一種用于表示密鑰的嵌入式 JSON 對象。正常時候服務器應該要對其進行限制，只能使用特定的公鑰白名單進行簽名驗證。然而，如果出現(xiàn)配置失誤或疏忽，某些服務器可能會誤用JWK參數(shù)內(nèi)嵌的任何密鑰進行簽名驗證操作。這就意味著，如果出現(xiàn)jwk配置失誤，攻擊者就可以通過RSA私鑰對已經(jīng)修改過的payload進行簽名，并將RSA公鑰嵌入到JWK頭部，從而繞過簽名認證。

? kid（Key ID）：即密鑰標識符，被用作提供一個獨特的標識，當存在有多個密鑰的情況下，服務器就會通過此ID來準確識別應用于驗證的正確密鑰。但是，系統(tǒng)并不具備辨別用戶意圖的能力，因此如果缺乏對參數(shù)的過濾措施，攻擊者就可能篡改密鑰文件，從而實現(xiàn)任意文件讀取攻擊，借此讀取系統(tǒng)內(nèi)的各類文件資源。

? jku（JSON Web Key Set URL）：是一種用于提供URL的機制，發(fā)送jwk的地址。與"key ID" (kid) 類似，jku 也可以由用戶根據(jù)特定輸入數(shù)據(jù)來指定。一旦用戶的輸入數(shù)據(jù)沒有經(jīng)過嚴格的過濾和驗證，就可能導致潛在的安全漏洞。

上述用戶可操控的參數(shù)用于指示接收方服務器在進行簽名驗證時所需的密鑰信息，如果攻擊者修改這些可控參數(shù)可能會導致任意文件讀取、SQL注入等安全問題。

Part 05●? JWT安全防護?

根據(jù)上述安全漏洞，總結有以下防護措施：

1.不要在token中設置任何敏感信息，同時不要將payload中的時間戳失效設定太長，防止被盜的token長時間被濫用。

2.使用最新的庫來處理JWT，并確保完全理解它的工作原理以及任何安全隱患。

3.在服務器端，限制JWT頭部中“alg”參數(shù)的值只能使用特定的、安全的算法。禁止使用不安全的算法，如"none"算法。

4.針對JWT頭部進行嚴格的白名單設置，只允許特定的參數(shù)值，拒絕任何不在白名單內(nèi)的參數(shù)值。

Part 06●? 總結?

已簽名的JWT具有標頭、負載和簽名三部分，每個都在確保JWT可用于安全地存儲和傳輸關鍵信息方面發(fā)揮著至關重要的身份驗證作用。了解這三個組件對于正確使用JWT至關重要，同時由于簽名的重要性，我們有必要對JWT安全進行了解并做好防護，從而做到防范于未然。