前不久研究websocket時發現port-swigger出了新的靶場,一看,發現是關於jwt安全的,剛好來總結回憶一下
JWT簡介
Json web token (JWT),是爲了在網絡應用環境間傳遞聲明而執行的一種基於JSON的開放標準(RFC 7519)
RFC 7519:https://datatracker.ietf.org/doc/html/rfc7519
他定義了一種緊湊且自包含的方式,用於在各方之間安全地傳輸信息作爲 JSON 對象,特別適用於分佈式站點的單點登錄(SSO)場景
JWT與cookie/session的異同
● JWT與cookie/session一樣,都是作用於前後端認證
● cookie/session:後端有個session,前端有個cookie,這樣的基於session的認證會要求服務端不斷存儲用戶登錄信息,而隨着不同客戶端用戶的增加,獨立的服務器會逐漸無法承載更多的用戶,導致其服務器的壓力十分巨大,且cookie一旦被竊取還可能造成CSRF攻擊
● JWT:當我們把前後端分離開來,後端不再有session,當不再需要保存session文件,這就降低了服務端的負擔,而我們就可以利用JWT這麼一個基於token的鑑權認證,而基於token認證機制的應用就不需要去考慮用戶在哪個服務器登錄,客戶端也可以將通過服務器認證後的json對象存儲起來,下次訪問時連同請求內容一同發送即可
JWT格式
JWT由Header、Payload、Signature
組成
Header.Payload.Signature
Header
{"alg":"加密算法","typ":"JWT"}
Payload
iss: The issuer of the token sub: The subject of the token aud: The audience of the token exp: JWT expiration time defined in Unix time nbf: "Not before" time that identifies the time before which the JWT must not be accepted for processing iat: "Issued at" time, in Unix time, at which the token was issued jti: JWT ID claim provides a unique identifier for the JWT //可以自定義其它字段
Signature
Signature = HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),"secret")
secret保存在後端,就是來解析確定驗證的key
JWT&JWS&JWE
● JWS,即JSON Web Signature,只是 JWT 的一種實現
● JWE,即JSON Web Encryption,也只是 JWT 的一種實現
潛在漏洞
● 簽名未校驗
● 算法被篡改
● 敏感信息泄露
● 加密算法不安全
● 僞造密鑰(CVE-2018-0114)
【----幫助網安學習,以下所有學習資料免費領!加vx:yj009991,備註 “博客園” 獲取!】
① 網安學習成長路徑思維導圖
② 60+網安經典常用工具包
③ 100+SRC漏洞分析報告
④ 150+網安攻防實戰技術電子書
⑤ 最權威CISSP 認證考試指南+題庫
⑥ 超1800頁CTF實戰技巧手冊
⑦ 最新網安大廠面試題合集(含答案)
⑧ APP客戶端安全檢測指南(安卓+IOS)
JWT安全問題
未對簽名進行驗證
我們前面說過,JWT存在一個Signature 簽名,如若沒對簽名進行認證,就可能存在越權情況
靶場
Lab: JWT authentication bypass via unverified signature
解法
To solve the lab, modify your session token to gain access to the admin panel at /admin, then delete the user carlos.
我們需要把carlos刪掉,而這就需要登錄管理員賬號,但是又沒有給管理員的賬號,只有一個普通用戶,那我們就要想辦法提升權限
先抓包
觀察確定爲JWT,將payload處字符base64解碼得
把sub的wiener修改爲administrator,重新傳參
成功越權,然後就是刪除用戶即可
未對加密算法進行強驗證
回顧一下Header的構成
{"alg":"加密算法","typ":"JWT"}
這裏alg可以說明加密算法,但如果對該設置不進行強認證也會造成越權問題
我們可以把加密算法設成none來進行驗證繞過
靶場
Lab: JWT authentication bypass via flawed signature verification
解法
先和上題一致,將sub內容修改爲administrator,然後發現還是沒能成爲管理員,接着修改header的alg爲none,把後續的Signature刪除,因爲Signature是通過alg算法生成的,既然alg都爲none了,那Signature也應該爲空了
成功變成管理員
然後就是正常刪除用戶就行
繞過弱簽名密鑰進行越權
Signature = HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),"secret")
我們知道,簽名存在一個secret密鑰,這個一般都會保存在後端,別人無法查看,但是類同於弱口令,一旦這個密鑰不復雜就有可能被爆破,gayhub上也有很多爆破的字典
靶場
Lab: JWT authentication bypass via weak signing key
解法
還是一樣先抓包得到JWT
然後用到hashcat來進行爆破,kali自帶
hashcat -a 0 -m 16500 <YOUR-JWT> /path/to/jwt.secrets.list
爆破得到secret
爲secret1
然後前往jwt.io生成我們需要的的jwt,把sub和secret進行修改
重新傳包,成功
JWT標頭注入
與很多注入一樣,JWT標頭注入也可大致分爲兩種情況,一是與數據庫連接,搭配sql注入使用,一是不與數據庫連接,單獨進行越權操作
通過jwk參數注入自簽名的JWT
還記得我們說過的JWS嗎
JWS,即JSON Web Signature,只是 JWT 的一種實現
我們就可以通過JWK注入JWT,形成JWS
那什麼是JWK呢
JWK 英文全稱爲 JSON Web Key,是一個JSON對象,表示一個加密的密鑰,他不同於alg屬性,JWK是可選的,以下就是一個示例
{ "kid": "ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG", "typ": "JWT", "alg": "RS256", "jwk": { "kty": "RSA", "e": "AQAB", "kid": "ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG", "n": "yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9m" } }
在理想情況下,服務器應該是隻使用公鑰白名單來驗證JWT簽名的,但對於一些相關配置錯誤的服務器會用JWK參數中嵌入的任何密鑰進行驗證,攻擊者就可以利用這一行爲,用自己的RSA私鑰對修改過的JWT進行簽名,然後在JWK頭部中嵌入對應的公鑰進行越權操作
靶場
Lab: JWT authentication bypass via jwk header injection
解法
需要先安裝一個插件,方便後續的操作
然後正常抓包,將sub內容修改爲administrator
然後切換到JWT Editor Keys選項new一個RSA Key
我是已經生成的了,然後保存後回到Repeater選擇Embedded JWK攻擊
成功越權
JWT Editor
通過jku參數注入自簽名的JWT
有些服務器並不會直接使用JWK頭部參數來嵌入公鑰,而是使用JKU(JWK Set URL)來引用一個包含了密鑰的JWK Set,我們就可以藉此來構造一個密鑰從而實現越權操作
靶場
Lab: JWT authentication bypass via jku header injection
解法
先還是正常抓包修改sub內容,然後去到JWT Editor Keys生成一個RSA密鑰,或者用上一道題目的也行,然後複製公鑰
然後加上key頭
{ "keys": [ ] }
保存到exploit的body中
然後將kid修改成自己生成的JWK中的kid值,將jku的值改爲exploit,使其導入
然後回到點擊下面的sign,選擇Don’t modify header 模式,Sign 即可
成功越權
通過kid參數注入自簽名的JWT
服務器可能會使用多個加密密鑰來爲不同類型的數據進行簽名,出於這個原因,在JWT頭部有時會包含一個kid參數,以避免服務器驗證簽名時出現錯誤,而在JWT規範中並沒有對這個kid定義具體的結構,他僅僅是開發人員任意選擇的一個字符串,可能只是一個指向數據庫中的一個特定條目,甚至只是一個文件的名稱也有可能
而安全問題就出現在這裏,一旦這個參數受到目錄遍歷影響,就易被攻擊者使用服務器任意文件的文件名作爲驗證密鑰形成攻擊鏈
靶場
Lab: JWT authentication bypass via kid header path traversal
解法
先生成一個Symmetric Key
,也就是對稱密鑰,並將 k 的值修改爲 AA==
即爲null
然後抓包修改kid值和sub進行目錄遍歷
/dev/null是linux中的“黑洞”,代表空設備文件
/dev/null文件名與AA==一致都爲null,對稱密鑰,應該可以成功繞過
然後回到repeater點擊sign選擇OCT8 的密鑰攻擊
成功越權
其他有趣的JWT頭部參數
● cty(內容類型)如果已經找到了繞過簽名驗證的方法,可以嘗試注入cty參數,將內容類型改爲text/xml或application/x-java-serialized-object,這有可能爲XXE和反序列化攻擊提供新的向量。
● x5c(X.509證書鏈)類似於上面討論的jwk頭部注入攻擊,由於此標頭參數可用於注入自簽名證書,且由於 X.509 格式及其擴展的複雜性,引入這些證書時也有可能引入漏洞,可見CVE-2017-2800 和 CVE-2018-2633
JWT算法混淆
● 即使服務器的密碼是攻擊者無法破解的複雜密碼,但是由於JWT庫的一些原生安全問題,攻擊者可能會以開發者想不到的算法來僞造有效的JWT
● portswigges裏也有相關靶場,目前尚未完全理解,先挖個坑,後續補上
JWT攻擊的防禦
我們可以看到,JWT攻擊千奇百怪,但是萬變不離其宗,主要的潛在漏洞爲
● 簽名未校驗
● 算法被篡改
● 敏感信息泄露
● 加密算法不安全
● 僞造密鑰
我們也可圍繞這些進行JWT攻擊進行防禦
● 使用最新的 JWT 庫,雖然最新版本的穩定性有待商榷,但是安全性都是較高的
● 對 jku 標頭進行嚴格的白名單設置
● 確保 kid 標頭不容易受到通過 header 參數進行目錄遍歷或 SQL 注入的攻擊
● 始終爲頒發的任何令牌設置一個到期日
● 儘可能避免通過URL參數發送令牌
● 提供aud聲明(或類似內容),以指定令牌的預期接收者,防止其應用在不同網站
● 讓頒發服務器能夠撤銷令牌
更多靶場實驗練習、網安學習資料,請點擊這裏>>搜索
複製