[DOM based XSS] Or why you should not rely on Cloudflare too much
So I found another XSS in a bug bounty program again. The website [redacted.com] is protected by Cloudflare WAF and hence many payloads are filtered. But the website is implemented in an extremely bad way that even Cloudflare can’t protect it.
Just a few days before the day I found this bug, I was telling my colleagues “don’t rely on firewalls / security products too much” during an internal presentation. Now I have a real example to talk about. LOL.
This is an outdated page. You will now be redirected to our new page"); window.location="https://google.com"//
So we can spoof the users that they are going to an updated webpage and login again. (Redirecting to google for demonstration here)
How did I find it
In fact I was checking their register and sign in function and attempting to find some application flaws. I registered an account using email email@example.com without verifying it and tried to signup with the same email again. Then an error message is popped up:
And I found that the URL became
https://redacted.com/Secure/Login.aspx?UserIDfirstname.lastname@example.org&ReturnUrl=&Message=The E-Mail Address entered (email@example.com) is already on file. If this is your correct e-mail address, you may sign in as an existing customer.
Exactly the same of that in the pop-up box and the text shown on the top:
So the message maybe reflected in the body of the HTML. I tried the straight forward <script>alert(1)</script> payload.
Then I got this:
Oops. Cloudflare. But that was in my expectation 🙂 . The payload is for dummies.
So what we can do is closing the double quote and the parentheses like
Then we can do anything we want.
Good firewalls can’t save bad code. That’s it. Thanks for reading.