Uber XSS via Cookie
30 Aug 2017 - zhchbin
This write up is about part of my latest XSS report to Uber@hackerone. Sorry for my poor English first of all, I will try my best to explain this XSS problem throughly.
Several months ago, when enjoying my Spring Festival Holiday at home, I decided to do something interesting, so I started hunting for a bug. I like searching in the chrome dev tools. This time my lucky word was jsonp, and my target domain was
https://get.uber.com. Let’s look at what I had found at that time.
Nothing suspicious? Not! When came cross these lines of code, I was thinking about whether the value of
After reading through these lines of code:
We could get the information that the initial value of
this.rfiServer was set by using value of cookie
_rfiServer if exists. Now the problem became how we can set cookie of Uber sites? But how? Here was the options in my mind at that time:
- HTTP Header CRLF Injection at any subdomain of uber.com
- XSS at any subdomain of uber.com
What? We need to find a bug to trigger another bug. And why any subdomain of uber.com?
The Feature of Cookie
Any subdomain of uber.com can set cookie with domain
.uber.com to be used across subdomains. For instance, we can set cookie in
xxx.uber.com using following code, then
get.uber.com will use the cookie value.
XSS of .uber.com which is Out of Scope
I did really find out one reflected XSS in one of Uber’s subdomain using search engine. Let’s call the domain
<redacted>.uber.com for demo.
"is reflected and not encoded. We can inject any attribution into
type="text"is after the injection point. So we can inject
type="image" src="1" onerror="alert(1)". Note that when there is two types, the second one will be ignored.
>is removed!!! This can be used to bypass Chrome XSS Auditor. How?
- Use reflected XSS of
<redacted>.uber.comto set the value of
get.uber.com, JSONP request to
https://evil.com/idr.js, XSS of
- The final PoC
Thanks for Uber. Reward: 5k