五分鐘技術(shù)趣談 | 淺析JWT安全

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

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

Part 01●??什么是JWT？

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

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

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

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

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

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

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

1.2 基于JWT的認(rèn)證流程

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

JWT認(rèn)證流程：

用戶端在瀏覽器中輸入用戶名和密碼，服務(wù)器通過密碼校驗(yàn)后生成JWT。

客戶端獲取到token，存儲(chǔ)到cookie或local storage中，當(dāng)再次發(fā)出請求時(shí)均會(huì)有對(duì)這個(gè)token信息的訪問。

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

服務(wù)端將會(huì)檢查請求頭中的 JWT 信息，如果正確，則返回響應(yīng)并允許用戶操作。

圖1 JWT認(rèn)證流程

Part 02●??JWT格式?

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

圖2 JWT格式

2.1 Header（頭部）

JWT的頭部其實(shí)就是個(gè)JSON對(duì)象，它承載著兩部分信息：

- 聲明類型

- 聲明加密的算法

將頭部信息通過Base64URL加密轉(zhuǎn)成字符串即為JWT頭部。

2.2 Payload（負(fù)載）

負(fù)載就是存放有效信息的地方，這些有效信息包含三個(gè)部分：

標(biāo)準(zhǔn)中注冊的聲明

公共的聲明

私有的聲明

同樣將上面的JSON對(duì)象使用Base64URL加密轉(zhuǎn)成字符串即為JWT負(fù)載。

2.3 Signature（簽名）

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

簽名機(jī)制為服務(wù)器提供防篡改的驗(yàn)證方法：

因?yàn)楹灻侵苯訌牧钆频那皟刹糠峙缮?，因此更改header或payload的單個(gè)字節(jié)，都會(huì)導(dǎo)致簽名失配。

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

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

圖3 JWT解碼展示

Part 03●? 什么是JWT攻擊？

3.1 JWT攻擊

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

3.2 攻擊原理

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

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

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

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

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

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

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

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

圖5 修改前后的JWT

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

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

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

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

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

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

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

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

Part 05●? JWT安全防護(hù)?

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

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

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

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

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

Part 06●? 總結(jié)?

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