In this Web 2.0 world, mashups are red hot. Take the data from Craigslist, add it to Google Maps, and you have a visual representation of property listings within your target area. Web sites are rushing to publish their APIs so that their products are included in this latest Web 2.0 craze. But Billy Hoffman, security researcher with SPI Dynamics, warned at this year's Black Hat Briefings in Las Vegas that such convenience can invite trouble for both the user and the Web site. I want to call attention to the way Web sites themselves can (and should) do more to protect themselves against JavaScript exploits using AJAX bridges to loot their assets.
Bridging domains
AJAX is short for Asynchronous JavaScript and XML. In the old-school Internet, a synchronous world, an initial request is made to a Web application by a user through an Internet browser and that request is served and downloaded to the user. But should the user want to change the request or create another, the user would have to wait while the second and third requests are served and downloaded. 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. With AJAX, an attacker can autonomously inject script into pages on a target site, re-inject the same host with multiple XSSs (cross-site scripts) 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.
By design, AJAX is limited to contacting only one host server; AJAX bridges, acting as proxies, allow third-party domain sites to be used. Hoffman used the fictional example of Billy's Bookstore, a traditional brick-and-mortar bookstore whose online site uses Amazon.com's API to transparently provide its customers with an extended book search. From Amazon's perspective, Billy's Bookstore makes all of the requests, not the individual users. Indeed, under AJAX, it's impossible for a Web application to tell whether or not a user typed in a request; AJAX is capable of making autonomous requests all on its own. This could open Amazon (if it's not careful) to potential attacks from Billy's Bookstore customers.
When bridges fail
Hoffman, in his talk at Black Hat, called out several security flaws with AJAX bridges. AJAX bridges do not, for example, authenticate input. AJAX bridges do, however, rely on other components for security (not always secure), and under AJAX, it's impossible to repudiate (deny) that a specific malicious request was made. With AJAX, a criminal could invisibly exploit the security weakness in one company to attack the assets of another company by making complex requests, such as access to databases within the second company, that cannot easily be traced back to the first company.
Let's say a third-party site starts detecting malicious SQL injection activity, and its Web applications start seeing harmful JavaScript inserted into a SQL database request string. The third-party site could block the Billy's Bookstore ISP, but what if Billy's Bookstore generates a significant amount of traffic? The criminals in this example have succeeded in causing a denial-of-service attack on Billy's Bookstore customers by denying them access to the third-party site. Also, the third-party site would suffer a loss in traffic from having blocked Billy's Bookstore.
What's a company to do?
Hoffman offered the following advice: If a company is thinking of going AJAX, it should consider what is gained and whether it is necessary to adopt AJAX. If so, the company should then document all current user inputs and ensure there's input validation on each. Further, it should minimise the program logic exposed to the public and implement input validation on all function input, as well. Hoffman recommends following established Web standards rather than using creative hacks to accomplish what is desired. Shortcuts only open more avenues for attack.
With companies rushing to Web 2.0-enable their sites, some established businesses are needlessly compromising their security by depending upon the security of others. Companies should give careful consideration before opening their APIs and should not rush to allow any and every possible connection with their site. Convenience on the Internet most often compromises security. Just because AJAX is currently sexy doesn't mean it's necessarily a good idea.
