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

问题描述

更新:我已经完成了有关此问题的研究，并发表了一篇冗长的博客文章，解释了我的发现:

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-但我没有看到对由JSON令牌带来的风险的任何评估依靠签名密钥.

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的哈希，则攻击者将不得不向服务器写入内容以确保访问权限.无论如何，攻击者的优势似乎较少.

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用作身份验证令牌的情况.然而，许多知名的API使用了JWT，包括Google API.我想念什么?也许服务器违规很少是只读的?有减轻风险的方法吗?

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注入漏洞从目标系统中提取的.这几乎总是提供对数据的读取访问权限，但是使用这种技术很难插入数据，尽管并非没有可能(某些漏洞实际上导致实现了对目标计算机的完全根访问).

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.

因此不一定 more 会造成破坏，这完全取决于漏洞的深度.

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:

• 它们存储在哪里?
• 谁可以访问?
• 备份存储在哪里?
• 应用的预生产和生产部署中使用了不同的密钥吗?

减轻风险的方法是任何Web应用程序都要求的良好做法:

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屋！