Valid URL as a Potential XSS Vector

Valid URL as a Potential XSS Vector---This would be mine and yours URL from now on: http://xssplayground.net23.net/xss%22onmouseover=%22alert(1); %20imagefile.svg by Ashar Javed https://twitter.com/soaj1664ashar You often read about a term „specially crafted URL“ while skimming through XSS literature. I think there is no such thing and this is the most abused/misused term in the literature.

https://twitter.com/soaj1664ashar/status/429913133050654720 The correct term might be „customized URL“ and the goal is to XSSed a site with the help of this customized but valid URL. The customized URL is a valid URL and it is renderable in browsers. At the same time, if used, has a potential to XSSed a site.

Last night (this is how I spend weekends), I came across a site because I was looking for live example where I can XSSed a site with the help of „customized URL“. I will not tell you the name because the XSS is still live but just FYI that site has a rank in b/w 1400-1450 in Alexa1 ranking at the time of writing.

At one point in site's functionality, site asks me to provide a URL. Whenever site asks me to provide a URL, I always input ... javascript:alert(1) [JavaScript URI] OR data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ [DATA URI] In most of the cases, the above two works like charm and easily XSSed a site. Recently, I XSSed 1 http://www.alexa.com/

Twitter Translation Forum, Magento Commerce and Gitter (chat for GitHub) with the help of JavaScript and DATA URI . But the site, I am looking at currently is good in a sense because it does not allow JavaScript execution via JavaScript and DATA URI. Got the following message …

For the sake of completeness, URL encoding of JavScript and DATA URIs also do not work. For me, this is the perfect venue for testing „customized URL“ and see how far and under which circumstances it works. Internally, valid URL lands as a value of <input> tag's `value` attribute like that. e.g., if I input http://www.example.com/ then it looks like: <input name="..." id="..." class=".." value="http://www.example.com/" type="text"> The immediate and obvious thought came to my mind is: if I will find a way to break attribute context or jump out from the attribute context (i.e., the value of `value` attribute) then I can easily XSSed a site. Some days ago, I tweeted about „how to easily find XSS in attribute and script“ context:

https://twitter.com/soaj1664ashar/status/436425835742887937 So I decided to used the following as input: " onmouseover="alert(1); but again good thing happens in this case and site correctly says, input a valid URL. At the same time, I also want that the site should stop this because I am wishing for „customized URL“ :).

Normally good things do not happen for sites and above injection easily XSSed a site in attribute context. I found at least five STORED XSSes (not self or reflective … think and figure it out HOW) in Magento with the help of above injection. :-)

In short, in order to XSSed that site, the URL should be a valid URL but at the same time, it should be customized in a manner that it will break out from the attribute context.

So let the game begins....

If we input: http://www.example.com/" (URL ends in double quotes without URL encoded form of double quotes), then again site correctly says:

Now I change only double quotes into its respective URL encoded form i.e., %22 and input: http://www.example.com/%22 and this time, I receive no message from the site about the validity of the URL. BUT internally site treats our input http://www.example.com/%22 as:

It means, site has converted %22 into double quote (") and consider this as a new attribute whose value is empty like that "=" " :) This is interesting and worth looking at because site is converting URL encoded form of double quotes (%22) into double quotes (").

So my next input is: http://www.example.com/%22xxx (keep in mind my tweet related to attribute & script context) and site has converted this input into two parts i.e., one as value of `value` attribute of <input> tag and one as a new attribute whose name depends upon our input (see text in red color below): <input name="tb_url_text" id="tblink_url_text" class="text urlOptHTTP required" value="http://www.example.com/" xxx"="" type="text"> Like before, this time again, site has created a new attribute named xxx" and assigned empty value to it: xxx"=""

The goal I have in my mind is to replace xxx with onmouseover and fill empty value with alert(1) but at the same time I want to get rid of " appended after xxx. So I decided to input the following as a part of next input: http://www.example.com/%22xxx=%22xxx and site has converted this into: <input name="tb_url_text" id="tblink_url_text" class="text urlOptHTTP required" value="http://www.example.com/" xxx="xxx" type="text">

Cool! So now site did what I want i.e., xxx="xxx" …. Now it would be easy, if I simply convert the first xxx into onmouseover and second xxx into alert(1) then we should have an XSS … BUT THE MOST IMPORTANT THING IS: IT SHOULD BE AVAILABLE IN THE FORM OF VALID URL. So I created a URL infact customized URL (e.g., if site is using single quote ' around attribute value then you can simply change %22 into %27 and this will work) i.e.,

http://xssplayground.net23.net/xss%22onmouseover=%22alert(1);%20imagefile.svg You can open this URL in any browser and browser will render it. Once opened it will open another window that points to google.com. I have written a one liner in svg file inside script block that points to google.com. It is a valid URL and if input, site has no objection:

BUT at the same time, It will XSSed because internally it becomes:

So now we have a valid URL that has a potential to XSS a site BUT how good and useful it is …

The answer is, IT PURELY DEPENDS UPON THE IMPLEMENTATION. e.g., I have tested the same URL in the following manner in Gmail and Hotmail and found two different outputs. <a href=“http://xssplayground.net23.net/xss%22onmouseover=%22alert(1);%20imagefile.svg“> click me </a> Gmail Output (Gmail rightfully does not convert URL encoded form of double quotes into " otherwise there is a great chance that it will break out from the attribute (i.e., `href`) context):

Hotmail Output (Hotmail also correctly does not convert URL encoded form of double quotes into " BUT does convert small brackets of alert(1) and semi-colon (;) into URL encoded form)

So we may conclude by saying: any implementation that converts URL encoded form of double quotes (i.e., %22) into " is vulnerable to this valid URL based XSS vector because with the help of this URL, we can jump out from the attribute context. Let me know via DM, if you will ever use this URL in order to XSSed a site ….