Friday, 14 December 2012

DOM Based XSS in Etsy


I recently found a DOM based XSS vulnerability in the Registry search function on Etsy.com and thought I'd do a quick write up.


What is DOM based XSS?

DOM based XSS (In this article I'll abreviate to DBX) is slightly different to regular XSS in that we are targeting the underlying Javascript used on the client-side instead of reflecting our attack off some server-side function. The end goal is however the same, typically the execution of malicious Javascript within the trusted domain of the target site.

Usually to find DBX vulnerabilities we need to trace the input and output of client-side Javascript functions and find data flows with poor (or non-existent) input validation. Manual code analysis is possible but it's far quicker and easier to use an automated tool such as Dominator.

Dominator is implemented using a modified version of Firefox and will dynamically test pages as you browse. It specifically looks for sources and sinks, essentially where input data goes in and where it comes out. For data flows that are potentially vulnerable Dominator will give you a warning and a step by step view of how exactly the data is being processed. It's then down to you to pick apart the output to figure out if it can actually be exploited or not.

You can get a free trial of Dominator Pro at the official site here:

https://dominator.mindedsecurity.com/

Although there are multiple places where DBX vulnerabilities can appear, today I'm going to be looking at the handy little search box suggestion drop-down.


The humble suggestion function...

The search box suggestion menu is a staple function in most modern web sites. You enter some text in a search box and it gives you a set of suggestions back.

Me searching for a new dress on Etsy. (I ended up buying the hot pink dress ;) )

In the background there's a clever piece of Javascript running that detects when the input changes, dynamically processes the input and sends back suggestions. It's a useful function but does it validate my input?


Enter Dominator!

As mentioned before Dominator will break down the Javascript functions on the page and figure out where the sources and sinks are. Any time we can control a potentially sensitive sink Dominator will produce an alert and show us how our data is being processed.

How can we use this information to exploit a search field? Rather conveniently Stefano (the creator of Dominator) produced a handy tutorial here:

http://www.youtube.com/watch?v=f_It469LUFM

With Stefano's suggestions in mind I took a look at Etsy.com and came across the Registry suggestion field here:

http://www.etsy.com/registry

This field unsecurely used the search input and was vulnerable to DBX. I forgot to take a picture of the *actual* vulnerable code but here is equivalent code that is used for the main Etsy search function. Check it out:


Dominator tells us how our input data is manipulated as it passes through the javascript in the background. I started off by typing 'abc' in the search box and as you can see a replace function removed carriage returns, the input was made lowercase then concatenated with other strings and added to the page.

What's missing? Input validation! According to this input processing path, not once are special characters removed or replaced.


How can we exploit this?

Ideally we'd like to insert some malicious javascript in the page. How about inserting a sneaky iframe containing javascript?

<iframe/onload=alert("XSS")>

Simply inserting this code into the search box won't work as the output is still inside various quotation marks and HTML tags. Looking down the screenshot above, the bottom part shows our finished html that will be written to the page. In this code you'll notice two possible injection points, the first is by the span tags, the second is in the list object's data-value.

The first injection point actually had some additional checks but the second injection point didn't. So to exploit we just close off the quote for the data-value, close off the list tag and then insert our iframe.

a"</li><iframe/onload=alert("XSS")>

Entering this query into the search box would successfully lead to exploitation.  

Although I didn't review the code, I believe the main search box isn't vulnerable because of two mitigations. The first is that if your query contains special character such as slashes, quotes or brackets, the search box redirects you to a default text "find shop names containing" which prevents usage of the suggestion function. The second mitigation involves a maximum length on the suggestion. If your input is too long you will no longer be given suggestions.


Final Thoughts

This vulnerability yet again demonstrates the importance of using proper input validation for ALL inputs. Even in 2012 (almost 2013!) developers are still missing the basics it seems.

DBX is an interesting attack vector that's not as well known or researched as regular XSS partly due to the difficulty of dynamically analysing Javascript. Dominator has really filled a gap in the market providing both attackers and defenders with a way to detect potential DBX vulnerabilities. Props to Stefano for making such an awesome tool.

Lastly I want to give a shout out to Etsy for a quick response/fix as well as the bounty!

Cheers,

The PwnDizzler

4 comments:

  1. Nice work on this - does it mean you're buying beers?

    ReplyDelete
  2. This definitely highlights that client side validation is very important in securing web applications. Often client side validation is touted as simply a means to improve user experience and reduce user errors. Wherever possible, both client side and server side validation should be used to reduce an application's attack surface.

    Another example of DOM based XSS that I've seen is the use of the location.href property to access the entire URL of the current page and fragment identifiers. Since anything after the fragment identifier (the # symbol in a URL) is not sent to the server then it can only be validated by client side code. If no validation takes place on the client then an attacker is free to add anything they want after the fragment identifier in a URL to exploit the user.

    ReplyDelete
  3. Hey guys, thanks for the comments!

    Will you make some great points. In this post I specifically looked at how the data from a user controlled input field was written to the page HTML. But like you mentioned there are many other potentially sensitive inputs (and outputs).

    That's actually one of the best features of Dominator that it picks up ALL of the sources and sinks. So no matter how we send our data, through URL, Referrer or using input parameters we can still detect any unsafe usage by client-side code.

    ReplyDelete
  4. can you make a tutorial on dominator because i am still confused in how to use this application :(

    ReplyDelete