Ajax Security


Over at Reg Developer they have posted a good article regarding Ajax security. The article takes a 1-2-3 approach to security and covers topics like cross site scripting and SQL injection.

Below is an excerpt from the article.

Know what runs where

AJAX is making it increasingly difficult to be sure where your code is going to run. Take the Google Web Toolkit (GWT) for example. You program in Java and the environment takes some of that code and compiles it to JavaScript that runs on the client. If you make a mistake and implement authentication, access control, validation, or other security checks in the code that runs on the client, an attacker can simply bypass them with Firebug.

Imagine you've carefully coded rules to be sure that administrative functions are never shown to ordinary users. This sounds good, but you forgot that the user interface code is running on the client. So the attacker uses Firebug to invoke the administrative functions. If the proper checks aren't in place on the server side, the attacker just gained administrative rights. Many Rich Internet Application (RIA) frameworks also have this issue.

The solution is to be very careful about making the boundary between the client and the server very clear.

Keep data separate from code

Hackers frequently use a technique called "injection" to bury commands inside innocent-looking data and get interpreters to execute their commands for them. This simple trick is at the heart of many security attacks including SQL injection, command injection, LDAP injection, XSS, and buffer overflows. Preventing injection in a target-rich environment like the modern browser takes discipline.

The key to stopping injection attacks is never executing data that might contain code. But with AJAX, lots of data and code get passed around and mashed together in the DOM. There has never been a data structure that mixes together code and data more than modern HTML.

So be very careful with data that might include user input. Assume it's an attack unless you've carefully canonicalized, validated, and properly encoded. Imagine you're invoking a REST interface and the request contains user data. The response you receive is a JSON string that includes that user data. Don't evaluate that string until you're sure that there can't be anything but safe data in there. Even just adding that data to the DOM might be enough to get it to execute if there's JavaScript code buried in there.

Beware encoding

Encoding makes everything complicated. Attackers can hide their attacks inside innocent-looking data by encoding it. Back-end systems may recognize the encoding used and execute the attack. Or they may decode the attack and pass it on to a system that's vulnerable to it.

Attackers may use multiple different encoding schemes, or even double encode to tunnel their attacks through innocent systems. There are dozens and dozens of encoding schemes and no way to tell which schemes will be recognized by the interpreters you're using. This makes recognizing attacks very difficult, if not impossible.

Every time you send or receive data both sides have to know the intended encoding. Never try to make a "best effort" attempt to guess the right encoding. You can't prevent an attacker from sending data with some other encoding through the channel, but you don't have to execute it. Here are a few examples:

Set HTTP encoding in the header:

   Content-Type: text/xml, charset=utf-8

Use a meta tag in the HTML:

Set XML encoding in the first line of XML documents:

<?xml version="1.0" encoding="utf-8"?>

You can read the full post here.

Ajax security is very important in developing your Ajax applications and it is something that many developers overlook.

[...] post by David Hurth delivered by Medtrials and [...]

[...] Ajax Security By David Hurth Ajaxonomy - The Study of Ajax… - http://www.ajaxonomy.com [...]

Visual WebGui introduces a revolutionary approach to AJAX with its ‘empty client’ concept. According to this approach the client never consumes data or services directly, since all of the application logic, UI logic and data access is handled on the server. The client simply connects to the “view” on the server, via a standard protected HTTP/HTTPS pipeline, and the "view" is projected on the browser by Meta Data and therefore never compromises security.

Since there is no data, no logic and no open services on the client, the 'empty client' approach presents a highly secured alternative to conventional client side AJAX and introduces a new level of security of web applications in general.

Visual WebGui launches a Security Challenge daring to break into a Visual WebGui application for a $10,000 prize.
Learn more: www.VisualWebGui.com

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <pre> <div> <blockquote> <object> <embed> <img> <param>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Copy the characters (respecting upper/lower case) from the image.