Cookie Based Persistent XSS

This is something that I've been meaning to post for a while now as it was included in my Black Hat DC 2009 presentation entitled 'A Wolf in Sheep's Clothing: The Dangers of Persistent Web Browser Storage'. I've noticed an increasing number of sites whereby cross-site scripting vulnerabilities exist not in echoed (reflected XSS) or database stored (persistent XSS) user supplied content, but rather within the cookie itself. This is certainly a form of persistent XSS, but not in the traditional sense as the injected script is stored on the client machine as opposed to the server and only ever exposed to a single victim.

I typically notice this on sites which display a search history. When using search functionality on a site, your past search queries are displayed and rather than storing this content on the server, perhaps in a relational database, it is instead being embedded within a cookie. Let's take a look at the search functionality at Sony.com.

In the image to the left, you will note that my past search queries ('Michael' and 'Sutton') are displayed on the right hand side beneath the 'Your Recent Searches' heading. Now this data has obviously come from past requests and could naturally be stored in a variety of places such as a relational database connected to the web application, within hidden form fields, embedded in the URI, etc. In this particular case however you will see that past searches are actually stored within a cookie, in this case the sonysearch_recent_searches cookie. Now there's certainly nothing wrong with that, after all we're dealing with a relatively small amount of non-critical data which doesn't really need to be stored beyond the current session. However, as you will also note in a later image, the user supplied content accepted in search queries isn't appropriately filtered and thus the site is vulnerable to a rather unique form of persistent XSS. Note: This was reported to Sony in February.

So why is this interesting? It's just another XSS vulnerability - not exactly an elite club to get into. I find it interesting because it has some unique characteristics. In some ways, it's almost a hybrid of reflected and persistent XSS. Let's take a look at what I mean by that.

Storage - This is certainly an example of persistent XSS, as the script is stored. However, it is stored on the client side, within a cookie, not within a relational database on the server side as is typically the case.

Victim - Unlike most persistent XSS vulnerabilities, injected script will not affect anyone that visits a vulnerable page. It will only affect a single user (like reflected XSS) as it is transmitted within a cookie when an individual request is made.

As you can see, while we have persistent XSS, it smells like reflected XSS. This could come in handy, if for example an attacker were looking to target a single individual (reflected) but wanted the attack to repeat (persistent) every time the user accessed a certain resource. Consider for example a situation where the attacker wanted to harvest sensitive data every time the victim viewed it. This situation alleviates the timing challenges associated with a successful reflected XSS attack while remaining more stealthy than typical persistent XSS.

Food for thought.

- michael