AJAX applications and data security
AJAX is a great tool and has provided web developers with the opportunity to create wonderful, engaging applications that work better than anything else preceding them. By requesting information asynchronously, one can develop applications that function very much like traditional, installed applications. The resulting application has lower development costs, no distribution costs, lower support costs, and can be integrated with more, 3rd party applications than a traditional installed application.
However, AJAX has a new set of problems to be handled in order to have a safe, secure application. Let’s look at two basic things that have to be done in order to make it work right.
Request Hijacking and Spoofing
One of the most basic attacks and problems to an AJAX system is simply the sending of requests to the server directly. While this doesn’t seem to be an issue – it’s huge. Why? Because they can screw up your database, put items in a shopping cart, change pricing, and more.
Let’s look at a quick example, you are running Bob’s Micro-Dog Supplies website. It has a great AJAX interface that is smooth and beautiful. When people add items to the cart it is all done in AJAX. Here’s where the problem comes in. When they check out, you call the following URL https://www.bobsmicrodog.com/checkout.php. In the POST variables you list the products, the quantity, the price each, and the total price. Sounds great, right? Wrong.
By submitting to the URL with different POST data I could buy the entire order for pennies. Remember, your URL’s are only slightly hidden.
How to fix it
Use AJAX for user interface and non-consequential data management. Pricing and ordering are not inconsequential. A better way would be for the server to have the cart and data and the AJAX version simply make references to it. Anything that is of consequence should be maintained and controlled by the server.
Authentication
The next issue is maintaining authentication. Unfortunately for bobsmicrodog.com, their application had a login script that returned the rights via JSON to the browser. This allowed for a great user experience – it was fast. However, bobsmicrodog.com never checked anything again. If the user could click on a link the server would accept the information. Too bad, that little Johnny learned the URL to send and now they have all the customer information because little Johnny Hacker got into the private side of the site.
How to fix it
Not only must you store all information of consequence on the server, you must also assume that every request to the server is illegitimate. Store security information in a database on the server and verify that the user is who they say they are and that they have the rights to do what they are requesting. Don’t assume that the request can’t be sent via any other method.
You’re not there yet. Because there are sneaky people around, you need to go another step forward. One of bobsmicrodog.com visitors is ordering information while at a coffee shop with wifi. Little Johnny Hacker is sitting in the coffee shop with a sniffer and discovers the customer. Now they have session info, and user keys, and whatever else was posted on the requests. So they form a URL with the session information and maybe other details in the query string or in post data. Bobsmicrodog has modified their system so they check the session and recheck the rights for that user. Oops, now they have Little Johnny Hacker masquerading as the legitimate customer.
How to fix it
You not only have to check the session information, you need to make sure you know where the requests are coming from. Verify the IP address along with the session information. You may have a case, however where the IP address is shared among all users (like behind a proxy server). In that case, checking IP may not be sufficient and you are going to have to be more creative.
The best thing to do is to not use the standard session mechanism but set up your own authentication system to keep track of who is logged in and where. Sessions are automatically created by the server which makes spoofing a session ID easy. Avoiding using sessions in the traditional sense prevents this issue from coming up.
Summary
AJAX applications need to be rethought. It’s not a matter of just calling your standard processing script using AJAX calls. The security issues are more numerous with an AJAX application. You need to do more verification of access rights than you would do with a standard application. You need to have a much safer method of verification user identity than you would do with a standard web application.
I hate when Google gets bad press, even if it's from an obscure group of web geeks.
