破坏基于 JWT 的服务器是否更具破坏性? [英] Are breaches of JWT-based servers more damaging?

问题描述

更新:我已经结束了对这个问题的研究，并发布了一篇长篇博文解释我的发现:JWT 的潜意识漏洞.我解释了使用 JWT 进行本地身份验证的巨大推动力如何遗漏了一个关键细节:必须保护签名密钥.我还解释说，除非您愿意竭尽全力保护密钥，否则最好通过 Oauth 委派身份验证或使用传统会话 ID.

UPDATE: I have concluded my research on this problem and posted a lengthy blog entry explaining my findings: The Unspoken Vulnerability of JWTs. I explain how the big push to use JWTs for local authentication is leaving out one crucial detail: that the signing key must be protected. I also explain that unless you're willing to go to great lengths to protect the keys, you're better off either delegating authentication via Oauth or using traditional session IDs.

我已经看到很多关于 JSON Web 令牌安全性的讨论——重放、撤销、数据透明度、令牌指定的算法、令牌加密、XSS、CSRF——但我没有看到任何关于由依赖于签名密钥.

I have seen much discussion of the security of JSON Web Tokens -- replay, revocation, data transparency, token-specified alg, token encryption, XSS, CSRF -- but I've not seen any assessment of the risk imposed by relying on a signing key.

如果有人破坏了服务器并获得了 JWT 签名密钥，在我看来，此人随后可以使用该密钥来伪造未过期的 JWT 并秘密获得访问权限.当然，服务器可以在每个请求上查找每个 JWT 以确认其有效性，但服务器完全使用 JWT，因此它们不必这样做.服务器可以确认 IP 地址，但如果 JWT 不可信，这也涉及查找，显然这样做会排除可靠的移动访问.

If someone breaches a server and acquires a JWT signing key, it seems to me that this person could thereafter use the key to forge unexpired JWTs and secretly gain access. Of course, a server could look up each JWT on each request to confirm its validity, but servers use JWTs exactly so they don't have to do this. The server could confirm the IP address, but that also involves a lookup if the JWT is not to be trusted, and apparently doing this precludes reliable mobile access anyway.

将此与基于会话 ID 的服务器入侵进行对比.如果此服务器正在对密码进行哈希处理，则攻击者必须在会话 ID 过期之前为每个用户单独获取和使用会话 ID.如果服务器只存储会话 ID 的哈希值，攻击者将不得不写入服务器以确保访问.无论如何，攻击者的优势似乎较小.

Contrast this with a breach of a server based on session IDs. If this server is hashing passwords, the attacker would have to snag and use a session ID separately for each user before it expires. If the server were only storing hashes of the session IDs, the attacker would have to write to the server to ensure access. Regardless, it seems that the attacker is less advantaged.

我发现一种使用 JWT 的架构没有这个缺点.反向代理位于外部不受信任的客户端和内部微服务的后端集合之间，这里由北欧 API 描述.客户端从授权服务器获取不透明令牌，并使用该令牌与服务器应用程序通信以处理所有请求.对于每个请求，代理将不透明令牌转换为 JWT 并缓存它们的关联.外部世界从不提供 JWT，从而限制了窃取密钥造成的损害(因为代理转到身份验证服务器以确认不透明的令牌).但是，这种方法需要取消引用每个客户端令牌，就像会话 ID 需要取消引用每个请求一样，从而消除了 JWT 对客户端请求的好处.在这种情况下，JWT 只允许服务在它们之间传递用户数据，而不必完全信任彼此——但我仍在尝试理解这种方法的价值.

I have found one architecture that uses JWTs without this disadvantage. A reverse proxy sits between untrusted clients externally and a backend collection of microservices internally, described here by Nordic APIs. A client acquires an opaque token from an authorization server and uses that token to communicate with the server app for all requests. For each request, the proxy translates the opaque token into a JWT and caches their association. The external world never provides JWTs, limiting the damage wrought by stealing keys (because the proxy goes to the authentication server to confirm the opaque tokens). However, this approach requires dereferencing each client token just as session IDs require per-request dereferencing, eliminating the benefit of JWTs for client requests. In this case, JWTs just allow services to pass user data among themselves without having to fully trust one another -- but I'm still trying to understand the value of the approach.

我的担忧似乎只适用于不受信任的客户端使用 JWT 作为身份验证令牌.然而，包括 Google API 在内的许多知名 API 都在使用 JWT.我错过了什么?也许服务器违规很少是只读的?有没有办法降低风险?

My concern appears to apply only to the use of JWTs as authentication tokens by untrusted clients. Yet JWTs are used by a number of high-profile APIs, including Google APIs. What am I missing? Maybe server breaches are rarely read-only? Are there ways to mitigate the risk?

推荐答案

我相信你想错了.不要误会我的意思，您正在考虑安全性很好，但是您在服务器端仔细检查事物、添加违反无状态会话目标的额外检查等方面的处理方式似乎是一致的一条通往自己理智尽头的单行道.

I believe you're thinking about this the wrong way. Don't get me wrong, it's great you're considering security, however the way you're approaching it in regards to double checking things server-side, adding additional checks that defeat the objective of stateless sessions, etc, appear to be along a one way street towards the end of your own sanity.

总结两种标准方法:

• JWT 是无会话状态对象，由服务器端持有的密钥进行 MAC 化.

• JWTs are sessionless state objects, MAC'd by a secret key held server side.

传统的会话标识符要么存储在内存中，要么存储在服务器端的数据库中，正如您所说，通常会进行哈希处理，以防止在数据泄露时会话被劫持.

Traditional Session Identifiers are stored either in memory or in a database server-side, and as you say are often hashed to prevent sessions from being hijacked should this data be leaked.

您也是对的，攻击者通常更难以实现写访问.原因是数据库数据通常是通过 SQL 注入 漏洞从目标系统中提取的.这几乎总是提供对数据的读取访问权限，但使用这种技术插入数据更加困难，尽管并非不可能(某些漏洞实际上会导致目标机器的完全 root 访问权限).

You are also right that write access is often harder for an attacker to achieve. The reason is that database data is often extracted from a target system via a SQL injection exploit. This almost always provides read access to data, but it is harder to insert data using this technique, although not impossible (some exploits actually result in full root access of the target machine being achieved).

如果您存在允许在使用 JWT 时访问密钥的漏洞，或者存在允许在使用会话标识符时写入数据库表的漏洞，那么游戏就结束了 - 您会受到威胁，因为您的用户会话可能被劫持.

If you have a vulnerability that allows access to the key when using JWTs or one that allows database tables to be written to when using session identifiers, then it's game over - you are compromised because your user sessions can be hijacked.

所以不一定更多破坏，这完全取决于漏洞的深度.

So not more damaging necessarily, it all depends on the depth of the vulnerability.

仔细检查您的 JWT 密钥的安全性是否符合您的风险偏好:

Double check that the security of your JWT keys align with your risk appetite:

• 它们存储在哪里?
• 谁有权访问?
• 备份存储在哪里?
• 您的应用的预生产和生产部署是否使用了不同的密钥?

缓解方法与任何网络应用程序的良好实践一样:

The ways to mitigate is as good practise dictates with any web app:

• 定期安全评估和渗透测试.
• 安全代码审查.
• 入侵检测和防御 (IDS/IPS).
• WAF.

这些将帮助您评估您的真正风险所在.如此专注于应用程序的一个特定方面是没有意义的，因为这会导致忽略其他方面，这很可能会给您的业务模型带来更高的风险.JWT 并不危险，并且不一定比系统的其他组件具有更大的风险，但是如果您选择使用它们，则应确保正确使用它们.无论您是否是应用程序的特定上下文，这在一般意义上很难评估，所以我希望我的回答能够引导您朝着正确的方向前进.

These will help you evaluate where your real risks lie. It is pointless concentrating on one particular aspect of your application so much, because this will lead to the neglect of others, which may well be higher risk to your business model. JWTs aren't dangerous and have no more risk than other components of your system necessarily, however if you've chosen to use them you should make sure you're using them appropriately. Whether you are or not comes down to the particular context of your application and that is difficult to assess in a general sense, so I hope my answer guides you in the right direction.

这篇关于破坏基于 JWT 的服务器是否更具破坏性?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！