Channels ▼
RSS

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

Yamanner's Message
Hard to defend Yahoo screened out most JavaScript functions, but companies often must choose between convenience and security
Easy to find Hackers can send test messages with harmless JavaScript inserted until they find an opening
Quick to spread The JavaScript ran as soon as the e-mail was opened; it didn't rely on opening an attachment or link
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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.