OAuth 是否“状态"?减轻任何真正危险的攻击? [英] Does OAuth "state" mitigate any genuinely dangerous attacks?

问题描述

我使用 OAuth Playground 来更好地理解 OpenID Connect 流程，它有这个说一下验证 state 参数:

I was using the OAuth Playground to better understand the OpenID Connect flow, and it has this to say about verifying the state parameter:

用户被重定向回客户端，您会注意到 URL 中有几个额外的查询参数:

The user was redirected back to the client, and you'll notice a few additional query parameters in the URL:

?state=7ymOWcwttpCfDNcs&code=Tav2TPBjSNvR8aowA3oe

由于攻击者可以制作与此类似的 GET 请求，因此攻击者可以向您的应用程序提供垃圾授权代码.您需要首先验证 state 参数是否与此用户的会话匹配，以便您可以确定您发起了请求，并且只发送了用于您的客户的授权代码.

Since it's possible for an attacker to craft a GET request that looks similar to this, an attacker could provide your application with junk authorization codes. You need to first verify that the state parameter matches this user's session so that you can be sure you initiated the request, and are only sending an authorization code that was intended for your client.

基于这种解释，似乎我们使用 state 参数阻止的唯一攻击"是攻击者向我们的应用程序发送错误代码，我们针对授权服务器检查错误代码，然后被拒绝.

Based on this explanation, it seems that the only "attack" we are preventing with the state parameter is one in which the attacker sends our application bad codes, we check the bad code against the authorization server, and we get rejected.

但这实际上并没有给攻击者带来太多伤害或伤害我们太多:我们只是向身份验证服务器发出一些额外的 http 请求，如果我们立即拒绝该请求，我们就不需要这些请求当状态不匹配时我们的服务器.

But afaict this doesn't actually get the attacker much or harm us much: We're just making some extra http requests to the auth server that we wouldn't have needed to make if we'd rejected the request immediately on our server when the state didn't match.

我的问题是:我的理解是否正确，还是我错过了state 正在阻止的更重要的攻击向量?

My question is: Is my understanding correct, or am I missing a more consequential attack vector that state is preventing?

推荐答案

我的问题是:我的理解是否正确

没有

为什么?

OAuth 2.0 规范提供了一个可靠的例子，说明可以用伪造的重定向做什么.首先，来自定义，

The OAuth 2.0 specification provide a solid example on what can be done with forged redirects. First, from the definition,

状态:推荐.客户端用于维护的不透明值请求和回调之间的状态.

state : RECOMMENDED. An opaque value used by the client to maintain state between the request and callback.

State 有助于将授权请求与授权响应相关联，并防止跨站点请求伪造.认为您的客户端有一个接收响应的重定向 URL.如果恶意方使用有效的访问令牌(使用隐式流时)重定向到您的客户端会怎样.如果此访问令牌允许访问属于您使用的同一资源服务器中的恶意方的有效资源，该怎么办?OAuth 2.0 (RFC6749) 提供了一个关于银行帐户详细信息的可靠示例.

State helps to associate authorization request with authorization response and prevent cross-site request forgery. Think that your client have a redirect URL which receive the response. What if malicious party redirect with a valid access token (when using Implicit flow) to your client. And what if this access token allow access to a valid resource belongs to malicious party in the same resource server you use. OAuth 2.0 (RFC6749) give a solid example for this on bank account details.

针对客户端重定向 URI 的 CSRF 攻击允许攻击者注入自己的授权码或访问令牌，这可以导致客户端使用与关联的访问令牌攻击者的受保护资源而不是受害者的(例如，保存受害者的银行帐户信息到受保护的资源由攻击者控制).

A CSRF attack against the client's redirection URI allows an attacker to inject its own authorization code or access token, which can result in the client using an access token associated with the attacker's protected resources rather than the victim's (e.g., save the victim's bank account information to a protected resource controlled by the attacker).

State 参数可防止此类攻击.此外，我欢迎您阅读RFC6819 - 威胁模型和安全注意事项.它包括许多攻击向量和在采用 OAuth 2.0 时可能采取的反措施.它包括一个关于CSRF 攻击和状态使用的部分.

State parameter prevents this type of attacks. Furthermore, I welcome you to go through RFC6819 - Threat Model and Security Considerations. It include many attack vectors and counter measurements one could take when adopting OAuth 2.0. It include a section about CSRF attack and usage of state as well.

这篇关于OAuth 是否“状态"?减轻任何真正危险的攻击?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！