博客主机
A-A+

STORY OF A PARAMETER SPECIFIC XSS!

2018年01月17日 文章转载 暂无评论 阅读 391 views 次
博客主机

STORY OF A PARAMETER SPECIFIC XSS!

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
原文链接: http://www.noob.ninja/2017/09/story-of-parameter-specific-xss.html
标签:
博客主机

给我留言