Always escalate! From Self-XSS to Persistent XSS on Login Portal

Ref https://upload.wikimedia.org/wikipedia/commons/4/42/Copenhagen_Metro_escalators.jpg

About 2 months ago, I discovered a persistent self-XSS on a login portal. Most of programs do not accept self-XSS report, but I managed to escalate this to persistent XSS on login page by chaining with Login CSRF and reported to the program as valid vulnerability.

Yet again, this is my discovery on private program, so let’s call it redacted.com

There was an account portal page where you could change some settings on your account including firstname, lastname.

I spent some time tampering with all the parameters that I was able to. The result was I found that there was no validation of firstname and lastname on the backend, meaning I could change my name to something like <em>John</em>. However, <script> tag or common XSS payload were not allowed because there was cloudflare in-between frontend and backend and the reflected name on account page was filtered as well. < was escaped to &lt;.

I stopped looking for bugs on this account portal page thinking that it was too hardening for me.

Few days later, I was willing to try again and got their login page on my browser but I noticed something strange before typing my credentials on the form. I was greeting with the name I changed last time, John but that HTML tag <em> was missing.

I pressed CTRL+U on my keyboard, to bring source code of this page up to my screen and there was that HTML tag enclosing the name! unfiltered.

I went on researching on how to bypass cloudflare WAF, there were many articles out there on the Internet but the core idea is to look for an origin IP of the server.

An easiest and simple way is to look for IP history on viewdns.org. If the website was initially set up without cloudflare, an origin IP would be logged on the Internet history.

Lucky me, I found an origin IP recorded on viewdns.org. I tried accessing the website from its origin IP and changed the name to <script>alert(\”Are you hungry?\”)</script>, it got pass to the backend with no cloudflare WAF involved.

As expected, alert box prompted when I visited login page.

So I found self-XSS on login page, then what?
Most programs do not accept this type of vulnerability report becauuse it usually does not pose security threat but I spent too much time on this, there was no way back. The only was to go up! (I mean escalate)

When you find a self-XSS (that’s not putting javascipt code in dev console), ALWAYS try chaining it with other vulnerabilities. There are many articles out there from many great minds writing about escalating self-XSS. One that might relate to my situation is Login CSRF plus self-XSS

Let’s see how does my payload was stored on login page.

1.) After login, if user check on Remember me box, session will be saved in cookies named rememberme, with expiration time set to one year.
2.) If a user visit login page again, even without logging out before, he/she will be greeting with firstname reflected on login page.

Therefore, if I manage to find login CSRF, I could force other users to login on my account and if they visit the login page again, my XSS payload will be executed.

I started by Burp Suite to get a look at login request and as expected, CSRF token was sent along with my credentials during login request. I tried removing that token and re-sent the request… Unforetunately, it failed.

As I said, I could not give up. Have you ever heard of poor man CSRF?.
Usually, to implement anti-CSRF system, the CSRF token need to be tied to something that can be used to identify the person who perform that action.

If CSRF token does not tie to user’s session, an attacker could grab a valid CSRF token from the website and reuse it on victim.

I tried this option, copying CSRF token from a different browser session and reuse it… I got login to my account! I finally found a way to force XSS on user login page.

Here is the proof-of-concept code I used to exploit this chain of vulnerabilities

If a user visit my page, he/she will be forced to log into my account and next visit on login page, he/she will be greeting with my XSS payload!

Timeline of Vulnerability Report
- Feb 10, 2020 — Report sent
- Feb 11, 2020 — Triage with Medium severity
- Mar 14, 2020 — Reward $500 + $150 (bonus)
- Mar 17, 2020 — Fix deployed

another hacker

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store