News Stay informed about the latest enterprise technology news and product updates.

Eric Pascarello dissects Ajax security vulnerabilities

Eric Pascarello is the co-author of "Ajax in Action" (Manning Publications, October 2005, and the author of "JavaScript: Your Visual Blueprint for Building Dynamic Web Pages", 2nd Edition (Wiley, October 2004). Pascarello is a 2002 Graduate of Penn State University with a degree in mechanical engineering. He is also a "bartender" on In this interview he talks about Ajax security issues, the need for server-side validation and the Ajax worm released last October on

Ajax is being lauded as a technology to deliver a richer user experience. But does the use of an XMLHttpRequest open up security vulnerabilities?

When people look at Ajax they see this XMLHttpRequest object performing magic on a Web page and they think that this can lead to major security flaws. When we do a simple view source on the page, we see the page we are calling, the parameters that are being sent. Anyone with any basic knowledge of JavaScript can easily inject scripts onto the page and change the request object to send other data. So yes, it is open to attack, but it is not anything to be afraid of.

People say this is so horrible that someone can take over this request so easily. But these people need to realize that the XMLHttpRequest is nothing more than a normal form submission. You can picture it as a form being submitted in another frame. Act like there are form tags and hidden text fields on the page. With a view source of any normal HTML form, we can grab the element names and see the parameters being sent to the server. We can look at the action attribute and see where we are submitting the data. So just like how we can see the XMLHttpRequest object, we can see the same thing on any Web page. Why is it important to do validation on the server?
We can change the values of any element on the page with the help of the location bar in the browser. Disabled elements, read-only elements, hidden elements and client-side validation on any form is really a joke. Type javascript:document.FormName.ElementName.disabled="false";void(0); into the address bar and see that protected field able to be changed. That is why any seasoned developer tells you to make sure you are doing validation on the server. You have no clue what is coming to you and where it is coming from. I can write a form on my desktop and submit it to your page! It can be a hacker trying to inject SQL commands to delete your data. It can be JavaScript injection in a forum to add harmful code. No data is safe. Does Ajax raise any new types of threats?
Ajax does bring in a new threat to security that a developer may not realize. They can easily cause their server to crash if they poorly design and implement an Ajax-based control. Imagine a Web page that has 1,000 simultaneous users on it. Their servers were able to handle the load of a normal form submission to enter data. The developers see this cool Ajax and they implement a type-ahead suggest on a lookup for a ten-digit product code on every keystroke. They throw together a control that does no caching on the client or server and hits the database directly to get information. Now we have 1,000 people making a small request ten times. Now this server is seeing roughly ten times the amount of traffic it is used to. If the server cannot handle it, they may drop sessions or even have the server just stop. You note that performing cross-domain requests with JavaScript can open up vulnerabilities. Can you explain?
The one area that is really scaring me with security is developers wanting to be able to perform cross-domain requests with JavaScript. Now there are some good reasons for doing this, such as Web services and such, but most of this can be done through the server-side code on your domain. JavaScript with normal user settings cannot manipulate or see data from another domain. Developers want to be able to do this, but they have to realize the main purpose of not being able to work outside our own domain. This security setting protects us from another site opening up a frame, iframe, pop-up window or an XMLHttpRequest and grabbing our email, bank data, credit card information, eBay account, etc. I am sure that these people are really not thinking this through. Plus, what if we do allow this? We request data and a site injects code onto our sites--you would really have to trust the site you are talking too. Say hello to a new breed of advertising spam.

For more information

Ajax alert raises security, vulnerability issues

Check out our Ajax Learning Guide

Look at the Ajax worm that Samy wrote on [In October of 2005, a teenager, "Samy," released a self-propagating Ajax worm to MySpace, a social network.] That is a big security threat on a major Web site that used Ajax. Well, you have to realize that the author of this worm injected into a Web page by getting around the server-side security check. Now the author of this worm could have easily changed the code to grab user information and submit it to a hidden iframe on a page to an outside server. The XMLHttpRequest object would not be able to do that submission to another domain. So you have a little more to fear about a normal form than an XMLHttpRequest.

Pascarello's Rules of Thumb for Ajax Security:

  1. If you use user authentication, make sure you check for it on the request page!
  2. Check for SQL injections.
  3. Check for JavaScript injections.
  4. Keep the business logic on the server!
  5. Don't assume every request is real!
  6. Check the data with validation!
  7. Look at the request's header information and make sure it is correct.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.