问题描述
我在公司中使用 identityserver3 的 OAuth2.0 进行 SSO，我无法理解 state 参数如何防止 CSRF.
I use OAuth2.0 of identityserver3 for SSO in company, I cannot understand how does the state parameter prevent the CSRF.
我复制了如下攻击流程:
1.Mallory 访问某个客户的网站并开始授权该客户使用 OAuth 访问某个服务提供商
1.Mallory visits some client's website and starts the process of authorizing that client to access some service provider using OAuth
2.客户端向服务提供者请求允许代表Mallory请求访问，被授予
2.The client asks the service provider for permission to request access on Mallory's behalf, which is granted
3.Mallory 被重定向到服务提供商的网站，她通常会在那里输入她的用户名/密码以授权访问
3.Mallory is redirected to the service provider's website, where she would normally enter her username/password in order to authorize access
4.相反，Mallory 会捕获/阻止此请求并保存其 URL(Callback Url)
4.Instead, Mallory traps/prevents this request and saves its URL(Callback Url)
5.现在，Mallory 以某种方式让 Alice 访问该 URL.如果 Alice 用她自己的账户登录到服务提供商，那么她的凭据将用于发布授权码
5.Now, Mallory somehow gets Alice to visit that URL. If Alice is logged-in to the service provider with her own account, then her credentials will be used to issue an authorization code
6.授权码交换访问令牌
6.The authorization code is exchanged for an access token
7.现在Mallory在客户端的账户被授权访问Alice在服务提供商的账户
7.Now Mallory's account on the client is authorized to access Alice's account on the service provider
我可以理解第 1 步到第 4 步.但是从第 5 步开始，我有些困惑.根据我的理解，第五步Alice在登录的时候访问Callback Url，然后服务端直接使用授权码访问OAuth服务提供者在后台获取openid和access token，然后Alice的浏览器就可以了用Mallory的账号和访问令牌执行登录.Mallory的浏览器有什么关系?你能详细解释一下吗?感谢您花时间阅读我的话！
I can understand step 1 to step 4. But from step 5 I got some confusion. Accordding to my understanding, in step 5 Alice visit the Callback Url when she is logged-in, and then the server just use the authorization code to access the OAuth service provider to get an openid and access token in backend, and then Alice's browser just executing login with Mallory's account and access token.What is the relationship with Mallory's browser? Could you explain it in detail please? Thank you for taking time to read my word!
推荐答案
我认为第 3 步和第 4 步不太正确.我已经编辑了您的示例以说明我认为攻击是如何工作的.
I think steps 3 and 4 are not quite right. I've edited your example to show how I think the attack works.
1.Mallory 访问某个客户的网站(例如 https://brilliantphotos.com)并开始授权该过程客户端使用 OAuth 访问某些服务提供者(例如 Acebook - 因为 Brialphotos.com 允许其用户将图片发布到他们的 Acebook 页面)
1.Mallory visits some client's website (e.g. https://brilliantphotos.com) and starts the process of authorizing that client to access some service provider using OAuth (e.g. Acebook - as brilliantphotos.com allows its users to post pictures to their Acebook page)
2.brilliantphotos.com 将 Mallory 的浏览器重定向到 Acebook 的授权服务器，请求在身份验证完成后重定向回自身.
2.brilliantphotos.com redirects Mallory's browser to Acebook's Authorisation Server requesting a redirect back to itself once auth is done.
3.Mallory 被重定向到授权服务器，在那里她输入她的 Acebook 用户名/密码以授权访问.
3.Mallory is redirected to the Authorisation Server, where she enters her Acebook username/password in order to authorize access.
4. 成功登录后，Mallory 会捕获/阻止后续的重定向请求并保存其 URL(带有与 Mallory 相关的授权码的回调 URL)例如
4.After successful login, Mallory traps/prevents the subsequent redirect request and saves its URL(Callback Url with an auth code related to Mallory) e.g.
https://brilliantphotos.com/exchangecodefortoken?code=malloryscode
5.现在，Mallory 以某种方式让 Alice 访问该 URL(可能作为论坛帖子上的链接...)注意，Alice 可能已经使用她自己的帐户登录了 brightphotos.com.
5.Now, Mallory somehow gets Alice to visit that URL (maybe as a link on a forum post...) note that Alice may already be logged-in to brilliantphotos.com with her own account.
6.Alice 点击了brilliantphotos.com 的链接，授权码被交换为访问令牌(访问顽皮的Mallory 的帐户).如果 Alice 已登录，那么 Brimblephotos.com 可以将 Alice 的帐户与新生成的访问令牌相关联.
6.Alice clicks the link to brilliantphotos.com and the authorization code is exchanged for an access token (access to naughty Mallory's account). If Alice is logged in then brilliantphotos.com could conceivably associate Alice's account with the newly minted access token.
7.现在，如果 Alice 继续使用 Brialtphotos.com 网站，客户可能会无意中将图片发布到服务提供商 (Acebook) 上的 Mallory 帐户.
7.Now if Alice continues to use the brilliantphotos.com website, the client may inadvertently be posting pictures to Mallory's account on the service provider (Acebook).
如果一个状态参数是由brilliantphotos.com 维护的，那么Mallory 的状态代码将绑定到她的浏览器而不是Alice 的浏览器.因此，当 Alice 单击恶意 URL 时，brilliantphotos.com 将无法将状态代码与 Alice 的浏览器会话相关联.
If a state parameter was maintained by brilliantphotos.com then Mallory's state code would be bound to her browser but not Alice's. Therefore brilliantphotos.com would not be able to correlate the state code with Alice's browser session when Alice clicks on the malicious URL.
这篇关于在 OAuth2.0 中没有状态参数的 CSRF 如何工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！