OAuth2.0进阶

Wizard Rubick

于 2024-09-30 06:20:35 发布

阅读量647

点赞数 9

文章标签： OAuth2.0

本文链接：https://blog.csdn.net/KHZ_222/article/details/142647362

版权

请求授权页面时的state防止的是什么跨站请求伪造

看起来分两种：

A CSRF attack against the client’s redirection URI allows an attacker to inject its own authorization code or access token
防止的是在redirectURI跨站请求伪造，攻击者把客户端与自己的code，refreshToken注入进而关联起来。
The client MUST implement CSRF protection for its redirection URI
重定向URI可能重定向到前端域名，也能重定向到后端接口，从CSRF角度来说，这里影响是什么？
A CSRF attack against the authorization server’s authorization endpoint can result in an attacker obtaining end-user authorization for a malicious client without involving or alerting the end-user.
基于认证端点的CSRF攻击，从恶意客户端中拿走受害者的凭证，认证服务器也要防止CSRF，避免在用户不知情的情况下授权

分析CSRF攻击的防护措施与原理时，需要明白CSRF攻击是指是用户主动或不经意在恶意UI级应用（如此处指具体恶意网站，而不是恶意浏览器）触发了本应该是正常网站发出的请求，导致授权错误；跨站请求伪造，就是在非期望的网站发出了正常网站的请求，此时不要考虑到什么code窃取，脚本代替发送等概念严重混乱的情况。 所以授权发起端要发出 state并且检查重定向回来时带的state是不是自己发出去的。

这里有个攻击示例，但是这机翻文章看不明白https://anquan.baidu.com/article/958?utm_source=pocket_saves，那就看原文 https://lokeshdlk77.medium.com/csrf-email-confirmation-vulnerability-for-gmail-g-suite-in-facebook-5ab551a0a526：
Facebook有个通过GMail来创建facebook账号的功能，就是通过OAuth来实现的：如果你在浏览器已经登录Google账号，那么就能一键绑定。问题在于一个授权链接到处都能用，即state参数是可重复使用的，即使在其他浏览器外也能用；同时作者也发现了Facebook有个一键登录功能，于是构造iframe，黑客登录自己的facebook账号，再隐藏授权链接诱导点击，此时需要受害者的google账号是登录的，这样黑客就把自己的facebook账号绑定到了受害者的google账号上，完事后登出facebook账号，一切如无事发生。
RFC对潜在CSRF的解释 https://www.rfc-editor.org/rfc/rfc6749#section-10.12

PKCE协议

这个协议简单来说就是在发起鉴权请求时，先发密文（可由明文计算出），后面code换token时，再发明文，以此来确认发起授权的和换token的是同一个客户端，防止CSRF和code注入攻击
协议解释：https://blog.csdn.net/weixin_43333483/article/details/126256938?utm_source=pocket_saves
解释2：这个人就乱说了，他说用了PKCE就不需要client_secret https://juejin.cn/post/7037403929063194638?utm_source=pocket_saves
而我们实践中，在用code换取token时也要传code，这相当于是采用明文的code_challenge，实际OAuth2.0没要求在换token时带state

用PKCE还需要client_secret吗？需要的，掘金文章那个人在乱说

这里就摆明了：https://oauth.net/2/pkce/

PKCE (RFC 7636) is an extension to the Authorization Code flow to prevent CSRF and authorization code injection attacks.PKCE is not a form of client authentication, and PKCE is not a replacement for a client secret or other client authentication. PKCE is recommended even if a client is using a client secret or other form of client authentication like private_key_jwt.

RFC https://www.rfc-editor.org/rfc/rfc7636

有PKCE了还需要state吗？

如果不知道，那就"抄"： AWS的登录链接

https://signin.aws.amazon.com/signin?
redirect_uri=https://us-east-1.console.aws.amazon.com/billing/home?region=ap-southeast-1
&state=hashArgs%23%2Fbills&isauthcode=true
&client_id=arn:aws:iam::8888888888:user/portal-aws-auth
&forceMobileApp=0
&code_challenge=MWS_YzKH0m7imyomWgNjU2GKGm5tlTNOHZCz0ZWoyuU
&code_challenge_method=SHA-256

都是需要的 state保护的是发起授权接受code这个流程，让客户端保证授权请求时它发起的，code_challenge保护的是，发起授权使用code这一流程，让服务端确认获取code和使用code的是同一个客户端。
参考链接：https://security.stackexchange.com/questions/214980/does-pkce-replace-state-in-the-authorization-code-oauth-flow?utm_source=pocket_saves