Malicious AJAX was first introduced to a wide audience with the Samy worm. While the 1980s gave us the Morris worm, the 1990s gave us I Love You, Blaster, Sasser, Nimda, and Slammer, and the new century has introduced us to Samy and Yamanner. Samy was the first worm of its kind, an AJAX worm that propagated to more than a million sites on MySpace in just a few hours. Unlike past worms that took advantage of specific holes from operating systems, Samy exploited holes directly from a web application. The idea of Samy was simple: exploit filtering weaknesses and browser “leniencies” through JavaScript to perform actions on behalf of web users. The technical abilities of Samy is not so simple, as many actions were performed to bypass JavaScript filters, submit GETs and POSTs, and perform various AJAX functions to complete all the tasks required.
In addition to the Samy worm on MySpace, shortly thereafter Yahoo! Mail users were hit by a worm called JS-Yammer. The JS-Yammer worked because of a security exposure in Yahoo! Mail that allowed scripts to be run on a user’s system that were embedded within an HTML e-mail. Once the mail was read, every yahoo.com or yahoogroups.com user in the user’s address book was also sent the malicious e-mail and consequently affected (if the mail was opened). While the damage from Samy was obvious downtime of a 580 million web sites as well as reputation damage of the organization, the worm on Yahoo! Mail might have been more distressing since personal address books were stolen and then abused.
The next section of the chapter discusses how malicious JavaScript can be abused to do simple things, such as visit a web page on a user’s behalf without the user knowing, to very complex things, such as bringing down a $500 million web page or stealing personal information from a user without the user’s knowedge.
XMLHTTPRequest
XMLHTTPRequest (XHR) is a library used to perform asynchronous data transfers and is often used by AJAX applications. XMLHTTPRequest helps web developers push and pull data over HTTP from several locations by using an independent channel with the web server. XHR is quite important to Web 2.0 applications as it allows the page to implement real-time responsive actions without requiring a full refresh of the web page (or any other actions from the user). Developers like this because it means only the
changed data needs to be sent, instead of the full HTML, which results in web applications that appear more responsive. The methods supported by XHR include most of the HTTP methods, including GET,POST,HEAD,POST, and DELETE, via its open method:
Open (HTTP method, URL)
Here’s a sample XHR request to GET a web page:
open("GET", "http://www.isecpartners.com")
Using XHR, an attacker who entices a user to visit a web page can perform GETs and POSTs on behalf of the user. The great thing about XHR is that it will not perform any actions on a different domain, so the request must be within the same domain of the page. For example, if the attacker entices a victim user to visit www.clevelandbrowns .com, which includes a malicious XHR request that submits a GET to an evil site called www.baltimorebenedicts.com, the XHR request will fail since the request is not within the clevelandbrowns.com domain. However, if the attacker tries to get the user to visit www.clevelandbrowns.com/ArtLied, XHR will allow the request.
Even with the domain limitation, attackers know a lot of targets on the information super highway. Social networking sites such as MySpace, Facebook, or Linked-in; blog applications such as blogger.com; or simply common mail applications such as Yahoo!, Google, or Hotmail are all attacks where an XHR GETs or POSTs could affect thousands of users within one domain. For example, the Samy worm was able to perform XMLHTTP POSTs on MySpace by calling the URL with the www prefix (www.myspace.com + [name of myspace user]).
Some of you might be saying that any JavaScript could perform similar exploits, so what is the big deal about XHR? The fact that XHR can automatically (and easily) per-form GETs and POSTs without the user’s participation is key. For example, using XHR to POST is far simpler because the attacker can simply send the data. With JavaScript, the attacker would have to build a form with all the correct values in an iFrame and then submit that form. For an attack to be a full-blown virus or worm, it must be able to pro-rogate by itself, with limited or no user interaction. For example, XHR can allow many HTTP GETs or POSTs automatically, forcing a user to perform many functions asynchro-nously. Or a malicious XHR function could force a user to purchase an item by viewing a simple web forum posting about the product. While the web application require mul-tiple verification steps, including add-to-card, buy, confirm, and then purchase, XHR can automate the POSTs behind the scenes.
If the simple act of a user checking e-mail or visiting a friend’s MySpace page forces the browser to perform malicious actions on behalf of the user, which then sends the malicious script to the user’s friends, then a JavaScript virus/worm is alive and kicking.
Furthermore, since applications are not able to differentiate between requests that come from a user verses those from XHR requests, it is difficult to distinguish between forced clicks and legitimate ones.
To explain the issue further, consider a simple web page that will automatically force the browser to submit a GET to a URL of the attacker’s choice. The following page of JavaScript
uses the XHR function. When a user visits labs.isecpartners.com/HackingExposedWeb20/
XHR.htm, the XHR function will automatically perform GETs on labs.isecpartners.com/
HackingExposedWeb20/isecpartners.htm.
var response = xmlHttp.responseText;
}
While the intention of the user was simply to visit XHR.htm, but via XHR, the web page was able to force the user to visit isecpartners.htm without the user’s knowledge or permission. Next, labs.isecpartners.com/HackingExposedWeb20/XHR.htm is not an AJAX application; it is a static web page that calls an AJAX function in the browser (as noted by the boldface lines). Hence, the ability to execute the GET via XHR is supported by Internet Explorer, Safari, and Firefox, not by the web server on the remote site.
This introduces a low barrier to entry for attackers trying to exploit XHR functionality on modern web browsers. Figure 4-10 exposes a sniffed program that shows the initial request to labs.isecpartners.com/HackingExposedWeb20/XHR.htm on line 6 and then the automatic XHR to labs.isecpartners.com/HackingExposedWeb20/isecpartners.htm on line 10.
While the example shown in Figure 4-10 might produce more hits on a web page, a portal application, such as Yahoo! or Google, could do more damage. For example, forcing a user to POST account information, such as an address or phone number, from a social networking site or to force a user to POST e-mails to all addresses from a contacts list would be far more devastating, and both are certainly possible with XHR and depend on the security controls of the remote application.