[xDef2012]OAuth Security
?Download as PPTX, PDF?
2 likes?1,504 views
oauth security,xDef2012,pnig0s,张天琪
![[xDef2012]OAuth Security](https://image.slidesharecdn.com/xdef2012oauthsecurity-121205070119-phpapp01/85/xDef2012-OAuth-Security-1-320.jpg)
![OAuth2.0：Authorization Code授
权流程
跳转到授权页面请求code[GET]
用户同意授权, 返回code[GET]
第三方利用code请求access token[POST]
以响应体的形式返回access token[POST]
第三方应用 授权服务器
https://api.weibo.com/oauth2/authorize?client_id=1
111111&redirect_uri=http://www.xxx.com/connect/si
naweibo?&response_type=code
https://api.weibo.com/oauth2/access_token?client_
id=1111111&client_secret=l29dgp03m2&grant_type
=authorization_code&redirect_uri=http://www.xxx.c
om/connect/sinaweibo?&code=1sk42lf0s
第三方应用](https://image.slidesharecdn.com/xdef2012oauthsecurity-121205070119-phpapp01/85/xDef2012-OAuth-Security-18-320.jpg)
[xDef2012]OAuth Security
- 3. About:Me 张天琪 ID:pnig0s(小P) Security Researcher @ Core Member @ xKungFoo2012 Speaker Focus On: Web安全研究 核心产物后台引擎研发 Fond Of: 渗透测试 大数据分析处理
- 5. 一，翱础鲍罢贬那点事儿
- 7. 二，翱础鲍罢贬1.0&补尘辫;厂贰颁鲍搁滨罢驰 ISSUE
- 8. OAuth1.0 授权流程 第三方应用 开放平台 用户 请求未授权request 创建request token及密 token 钥 重定向至授权页，询问 用户同意或取消授权 用户是否授权 使用授权后req token请 创建并返回access 求access token token及密钥 使用access token获取 用户信息
- 9. OAuth1.0安全问题 Session Fixation Attack(会话固话攻击)： 由于1.0版本中没有对oauth_callback进行检查和限制，也没有任何机制保证 整个授权流程只由一个人完成，因此造成了该安全问题，导致攻击者可以访 问目标的用户资源。 记录oauth_token，并 使用之前记录的 攻击者启动授权 oauth_token继续授权 将此时URL诱骗目标 流程 访问 并访问受害者资源 受害者访问并 受害者被重定 同意授权 向到其他位置 诱骗URL：http://provider/auth/oauth_token=123456 &oauth_callback=http://evil.com/ 攻击者伪造URL：http://consumer/callback/oauth_token=123456 关联案例： WooYun-2010-00781《Sina 微博OAuth 存在session fixation attack漏洞 》
- 10. OAuth1.0安全问题 ? OAuth1.0a版本中已经将此问题修复： ? oauth_callback在请求未授权request token时即传递 给平台方并参与签名计算，从而避免攻击者篡改 oauth_callback回调地址。 ? 平台方获得用户授权后重定向用户到第三方应用时， 返回oauth_verifier，它会被用在第三方申请Access Token的过程中，是一个随机的无法猜测的值。
- 11. 叁，翱础鲍罢贬2.0&补尘辫;厂贰颁鲍搁滨罢驰 ISSUE
- 12. OAuth2.0 OAuth2.0提供了多种授权流程： ? Authorization Code授权:适用于有Server端配合的应用 ? Implicit Grant授权:适用于无Server端配合的应用 ? Resource Owner Password Credentials授权:使用用户名密码进行授权 ? 此外还有一种Refresh Token获取Access Token的方式 OAuth2.0与OAuth1.0对比： ? Request Token在2.0中不再使用 ? 取消所有签名，整个授权流程使用HTTPS确保安全性 ? 授权流程大大简化，安全性有所提高 ? 与1.0不兼容，作为一个全新的协议
- 13. OAuth2.0 ：Resource Owner Password Credentials https://open.xxx.com/oauth2/access_token? 请求 client_id=1111111&client_secret=f7404ko9s748728313&gra nt_type=password&username=xxx&password=xxx 该授权方式只需一步，用户在client端输入自己的用户名及密码，并同意授权 后，资源提供方会直接返回access token给第三方使用。 安全问题： 这种授权方式通常需要授权提供方对第三方应用有着高度信任。 恶意应用使用该方式授权，可以导致暴力破解资源提供方的用户账密。
- 14. OAuth2.0： Implicit Grant授权流程 Implicit Grant 是Client端的授权流程，无需Server端配合，一步授权。 Access token被暴露在客户端，是2.0中最不安全的授权流程。 https://api.weibo.com/oauth2/authorize?client_id=2970752 请求 1&redirect_uri=http://www.xxx.com/connect/sinaweibo &response_type=token http://www.xxx.com/connect/sinaweibo#access_token=2.0 0xH12gCg2yCPD545628d9ce4RDZYD&remind_in=1274 响应 263&expires_in=1274263 整个授权流程结束，授权服务器一般会将如 下字段返回给第三方应用： access_token:用于请求用户资源 expires_in:过期时间 refresh_token:用于刷新access token scope:请求的权限
- 15. OAuth2.0： Implicit Grant安全问 题 Client_id与redirect_uri没有做校验或信任域范围过大，配合信任域下的XSS， 即可劫持用户access token。 关联案例： WooYun-2012-05804《人人网Oauth 2.0授权可导致用户access_token泄露》 漏洞详情： 1、登陆人人网 2、访问该地址 http://graph.renren.com/oauth/grant?client_id=cd271e3051444285b8a18f1211a095cd &redirect_uri=http://zone.ku6.com/u/17958620&response_type=token 3、跳转到存在xss的酷6地址 http://zone.ku6.com/u/17958620 2步中的人人那个地址是用来授权第三方的，response_type=token的授权请求只需要 提供应用的client_id以及该应用申请时所填写的回跳地址redirect_uri，但是人人网并没 有对redirect_uri进行严格检查，如果该redirect_uri域下存在xss漏洞，则可以诱导用户 授权并劫持该用户的access_token WooYun-2012-12683《百度开放平台oauth授权接口可以劫持access_token》 WooYun-2012-12689 《QQ互联开放平台oauth授权接口可以劫持access_token》
- 16. OAuth2.0： Implicit Grant安全问 题 从伪造页面中 攻击者启动正 伪造回调地址 解析access 常授权流程 诱骗目标访问 token 被跳转到存在 目标访问 XSS的页面
- 17. OAuth2.0： Implicit Grant安全问 题 越权API访问 授权服务器通常会给予第三方应用一些基础功能API的权限，如果用到受 限API，需要指定scope进行申请。若access token没有与应用的appkey 绑定，可导致越权访问受限API： https://graph./oauth2.0/authorize?response_type=toke n&client_id=28&redirect_uri=http://open.z./success.jsp &scope=get_user_info,add_one_blog 从回调地址的fragment部分中获得access token， 此时已经被授权了高级权限接口。 关联案例： WooYun-2012-12462《可用QQ登录平台发表空间日志等高权限操作》
- 18. OAuth2.0：Authorization Code授 权流程 跳转到授权页面请求code[GET] 用户同意授权, 返回code[GET] 第三方利用code请求access token[POST] 以响应体的形式返回access token[POST] 第三方应用 授权服务器 https://api.weibo.com/oauth2/authorize?client_id=1 111111&redirect_uri=http://www.xxx.com/connect/si naweibo?&response_type=code https://api.weibo.com/oauth2/access_token?client_ id=1111111&client_secret=l29dgp03m2&grant_type =authorization_code&redirect_uri=http://www.xxx.c om/connect/sinaweibo?&code=1sk42lf0s 第三方应用
- 19. OAuth2.0：Authorization Code CSRF
- 21. 测试案例展示： 3,攻击者(attacker_01)通过新浪微博登录360： 4,点击授权后阻止页面自动跳转：
- 22. 测试案例展示： 5，诱骗目标访问： (以下页面真实攻击 时不会在受害方 出现) http://i.360.cn/oauth/b ind?a=dobind&c=Sina& f=&destUrl=&type= 6，目标访问URL， 劫持成功：
- 25. OAuth2.0：Authorization Code CSRF递归劫持 模拟场景： 。。。 已经通过CSRF劫持了用户的某个 其他网站 帐号 登录 继续劫持 第三方帐号 目标帐号 其他网站 。。。 攻击者 受害者 目标帐号所在 其他网站 平台又向外提 供网站接入的 。。。 服务 有时会通过forcelogin来强制用户 输入第三方账密信息，而改为 false即可直接读取session登录。
- 26. OAuth2.0：Authorization Code Replay Attack 授权码重放攻击： Authorization Code通常会随着access token过期而过期。规范中建议过期时间为 60到80分钟，且要保证授权码仅可用一次。而很多资源提供方为了降低授权成本， 没有严格按照规范实施，导致该安全问题。 http://magru.net/users/auth/facebook/callback?code=AQDxwQebP EVVzmlfnFIZ0U11gCOVFUxz5MDcgvmWEnXwsbGF 获取目标授权码方式： 日志:GET “/auth/sinaweibo/callback?code=…” 嗅探：回调地址位于Client端，不会强制使用HTTPS XSS：配合目标网站同域下的XSS可以实现劫持code <iframe/src=/slideshow/x-def2012o-auth-security/15500718/"https:/www.facebook.com/dialog/permissions.request?app_id=159836& display=page&next=http://ori.net/users/callback&response_type=code" name="refcontainer" onload="alert(refcontainer.document.referrer)"></iframe>
- 27. 四，翱础鲍罢贬安全厂罢驰尝贰
- 28. 资源提供方： 对client_id和回调地址做严格校验 获取access token的code仅能使用一次 尽量避免直接读取当前用户session进行绑定 资源使用方： 使用Authorization Code方式进行授权 授权过程使用state随机哈希，并在服务端进行判断 尽量使用HTTPS保证授权过程的安全性
- 31. 罢丑补苍办蝉！ weibo.com/pnigos twitter.com/pnig0s