Reflected XSS in Tokopedia Train Ticket
Bypassing XSS filter via two reflected parameters.
There was an XSS filter that would encode
GET parameter if it contains
< character followed by
> character. The filter could be bypassed by splitting
</script/> closing tag into
> in two reflected parameters.
In March this year, I was scrolling through my old emails and found the report. I re-tested, fuzzed here and there. Eventually, I found the vulnerability on the same page.
If you search a train ticket in Tokopedia, you will be redirected to a URL something like this
https://tiket.tokopedia.com/kereta-api/search/Jakarta-Gambir-GMR/Bandung-Bandung-BD?adult=1&infant=0&trip=departure&dep_date=16-09-2019&ori=GMR&dest=BD. It stores all
My previous report was using the first method. The server didn't encode dangerous characters, such as
<. However, it encoded
\\, so the second method couldn't be used.
Then I noticed a strange behavior. The encoding used in
dest parameters was different than the rest. Notice how in other parameters,
" character got encoded into
I tried with another dangerous character,
Interesting, it was not encoded in
dest parameters. What if I insert both
Apparently the server did sanitize the parameters, but only if
<.*> appears in the parameter!
Bypassing the Filter
First I thought yeah that's it, it can't be exploited. But then I was googling some XSS payload and found this awesome repository. It says:
You can use
//to close a tag instead of
Let's try it.
Chrome threw an error:
Uncaught SyntaxError: Invalid or unexpected token. Okay I knew I was making a progress. Then I tried to insert XSS payload.
</script/>. We knew the fact that we couldn't insert
> characters on a same parameter because it would be encoded. But what if we separate
> on different parameters (i.e.
dest)? There would be other characters between them, in this case
</script/","dest":">. Is that still a valid closing tag?
Turned out it was a valid closing tag! Chrome XSS auditor blocked the page, indicating there was a reflected XSS. Then I tried it on Firefox, and it worked! Here is the full payload I used:
Session cookie in Tokopedia (named
dataSession.session.cookies. This defeats the purpose of HTTP-only attribute on the cookie. By exploiting the XSS, an attacker can steal victim's session as demonstrated on proof of concept video below.
- 28/03/2019 - Reported the vulnerability to Tokopedia security team.
- 08/04/2019 - Sent a follow-up email. The vulnerability was fixed and the report was valid with high severity.
- 11/06/2019 - Tokopedia rewarded IDR 3.000.000 and a certificate.