入侵JSON Web令牌(JWT)

攻击者如何伪造令牌并以其他人身份登录

JSON Web令牌是一种在商业应用程序中广泛使用的访问令牌。它们基于JSON格式,并包含令牌签名以确保令牌的完整性。

今天,我们将讨论使用JSON Web令牌(通常是基于签名的令牌)的安全隐患,以及攻击者如何利用它们绕过访问控制。

JSON Web令牌如何工作?

JSON Web令牌包含三个组件:标头,payload和签名。

标头

JSON Web令牌的标头部分标识用于生成签名的算法。它是JSON Blob的base64编码的字符串,如下所示:

{
 "alg" : "HS256",
 "typ" : "JWT"
}
base64 encoded string: eyBhbGcgOiBIUzI1NiwgdHlwIDogSldUIH0K

最常用的算法是HMAC和RSA算法。

payload

payload部分包含实际用于访问控制的信息。此部分在用于令牌之前也已进行base64编码。

{
 "user_name" : "admin",
}
base64 encoded string: eyB1c2VyX25hbWUgOiBhZG1pbiB9Cg

签名

签名是用于验证令牌未被篡改的部分。它是通过将标头与payload串联在一起,然后使用标头中指定的算法进行签名来计算的。

signature = HMAC-SHA256(base64Encode(header) + '.' + base64Encode(payload), secret_key)
// Let's just say the value of secret_key is "key".
-> signature function returns 4Hb/6ibbViPOzq9SJflsNGPWSk6B8F6EqVrkNjpXh7M

对于此特定令牌,字符串“ eyBhbGcgOiBIUzI1NiwgdHlwIDogSldUIH0K.eyB1c2VyX25hbWUgOiBhZG1pbiB9Cg”已用密钥“ key”的HS256算法签名。生成的字符串是4Hb / 6ibbViPOzq9SJflsNGPWSk6B8F6EqVrkNjpXh7M

完整的令牌

通过将每个部分(标头,有效负载和签名)与每个部分之间的“。”串联起来,可以获得完整的令牌。

eyBhbGcgOiBIUzI1NiwgdHlwIDogSldUIH0K.eyB1c2VyX25hbWUgOiBhZG1pbiB9Cg.4Hb / 6ibbViPOzq9SJflsNGPWSk6B8F6EqVrkNjpXh7M

绕过JSON Web令牌控件的方法

如果正确实现,JSON Web令牌将提供一种安全的方式来标识用户,因为payload部分中包含的数据无法被篡改。(由于用户无权访问密钥,因此她不能自己对令牌进行签名。)

但是,如果实施不正确,攻击者可以通过多种方式绕过安全机制并伪造任意令牌。

更改算法类型

攻击者可以伪造自己的令牌,其中一种方法是篡改标头的alg字段。如果应用程序不限制JWT中使用的算法类型,则攻击者可以指定要使用的算法,这可能会损害令牌的安全性。

  1. 无算法

JWT支持“无”算法。如果将alg字段设置为“ None”,则如果其标记部分设置为空,则任何令牌都将被视为有效。例如,以下令牌将被视为有效:

eyAiYWxnIiA6ICJOb25lIiwgInR5cCIgOiAiSldUIiB9Cg.eyB1c2VyX25hbWUgOiBhZG1pbiB9Cg。

它只是这两个Blob的base64编码版本,没有签名。

{
 "alg" : "None",
 "typ" : "JWT"
}
{
 "user" : "admin"
}

此功能最初用于调试目的。但是,如果没有在生产环境中将其关闭,则攻击者可以通过将alg字段设置为“ None” 来伪造他们想要的任何令牌。然后,他们可以使用伪造的令牌模拟网站上的任何人。

2. HMAC算法

用于JWT的两种最常见的算法类型是HMAC和RSA。使用HMAC,将使用密钥对令牌进行签名,然后使用相同的密钥进行验证。对于RSA,将首先使用私钥创建令牌,然后使用相应的公钥进行验证。

HMAC -> signed with a key, verified with the same key
RSA -> signed with a private key, verified with the corresponding public key

至关重要的是,将HMAC令牌的私钥和RSA令牌的私钥保密,因为它们用于签名令牌。

现在,我们假设有一个最初设计为使用RSA令牌的应用程序。令牌用私钥A签名,私钥A对公众保密。然后,使用任何人都可以使用的公钥B验证令牌。只要令牌始终被视为RSA令牌,就可以。

Token signed with key A -> Token verified with key B (RSA scenario)

现在,如果攻击者改变的ALG到HMAC,她可能通过与RSA公钥B.签署伪造的令牌能够创建有效令牌

这是因为最初使用RSA对令牌进行签名时,程序会使用RSA公钥B对其进行验证。当将签名算法切换为HMAC时,仍使用RSA公钥B来验证令牌,但是这次是使用令牌可以使用相同的公钥B签名(因为它使用的是HMAC)。

Token signed with key B -> Token verified with key B (HMAC scenario)

提供无效的签名

令牌的签名在到达应用程序后也可能永远不会被验证。这样,攻击者可以通过提供无效签名来简单地绕过安全机制。

暴力破解密钥

也有可能暴力破解用于签署JWT的密钥。

攻击者从一开始就有很多信息:她知道用于对令牌进行签名的算法,已签名的有效负载以及生成的签名。如果用于对令牌进行签名的密钥不够复杂,则她可能可以轻松地对其进行暴力破解。

泄漏密钥

如果攻击者无法蛮力破解密钥,则可以尝试泄漏秘密密钥。如果存在另一个允许攻击者读取存储密钥值的文件的漏洞(如目录遍历,XXE,SSRF),则攻击者可以窃取密钥并签署任意令牌。

KID操作

KID代表“Key ID”。它是JWT中的可选标头字段,它使开发人员可以指定用于验证令牌的密钥。KID参数的正确用法如下所示:

{
 "alg" : "HS256",
 "typ" : "JWT",
 "kid" : "1"       // use key number 1 to verify the token 
}

由于此字段是由用户控制的,因此攻击者可能会操纵它并导致危险的后果。

  1. 目录遍历

由于KID通常用于从文件系统中检索密钥文件,因此,如果在使用前未对其进行清理,则可能导致目录遍历攻击。在这种情况下,攻击者将能够在文件系统中指定任何文件作为用于验证令牌的密钥。

“kid”: “../../public/css/main.css” 
// use the publicly available file main.css to verify the token

例如,攻击者可以迫使应用程序使用公开可用的文件作为密钥,并使用该文件对HMAC令牌进行签名。

2. SQL注入

KID还可以用于从数据库检索密钥。在这种情况下,可能可以利用SQL注入来绕过JWT签名。

如果可以在KID参数上进行SQL注入,则攻击者可以使用该注入返回她想要的任何值。

“kid”: "aaaaaaa' UNION SELECT 'key';--"
// use the string "key" to verify the token

例如,上面的注入将使应用程序返回字符串“ key”(因为数据库中不存在名为“ aaaaaaa”的键)。然后将使用字符串“ key”作为密钥来验证令牌。

标头参数处理

除密钥ID外,JSON Web令牌标准还使开发人员能够通过URL指定密钥。

  1. JKU标头参数

JKU代表“ JWK设置URL”。它是一个可选的标头字段,用于指定指向一组用于验证令牌的密钥的URL。如果允许该字段,并且没有适当地限制该字段,则攻击者可以托管自己的密钥文件,并指定应用程序使用它来验证令牌。

jku URL -> file containing JWK set -> JWK used to verify the token

2. JWK标头参数

可选的JWK(JSON Web密钥)标头参数允许攻击者将用于验证令牌的密钥直接嵌入令牌中。

3. X5U,X5C URL操作

类似于jku和jwk标头,x5u和x5c标头参数允许攻击者指定用于验证令牌的公钥证书或证书链。x5u以URI形式指定信息,而x5c允许将证书值嵌入令牌中。

其他JWT安全问题

如果未正确实施,还会产生其他JWT问题。这些不是很常见,但是绝对值得关注:

信息泄漏

由于JSON Web令牌用于访问控制,因此它们通常包含有关用户的信息。

如果令牌未加密,则任何人都可以通过base64解码令牌并读取令牌的有效负载。因此,如果令牌包含敏感信息,则它可能成为信息泄漏的来源。JSON Web令牌的正确实现的签名部分可提供数据完整性,而不是机密性。

命令注入

有时,当KID参数直接传递到不安全的文件读取操作中时,可能会将命令注入代码流中。

可能允许这种类型的攻击的函数之一是Ruby open()函数。此功能使攻击者只需在KID文件名之后将命令添加到输入即可,即可执行系统命令:

“key_file” | whoami;

这只是一个例子。从理论上讲,每当应用程序将未经消毒的任何头文件参数传递给任何类似于system(),exec()等的函数时,就会发生此类漏洞。

最终,JSON Web令牌只是用户输入的另一种形式。他们应始终持怀疑态度并严格审查。


免责声明:这篇文章旨在引起人们对JSON Web令牌漏洞的关注,并帮助开发人员识别常见的陷阱。请不要使用此信息来攻击网站或冒充他人。

在没有测试权限的系统上尝试此操作是非法的。如果您发现了漏洞,请以负责任的方式向供应商披露。帮助使我们的互联网更安全。

翻译自:https://medium.com/swlh/hacking-json-web-tokens-jwts-9122efe91e4a

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 197,000评论 5 462
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 82,825评论 2 374
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 144,055评论 0 325
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,766评论 1 267
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,639评论 5 358
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,453评论 1 275
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,860评论 3 388
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,492评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,783评论 1 293
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,817评论 2 314
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,624评论 1 328
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,439评论 3 316
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,872评论 3 300
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,075评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,372评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,868评论 2 343
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,075评论 2 338

推荐阅读更多精彩内容