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.
但是，这实际上并不会给攻击者带来太大的伤害或对我们造成很大的伤害:我们只是向auth服务器发出了一些额外的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屋！
