漏洞赏金猎人笔记-OAuth账户劫持精要理解
前言
公众号在之前发过一篇文章: 在OAuth流程中所产生的账户劫持漏洞研究 ,原文是Frans Rosén写的,文章太长,初次读可能会蒙圈,为了方便理解,这里做了一个精要总结,这便是本文诞生的缘由.
OAuth流程简要概述
1.用户打开example.com 并选择使用 Google 等第三方提供商登录
2.example.com通过redirect_uri参数将用户重定向到Google进行验证。这个参数是经过严格验证的，允许列表(allowlist)是由example.com管理员在设置时配置的。
3.用户在谷歌上进行认证，或者如果他们已经登录，就会自动进行认证;
4.谷歌将用户重定向到第二步的redirect_uri(通常是example.com后面有个关键词callback)
注意:上面这个第四步里面的url包含这些参数,如果url被泄露,可能会造成账户劫持
有两个问题:
-
有些参数只能使用1次。如果受害者通过认证流程并将code换成cookie，即使你泄露了code，你也无能为力。
-
怎么泄露这个URL也是个问题
如何从OAuth流程中入手
1.欺骗受害者访问他的网站
2.将用户重定向到Google，redirect_uri指向example.com。
3.用户在谷歌上进行认证，或者如果他们已经登录，就会自动进行认证
4.谷歌将用户重定向到example.com
上面流程的关键点在哪?在第二步中，Frans(原文作者)添加了一些OAuth参数,这些参数在Google看来是有效的，但在example.com看来是无效的。这将导致example.com从Google收到有效的code或令牌，但却不能使用它们。
例如，state参数的作用类似于CSRF令牌。当它无效的时候，example.com会抛出一个错误。其他破坏这个流的方法包括请求不同的或多个OAuth response_type亦或是修改redirect_uri,比如:
将用户重定向到/CaLlBaCk(主要就是改变大小写)或/callbackxxx，这通常没有什么影响，但却可以破坏这个流程;目的是在example.com上造成错误。因为这样的话，example.com就不会使用code参数，如果攻击者能够泄露它，他们就可以接管受害者的账户了
受害者降落在一个错误的页面上，这就是原文作者Frans所说的non-happy paths.
另外一种方式是将用户重定向到example.com主页面(注意这里是没有/callback路径的)。这通常是一个有效的redirect_uri，但目标仍然没有使用参数。
最后一种方式是: 网站将用户重定向到了登录页面。
以上所有方法中,敏感参数必须在URL中。
泄露URL
OAuth流程中断之后,后面就是要想办法让URL泄露,他(Frans)发现了几个方法:
-
第一种是分析SDK,允许任何网站发送postMessage，它将以location.href作为响应,可能会泄露code和其他OAuth参数。(注意:这里如果你不懂postMessage,可以自己去研究一下其用法,这里还是稍微有点复杂的,尤其是对于没有开发基础的童鞋)
-
另一种方法是类似的，但postMessage里面有个参数会被校验(上面那个方法没有被校验)。但是，他在其中一个被允许的域名上发现了一个XSS，于是他从该网站发送了postMessage。
-
第三种方法也是有点类似,不需要XSS,iframe只允许你加载一个任意的JS
-
另外一个例子是一个分析服务，它将URL保存在本地存储中，你可以要求它给你本地存储中(local storage,这个前端的童鞋应该很熟悉了)的所有值。
-
还有一个带有特定API功能的聊天，允许泄露URL。
最后，他在一个分析提供商的CDN上发现了一个XSS，这使得这种攻击可以在许多网站上执行。他在这里使用的CSP绕过方法相当有趣:
1.他可以把SVG上传到一个网站的/img/目录中。其路径是/img/customer94342/xss.svg。
2.CSP头被添加到对/img/目录内任何请求的响应中。
3.但当他请求/img%2fcustomer94342/xss.svg时, CSP头没有被添加，但这里使用的S3存储并不关心编码问题，而是返回了文件
注意:S3 buckets并不关心你是请求/img/file.svg还是/img%2ffile.svg。
总结
1.如果你想劫持一次性使用的令牌和值，你需要以某种方式强制出错。
2.iframe的origin值得注意,在本地存储中可能有敏感数据
如有侵权，请联系删除
好文推荐
