4194
作者：王菲，單位：中移物聯(lián)網(wǎng)有限公司
JSON Web Token（縮寫JWT）是當(dāng)前被廣泛采用的跨域認(rèn)證解決方案，通常被用來在身份提供者和服務(wù)平臺提供者間傳遞已經(jīng)認(rèn)證的用戶，進(jìn)行身份管理，以便于從資源服務(wù)器中獲取所需的企業(yè)資源，但是如果未對JWT做好防護(hù)，會造成一系列安全風(fēng)險。
Part 01●??什么是JWT？
在JWT官網(wǎng)的基本概念中，JSON Web Token (JWT)定義了一個在各方之間通過 JSON 對象安全傳輸信息的方式，它將用戶信息加密保存在JSON格式的token中，服務(wù)端將不會保存任何與用戶認(rèn)證的相關(guān)配置信息，只保存校驗token簽名的密鑰，通過簽名的校驗來判斷用戶身份是否合法。此時，這種基于token的身份驗證方法能夠代替?zhèn)鹘y(tǒng)的cookie+session身份驗證方法。
1.1 傳統(tǒng)的cookie+session身份驗證方法認(rèn)證流程
- 用戶端在瀏覽器中輸入用戶名和密碼，發(fā)送到服務(wù)器。
- 服務(wù)器通過密碼校驗后生成session并保存到數(shù)據(jù)庫中。
- 為用戶端生成一個sessionid，并在瀏覽器中存放擁有sessionid的cookie，當(dāng)再次發(fā)出請求時均會有對這個cookie信息的訪問。
- 服務(wù)器獲取用戶cookie，根據(jù)其中的sessionid在數(shù)據(jù)庫中查找，進(jìn)而判斷請求是否有效。
- 這種session+cookie的模式，是互聯(lián)網(wǎng)應(yīng)用中最為流行的用戶認(rèn)證模式，但是這種模式的擴展性并不好，如何解決這個問題呢？接下來讓我們繼續(xù)認(rèn)識擴展性更好的JWT認(rèn)證。
1.2 基于JWT的認(rèn)證流程
JWT保存在客戶端，服務(wù)器端只需要通過密鑰解密技術(shù)對JWT進(jìn)行分析和驗證，不需要再繁瑣地進(jìn)行數(shù)據(jù)庫查詢和管理。也就是說服務(wù)器不用負(fù)擔(dān)保存任何保存session數(shù)據(jù)的任務(wù)，減輕服務(wù)器壓力，因此比較容易實現(xiàn)擴展。
JWT認(rèn)證流程：
用戶端在瀏覽器中輸入用戶名和密碼，服務(wù)器通過密碼校驗后生成JWT。
客戶端獲取到token，存儲到cookie或local storage中，當(dāng)再次發(fā)出請求時均會有對這個token信息的訪問。
用戶在request請求頭中包含JWT，并發(fā)給服務(wù)器。
服務(wù)端將會檢查請求頭中的 JWT 信息，如果正確，則返回響應(yīng)并允許用戶操作。
圖1 JWT認(rèn)證流程
Part 02●??JWT格式?
物聯(lián)網(wǎng)安全是JWT由三部分組成，中間用點（.）分隔，依次如下：Header（頭部）、Payload（負(fù)載）、Signature（簽名）。JWT格式如下圖2所示。
圖2 JWT格式
2.1 Header（頭部）
JWT的頭部其實就是個JSON對象，它承載著兩部分信息：
- 聲明類型
- 聲明加密的算法
將頭部信息通過Base64URL加密轉(zhuǎn)成字符串即為JWT頭部。
2.2 Payload（負(fù)載）
負(fù)載就是存放有效信息的地方，這些有效信息包含三個部分：
標(biāo)準(zhǔn)中注冊的聲明
公共的聲明
私有的聲明
同樣將上面的JSON對象使用Base64URL加密轉(zhuǎn)成字符串即為JWT負(fù)載。
2.3 Signature（簽名）
服務(wù)器通常通過散列header和payload來生成簽名。在一些情況下，還會加密生成的哈希值，無論是否加密，過程中都會涉及到簽名密鑰。服務(wù)器通過讀取header中指定的簽名算法，按照下表中的公式產(chǎn)生簽名。
簽名機制為服務(wù)器提供防篡改的驗證方法：
因為簽名是直接從令牌的前兩部分派生的，因此更改header或payload的單個字節(jié)，都會導(dǎo)致簽名失配。
在不知道服務(wù)器的簽名密鑰的情況下，不能為已經(jīng)給定的header或payload生成正確的簽名。
JWT三個組成部分的解碼展示如下圖3所示。
圖3 JWT解碼展示
Part 03●? 什么是JWT攻擊？
3.1 JWT攻擊
JWT攻擊是指攻擊者向服務(wù)器發(fā)送篡改過的JWT，實施惡意操作的行為。一般情況下，攻擊的目的是偽造身份認(rèn)證的用戶，來繞過身份驗證和訪問控制的阻攔。而如果攻擊者能夠生成任意的有效令牌，就能夠提升用戶權(quán)限或假冒其他合法用戶的身份，從而對這些偽造的用戶賬戶實施完全的接管。
3.2 攻擊原理
JSON Web Token（JWT）存在的漏洞往往源于應(yīng)用程序對JWT的處理存在缺陷，進(jìn)而影響了其安全性。JWT及其相關(guān)規(guī)范的設(shè)計賦予了網(wǎng)站開發(fā)人員較大的自由度，允許自主決定許多實現(xiàn)細(xì)節(jié)，但是這種自由度也可能導(dǎo)致安全問題的出現(xiàn)。
這些實現(xiàn)缺陷往往直接關(guān)聯(lián)于JWT簽名的驗證，即便進(jìn)行了嚴(yán)格的簽名驗證，攻擊者仍有可能通過篡改JWT負(fù)載中的數(shù)據(jù)，傳遞惡意值給應(yīng)用程序，從而干擾正常業(yè)務(wù)流程。此外，關(guān)于傳遞簽名的可信性，主要取決于密鑰的安全性，但是如果服務(wù)器的密鑰存在泄漏或被破解，攻擊者將能夠生成合法的簽名，進(jìn)而偽造令牌并嚴(yán)重威脅整個身份驗證與授權(quán)機制的完整性。
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庫通常會提供一個驗證token的方法，同時也會提供對其解碼的方法。例如Node.js庫jsonwebtoken的兩個方法：verify()、decode()。如果開發(fā)只把decode()方法傳給token而沒有傳遞verify()方法，這意味著攻擊者可以將隨意修改payload后的JWT發(fā)送給服務(wù)器，服務(wù)器僅僅會對JWT進(jìn)行解碼解析卻沒有驗證簽名是否正確，從而造成偽造用戶、越權(quán)訪問等安全問題。
4.2 Accepting tokens with no signature -- 沒有簽名的令牌
JWT頭部有一個重要參數(shù)“alg”，它會指明JWT簽名所采用的算法。JWT支持多種算法來進(jìn)行簽名，也可以不進(jìn)行簽名。通過修改alg參數(shù)為“none”，此時簽名為空，這就是生成了“不安全的JWT”。
圖4 修改JWT的header頭部alg參數(shù)為“none”
圖5 修改前后的JWT
4.3 Brute-forcing secret keys -- 暴力破解密鑰
某些簽名算法，會使用一個字符串作為密鑰，而當(dāng)我們知道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 對象。正常時候服務(wù)器應(yīng)該要對其進(jìn)行限制，只能使用特定的公鑰白名單進(jìn)行簽名驗證。然而，如果出現(xiàn)配置失誤或疏忽，某些服務(wù)器可能會誤用JWK參數(shù)內(nèi)嵌的任何密鑰進(jìn)行簽名驗證操作。這就意味著，如果出現(xiàn)jwk配置失誤，攻擊者就可以通過RSA私鑰對已經(jīng)修改過的payload進(jìn)行簽名，并將RSA公鑰嵌入到JWK頭部，從而繞過簽名認(rèn)證。
? kid（Key ID）：即密鑰標(biāo)識符，被用作提供一個獨特的標(biāo)識，當(dāng)存在有多個密鑰的情況下，服務(wù)器就會通過此ID來準(zhǔn)確識別應(yīng)用于驗證的正確密鑰。但是，系統(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)過嚴(yán)格的過濾和驗證，就可能導(dǎo)致潛在的安全漏洞。
上述用戶可操控的參數(shù)用于指示接收方服務(wù)器在進(jìn)行簽名驗證時所需的密鑰信息，如果攻擊者修改這些可控參數(shù)可能會導(dǎo)致任意文件讀取、SQL注入等安全問題。
Part 05●? JWT安全防護(hù)?
根據(jù)上述安全漏洞，總結(jié)有以下防護(hù)措施：
1.不要在token中設(shè)置任何敏感信息，同時不要將payload中的時間戳失效設(shè)定太長，防止被盜的token長時間被濫用。
2.使用最新的庫來處理JWT，并確保完全理解它的工作原理以及任何安全隱患。
3.在服務(wù)器端，限制JWT頭部中“alg”參數(shù)的值只能使用特定的、安全的算法。禁止使用不安全的算法，如"none"算法。
4.針對JWT頭部進(jìn)行嚴(yán)格的白名單設(shè)置，只允許特定的參數(shù)值，拒絕任何不在白名單內(nèi)的參數(shù)值。
Part 06●? 總結(jié)?
已簽名的JWT具有標(biāo)頭、負(fù)載和簽名三部分，每個都在確保JWT可用于安全地存儲和傳輸關(guān)鍵信息方面發(fā)揮著至關(guān)重要的身份驗證作用。了解這三個組件對于正確使用JWT至關(guān)重要，同時由于簽名的重要性，我們有必要對JWT安全進(jìn)行了解并做好防護(hù)，從而做到防范于未然。
下載ECAD模型
