Yahoo Mail Worm May Be First Of Many As Ajax Proliferates

The Yamanner worm that infested Yahoo Mail last week was quickly squashed. In the 24-hour period it thrived, though, the worm provided a glimpse of what's in store for Internet users unless companies apply strict measures when building Web applications with techniques such as Ajax.

The worm exploited a weakness related to JavaScript, which is a key component of Ajax, a set of technologies being used more frequently for interactive Web applications. That's what made last week's worm worrisome. Ajax can be used securely, but without careful, designed-in security, Web apps using it open additional doors to writers of malicious code.

"This kind of worm shouldn't be a surprise to anyone," says David Wagner, assistant professor of computer science at the University of California at Berkeley. We'll see more such worms and viruses as long as Web sites and companies implement Ajax applications without understanding their vulnerabilities, he predicts.

The Yamanner worm exploited JavaScript for uploading an image from a user's Yahoo Mail message, substituting its own JavaScript commands. That let the worm send a request from a person's computer to a Yahoo Mail server for names in the user's address book. It then sent a message to each name as a means of spreading itself. Most troubling, merely opening the message exposed the user; it didn't require the recipient to open an attachment or click on a link or icon. It also uploaded names to an unidentified Web site. "The problem isn't that Yahoo is incompetent. The problem is that filtering JavaScript to make it safe is very, very hard," Wagner says. Yahoo declined to discuss the attack beyond saying it had resolved the problem.

Future vulnerabilities are likely to be found in mash-ups, the combination of a known service based on Ajax and some service added on top. "JavaScript was dangerous before Ajax came around," says Billy Hoffman, lead R&D researcher at SPI Dynamics, a provider of Web application security and testing technology. With the addition of Ajax functionality in many other Web applications, the problem is going to get worse before it gets better, Hoffman predicts.

Ajax's Risks

With a more conventional Web application, a user would, for example, fill out an online form to apply for a bank account and submit that form for approval. A programmer could add Ajax or Web services capabilities to that application so it immediately alerts the user if information is entered improperly in certain fields, even before the form is submitted. Such Web services need to contact a database, which can expose vulnerabilities like a SQL injection. "Most developers will throw a Web service up, make a database call that is probably SQL-injectable, and have no session authentication to protect the transaction," says Caleb Sima, CTO at SPI Dynamics.

JavaScript on its own presents risks because it runs in the browser window without any validation checks. A browser doesn't double-check and ask itself whether the code is doing what's expected. Web applications written in Java, on the other hand, check any variable inserted by a user to see whether it matches the intended data type or purpose. Java apps restrict user-entered code and quarantine it if it tries to take an unauthorized or potentially damaging action, such as accessing the hard drive. Yet Java applications are complicated to program, while Ajax enables interactions between a Web site and user for comparatively low programming costs. Ajax application builders will need to write in validation checks and safeguards that make sure the script only does what's intended and not trust to luck that people won't decide to substitute their own instructions.

These are problems Web programmers can solve, as long as they recognize the risks and address them. Expect more bumps and break-ins along that learning curve.