Longtime readers will recognize my standard security mantra: convenience equals insecurity. Call me a security Luddite in that I believe it's sometimes better do things the long way around because shortcuts in computer software or Internet services most often leave you vulnerable. That sentiment seems to be shared by Billy Hoffman. He's a researcher at SPI Dynamics who, while criticizing businesses that race to deliver AJAX-enabled Web sites without regard to security, focused his two Black Hat Web 2.0 presentations on the potential troubles lurking within AJAX--in particular, how some hot new Web sites are ineptly filtering user input and thus newly opening the end user and the enterprise itself to old-style attacks. In this week's column, I'll talk specifically about AJAX and cross-site scripting attacks using JavaScript executed on your desktop browser; next week, I'll discuss how AJAX can also open an enterprise to attack.

What is AJAX?
AJAX is short for Asynchronous JavaScript and XML. In the old-school Internet, a synchronous world, a request made by a user through an Internet browser, such as getting a page that shows a map of San Francisco, would go out to a Web application server and return as an image on the user's browser. If the user then decided to zoom in on a feature, say, Fisherman's Wharf, the browser would send a second request to the map server, and a new page would be sent down to the user. As the user continued to define the search area, new requests and new displays would be downloaded, always pausing to pass through the Web server. In the asynchronous world of AJAX, a single request made by a user through a browser begins a dialogue with the Web application server by downloading and caching the user's anticipated next moves.

	AJAX makes several hidden requests (albeit helpful requests), and if a given Web application isn't properly filtered, these additional requests could be used for malicious purposes.

To demonstrate the difference in the experience, Hoffman asked everyone to recall the pre-AJAX service MapQuest circa 2000, where if you wanted to zoom in on a city street, you had to wait for the new image to download and render on your machine. Contrast that experience with today's AJAX-rich map services, where images appear to expand in resolution fluidly, with no time delay. Behind the scenes, AJAX has requested additional images to be cached and readied in advance, without your instruction. And therein lines the potential for trouble: AJAX makes several hidden (albeit helpful) requests, and if a given Web application isn't properly filtered, these additional requests could be used for malicious purposes--for cross-site scripting, for example.

Cross-site scripting
Cross-site scripting (XSS), which has been around for years, injects script (either JavaScript or VBScript) into a user's browser. Most often, XSS attacks lead to cookie theft, keylogging, screen scraping, and even malicious requests. A more detailed explanation of cross-site scripting will delineate at least three different types of attacks. One attack uses the Document OM, or local site, to execute code within the user's browser. For example, if you visited a Web site coded with malicious content and your browser was vulnerable to such an attack, a script could be injected on the user's machine potentially allowing a remote third party access to your compromised machine.

Another attack uses the way in which Web data is first stored on a Web server then displayed (without using HTML) within the user's browser. An example would be to use an online message board, with users posting HTML messages for others to read. An attacker could inject script into the HTML message and potentially attack anyone who reads the message, taking, for example, a user's session cookie and sending it to a third party site without the user's knowledge. A third attack scenario, the most common, uses nonvalidated data to display a new Web page, and this nonvalidated content could include specially crafted JavaScript.

Even trusted-name sites have to be scrutinized: Yahoo Messenger suffered a JavaScript-based, AJAX-enabled worm last June. Then there's the Samy MySpace worm from last fall.

Life in a post-AJAX world
Before AJAX, a cross-site scripting attack could merely capture information about a site that a user visits. In the current AJAX-enabled world, says Hoffman, AJAX allows an attacker to actively hunt specific content, using the target site as point of departure. Before AJAX, an attacker was limited and Web application requests were often made blind, with the attacker unable to view the responses. With AJAX, an attacker can autonomously inject script into pages on a target site, reinject the same host with multiple XSSs, or send multiple requests using complex HTTP methods. With AJAX, the attack landscape has increased, especially if the Web server doesn't filter input from users.

Even trusted-name sites have to be scrutinized. For example, Yahoo Messenger suffered a JavaScript-based, AJAX-enabled worm last June. Then there's the Samy MySpace worm from last fall. (I'll write a separate column about AJAX worms in the near future.)

Patch early and often
I'm not advocating that we return to the slow request-and-wait days of yore; I'm hooked on the relative ease with which I can surf around sites such as Google Maps. But the continued use of these sites underscores the need to keep your browser up-to-date.

Firefox just released version 1.5.0.6, and it will release another update in early September. These are pushed out automatically, so current Firefox users know when to apply them. Microsoft, however, doesn't do this. To get its updates, you will need to visit the Microsoft Update site or this recent cumulative security update for Internet Explorer (one caveat: you must be running either Windows 2000 or Windows XP; Microsoft will no longer patch legacy Windows systems, even for security vulnerabilities).

When was the last time you updated your Internet browser? Talk back to me.