Uber Bug Bounty:将self-XSS转变为good-XSS

既然Uber bug赏金计划已公开发布,我可以发布一些我最喜欢的提交内容,这些内容在过去的一年里一直很想做。

在Uber的合作伙伴门户网站上,驱动程序可以登录并更新其详细信息,我发现了一个非常简单的经典XSS:将其中一个配置文件字段的值更改为

<script>alert(document.domain);</script>

导致代码被执行,并弹出一个警告框。

注册后,这需要花费两分钟的时间才能找到,但现在又来了。

Self-XSS

能够在另一个站点的上下文中执行额外的,任意的JavaScript称为跨站点脚本(我假设99%的读者都知道)。通常,你希望针对其他用户执行此操作,以便抽取会话中的cookie,提交XHR请求等。

如果您无法针对其他用户执行此操作 - 例如,代码仅针对您的帐户执行,则称为Self-XSS。

在这种情况下,它似乎是我们发现的。你的个人资料的地址部分仅向您显示(例外情况可能是内部Uber工具也显示地址,但这是另一个问题),我们无法更新其他用户的地址以强制对其执行。

我总是想着是否发送有潜力的bug(这个站点中的XSS漏洞),所以让我们试着找出一种从bug中删除“self”部分的方法。

Uber OAuth登录流程

Uber使用的OAuth非常典型:

用户访问需要登录的Uber站点,例如

partners.uber.com

用户被重定向到授权服务器,

login.uber.com

用户输入凭据

用户被重定向回代码,然后可以交换访问cookie

partners.uber.com

如果您没有从上面的屏幕截图中看到OAuth回调,

/oauth/callback?code=...

不使用推荐的参数。这在登录功能中引入了CSRF漏洞,可能会被视为重要问题。

state

此外,注销功能中存在CSRF漏洞,这实际上不属于问题。

/logout

销毁用户的会话,并执行重定向到相同的注销功能。

partner.uber.com

login.uber.com

由于我们的payload仅在我们的帐户内可用,因此我们希望将用户登录到我们的帐户,而帐户又将执行payload。但是,将它们登录到我们的帐户会

破坏它们的会话,这会破坏很多错误的价值(不再可能对其帐户执行操作)。因此,让我们将这三个小问题(self-XSS和两个CSRF)联系在一起。

有关OAuth安全性的更多信息,请查看@ homakov的精彩指南。

链接中的bugs

点击收藏 | 1 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖