寫在前頭，總結向筆記類文章，內容有些不是我自己的，詳情見參考資料
0x00 什么是JWT
JWT全稱為: json web token
JWT通常用於實現前端和后端的解耦，同時，它還可以與Restful API一起使用，用於構建身份驗證機制
0x01 JWT的格式
JWT的數據分為三部分：頭部，有效載荷，簽名（圖來自freebuf一篇文章，具體找不到了）
通過base64編碼起來
使用點號進行划分，比如一個JWT如：
eyJraWQiOiJrZXlzLzNjM2MyZWExYzNmMTEzZjY0OWRjOTM4OWRkNzFiODUxIiwidHlwIjoiSldUIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJkdWJoZTEyMyJ9.XicP4pq_WIF2bAVtPmAlWIvAUad_eeBhDOQe2MXwHrE8a7930LlfQq1lFqBs0wLMhht6Z9BQXBRos9jvQ7eumEUFWFYKRZfu9POTOEE79wxNwTxGdHc5VidvrwiytkRMtGKIyhbv68duFPI68Qnzh0z0M7t5LkEDvNivfOrxdxwb7IQsAuenKzF67Z6UArbZE8odNZAA9IYaWHeh1b4OUG0OPM3saXYSG-Q1R5X_5nlWogHHYwy2kD9v4nk1BaQ5kHJIl8B3Nc77gVIIVvzI9N_klPcX5xsuw9SsUfr9d99kaKyMUSXxeiZVM-7os_dw3ttz2f-TJSNI0DYprHHLFw
1，頭部
eyJraWQiOiJrZXlzLzNjM2MyZWExYzNmMTEzZjY0OWRjOTM4OWRkNzFiODUxIiwidHlwIjoiSldUIiwiYWxnIjoiUlMyNTYifQ
解碼為：
{“kid”:”keys/3c3c2ea1c3f113f649dc9389dd71b851",”typ”:”JWT”,”alg”:”RS256"}
包括了typ類型，alg：簽名算法
2，有效載荷
eyJzdWIiOiJkdWJoZTEyMyJ9
有效載荷用來存儲用戶的數據，解碼之后為
{"sub":"dubhe123"}
3，簽名
XicP4pq_WIF2bAVtPmAlWIvAUad_eeBhDOQe2MXwHrE8a7930LlfQq1lFqBs0wLMhht6Z9BQXBRos9jvQ7eumEUFWFYKRZfu9POTOEE79wxNwTxGdHc5VidvrwiytkRMtGKIyhbv68duFPI68Qnzh0z0M7t5LkEDvNivfOrxdxwb7IQsAuenKzF67Z6UArbZE8odNZAA9IYaWHeh1b4OUG0OPM3saXYSG-Q1R5X_5nlWogHHYwy2kD9v4nk1BaQ5kHJIl8B3Nc77gVIIVvzI9N_klPcX5xsuw9SsUfr9d99kaKyMUSXxeiZVM-7os_dw3ttz2f-TJSNI0DYprHHLFw
由於頭部和有效載荷以明文形式存儲，因此，需要使用簽名來防止數據被篡改。
提供數據的相關函數使用的簽名算法通常是RS256（RSA非對稱加密和私鑰簽名）和HS256（HMAC SHA256對稱加密）算法。
如使用HS256的加密方式為：
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
0X02 如何攻擊JWT
1，敏感信息泄露
因為有效載荷是明文傳輸的，如果有效載荷存在敏感信息的話就會發生信息泄露
2，將簽名算法改為none
使用工具: JWTPyCrack
python jwtcrack.py -m generate -s {\"admin\":\"True\"}
3，未校驗簽名
直接替換數據，使用
https://jwt.io/#debugger
插入一些常見測試payload，如注入，xss等
4，爆破弱key
使用工具:JWTPyCrack ，只支持明文，有些時候可能還要考慮base64encode的情況，base64的情況，要自己編寫腳本
python jwtcrack.py -m blasting -s eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.keH6T3x1z7mmhKL1T3r9sQdAxxdzB6siemGMr_6ZOwU --kf 2.txt
除此之外，我們也可以用hashcat來爆破
爆破hahs少不了一個好的字典，而hashcat rules文件夾下其實有不少規則，我們也可以直接拿來用，生成字典：（b0b064.rule來源於Hob0Rules）
hashcat64.exe --stdout password.txt -r rules/hob064.rule -o pasword_new.txt --force
不想生成文件占磁盤，也可以直接用規則來爆破
hashcat64.exe -a 0 -m 16500 jwt_token jwt_key.txt -r rules/d3ad0ne.rule --force
當然也可以用掩碼方式，爆破出來的時間取決於key的長度和GPU的性能
0x03 拓展：accessToken與refreshToken問題
風險點：
未校驗access token和refresh token是否屬於同一個用戶，導致A用戶可使用自己的refresh token去刷新B用戶的access token，垂直越權
建議：
使用jwt令牌的最佳位置是服務器之間的通信。在普通的web應用程序中，最好使用普通的舊cookies。
例子:
webgoat 8 ，
使用A賬號的refresh token 和 過期B的access_token去刷新 B的access_token
0x04 實戰記錄
1，開源程序默認key未修改
某眾測廠商默認key直接偽造超級管理員進去
github標志，開源系統直接跟過去
有默認值，雖然作者再三提醒，但鑒於人的本質惰性，相信很多管理員都是不會去修改的，直接偽造超級管理員進去
2，accessToken與refreshToken問題
某廠商可用A用戶refreshToken刷新B用戶的access_token
假如獲取到B用戶的過期access_token，那么就可以用A的refresh_token去刷新了
B用戶的access_token與refresh_token
使用A用戶的refresh_token去刷新B用戶的access_token
正常B用戶的請求
替換之后的請求，成功請求
這里過期的access_token可以在搜索引擎搜到或者評論等信息泄漏
0x05 總結
簡單列舉了一下自己遇到的jwt兩個案例，筆記向文章沒啥好說的。
0x06 參考資料