Story of a Parameter Specific XSS!

REDIRECTING TO THE NEW BLOG ...

Hello Infosec folks!
                    So I am going to start writing posts related to my bug hunting findings and share it with the community starting with this post.

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.




It got reflected as - 
https://www.private-bounty.com/Deactivate?utm_content=foo&utm_medium=bar&utm_source=baz

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'"><>\




Then I tried to add quotes in the path itself but it was also encoded well, so I moved ahead to find something else after not being able to XSS this due to the proper encoding of user input.

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

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

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

https://www.private-bounty.com/Deactivate?utm_content=foo&utm_medium=bar&utm_source=baz&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 

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

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 , 

https://www.private-bounty.com/Deactivate?utm_content=foo&utm_medium=bar&utm_source=baz&utm_foobarbaz');alert(1)//

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


Comments

Post a Comment

Popular Posts