Crashing the Stock Market with XSS and AJAX

Here is my first installment of a many part series of the dangers of having XSS vulnerabilities in AJAX enabled web applications.

The Vulnerability

Many websites are offering a customized homepage dripping with AJAX goodness. You can often times customize your homepage with “widgets” or modules of code that allow you to bring together many pieces of information onto your homepage. The Google Homepage and Live.com homepage allow you to aggregate your news, e-mail, and many other tools so you don’t have to leave the comfort of your customized page to get the latest update or change settings on other pages.

While these little widgets are great advances in web technology they also increase the possible attack surface. For this example let’s assume that you have installed a widget on your personal page that was written by an online trading company.  This widget allows you to track the stocks that you have purchased. Not only that but as a value add they’ve also created a feature that will allow you to set stocks to buy and sell and to add buy/sell thresholds on stocks that you’d like to buy or sell.

Now imagine that one of the widgets on the homepage is compromised by a persistent XSS vulnerability or is controlled by somebody with less than saintly morals.

The Compromise

Using different techniques of cross domain bridging an attacker can effectively reach from one domain: the attacker’s to another, the online stock training company’s site. They can do this because both widgets reside on the same page. Once this can be done an attacker could craft a malicious javascript virus that would infect the page of the user to control the stock trading widget. Since the trading module relies heavily on AJAX the entire experience can be scripted easily and without the user’s knowledge.

Using the stock trading widgets features described above an attacker could:

• Tell the trading company to sell all the stocks of the user.
• Set thresholds for trading to effectively bankrupt the user by setting thresholds to buy high and sell low.
• Intercept any UI changes from the real stock trading company to ensure the user doesn’t realize any changes have been made until the damage has been done. 
• Buy or sell any stocks available to the user

The amazing thing is that all of this can be done completely programmatically, meaning that it does not require the attacker to be present or even knowledgeable as the attack is taking place. As soon as the exploit code has been released the attacker will have infected every user on the site with those two widgets installed.

Of course this would be devastating to any user, but the truly surprising thing is that because the widget is using AJAX the victim would have no way of proving that he/she did not make these very poor choices in stock trading.

Who’s at Risk?

Any time we’re using AJAX and allowing user supplied input to be used in the creation of web pages this threat applies. Anytime we might have text that the user supplies we need to think about this risk.  This includes simple things like “Welcome back, Joe!” all the way up to full page content creation.

The Mitigation

This type of vulnerability can be easily fixed by employing two things: strict input checking using a whitelisting algorithm and HTML encoding all output to the browser.

Strict input checking will ensure that your application only allows the input to be processed that it absolutely knows how to deal with. The best technique for whitelist input checking is using regular expressions. Regular expressions should be built into a validation library where each developer has access. This will allow for easy updating if a vulnerability is found in this library. This centralized approach will ensure that every time validation is needed developers are sure to be calling the most recent version of the validator.

All user supplied input should be encoded using a whitelisting  encoding module. This type of module would encode all text that hasn’t been explicitly allowed to be presented to the user. Since the browser can quickly interpret any data in HTML encoding there is no risk of over-encoding.

What kinds of AJAX insanity have your company created in an attempt to melt the online and offline experience together? What kinds of security measures are you taking to ensure these major security risks don’t occur?

–Joe