OAuth2.0进阶

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

看起来分两种:

  1. 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角度来说,这里影响是什么?
  2. 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.****.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

进一步OIDC实现SSO
reidect_uri应该是到前端地址还是后端?

首先明确的是谁发起的authentication请求,就应该重定向到谁,我们实践中,为了让前端感知到账号已登出进行本地存储清理,所以是前端跳转发起SSO登录/authencation请求

上一篇:人口普查管理系统基于VUE+SpringBoot+Spring+SpringMVC+MyBatis开发设计与实现


下一篇:已解决:org.springframework.web.HttpMediaTypeNotAcceptableException-解决办法