So, this post is about a Reflected XSS I found in a Private Program which has been previously tested many times.This XSS was present on nearly every page of the domain (let's call this private-bounty.com) but wasn't found by anyone before.

When I was going through the Application, I found an endpoint which had following in URL:

https://www.private-bounty.com/Deactivate?view=aaa&utm_content=foo&utm_medium=bar&utm_source=baz

I checked the source code to see if the parameter "view" was reflected somewhere in the page and it was found that the whole URL was reflected in Javascript context(inside Script tags) but except for the parameter "view" and its value.

Then I tried to break out since foo, bar and baz values were also reflected in the page that but unfortunately, everything was properly encoded,

https://www.private-bounty.com/Deactivate?utm_content=foo'"><>\&utm_medium=bar'"><>\&utm_source=baz'"><>\

I found this pattern of "utm_content=foo&utm_medium=bar&utm_source=baz" on every endpoint getting reflected and no other parameter will be reflected. I tried to append a custom parameter myself to see if it gets reflected, but it didn't work

After that, I tried to append a parameter named utm_foobarbaz=xxxxx

and it was reflected! into the page, so the application only reflected the parameters beginning with "utm"

so I tried again to break the context to achieve XSS using this parameter's value but it was also encoded well 🙁

Then the last try I did was to break the context by putting the payload in the parameter name itself

and boom! it worked :D, the parameter names beginning with "utm" were not being encoded when reflected in the page.

and That's how we alert :p ,

The lesson is that we should also always try to inject/fuzz the parameter names themselves and this was just a special case of such an XSS in parameter name beginning with a specific keyword "utm".

- Rahul Maini

原文链接: http://www.noob.ninja/2017/09/story-of-parameter-specific-xss.html