Wednesday, June 14th, 2006
A Yahoo Mail Ajax Worm?
Web applications, just like any other environment, can have their share of issues. Thrown something as dynamic as Ajax into the mix and you could have some real problems if it’s left unchecked. Unfortunately, as Eric Pascarello mentions in this new blog post, there just might be one such issue with one of the larger providers out there – Yahoo.
Just like the Sammy worm attacked MySpace last October another JavaScript flaw in Yahoo email is using the good ole XHR object to grab a users address book and use another technique to send the list of emails to another remote server. Want to see the code look here and you will see the famous lines that look for 4 and 200 with the XHR object!
He reinforces the security implications that could cause this (unchecked user input) . Even the “big guys” are susceptible to this sort of thing, so don’t overlook your own code.
For more information on this, check out this blog post from the Pathfinder Blog as well.
Yahoo! Mail Worm
The Yahoo! worm I mentioned earlier uses Ajax to harvest those email addresses. Ajaxian has the (safely-viewable) source code. Interesting….
[...] An axe to grind with Ajax [Ajaxian] A Yahoo Mail Ajax Worm? [Ajaxian] Java and Ajax Webinar [Ajaxian] Google Ajax Search API [Ajaxian] [...]
I was looking at the source of this on Monday morning, laughing and saying “This thing uses XHR, it’s an Ajax ‘worm’! Someone call up the Ajaxian.com guys, quick!” ;) We laughed and left it at that, but it’s nice to see it actually getting a mention. With all the interest and hype around it, it should be mentioned that it has its potential dangers as well. While not new (you could set an img .src attribute to request data from any server), the added ability to parse XHR responses makes it potentially more dangerous.
How do you actually clear user input 100%? Is there a definitive, and provably correct, overview of how to make sure all malicious input in an input field is cleared?
Any HTML page is subject to code insertion right? That’s not new to ajax. Server-side check and validate anything from the Web. We learned that with CGI in 1995.
Granted an efficiency of this attack was the fact that the address book could data be retrieved easily, lowering the bar over how inserted code could otherwise get addresses in a non-ajax Web based email program as well and spoof submissions to the web interface to the SMTP process. (It just would do it more slowly with lots more request response).
Seems that Yahoo!’s exposure was more related to the fact that it had an email service exposed over HTTP and thus enabled information to propagate to others via the email service in the domain and leave the domain via the web api to its SMTP processes. Since XHR disallows cross sub-domain data exchange, and even iframes disallow cross domain data access, the real hole here was the HTTP service that allowed mail to be sent, unverified — a server side implementation issue more than an inherent problem in XHR, JavaScript, or XML.
Isn’t that a pretty narrow case? EG. If you’re not making web based email services this kind of security loop hole would not pertain?
I mentioned this the other day on my blog also. I actually received the malicious email. The subject line said ‘New Graphic Site’.
Anyone need an invitation to Gmail?
Vulnerability 2.0 : Worms in our web
As web 2.0 sites are growing up, common side effects of grown-up software are coming along. First sign was the worm that attacked MySpace.com last year. Only a week ago Yahoo! Mail was attacked by a javascript worm. Some argue…