Feeds

Reduce your exposure to AJAX threats

Three-step guide

Beginner's guide to SSL certificates

Fundamentally, there's nothing terribly new about the problems posed by Asynchronous JavaScript and XML (AJAX) when it comes to security, we just need to apply some good old security principles to this new technology.

The problems occur because, unfortunately, there are an awful lot of devils hidden inside the details.

One major security challenge for AJAX applications is that moving your code to the client involves a ton of data formats, protocols, parsers, and interpreters. These include JavaScript, VBScript, Flash, JSON, XML, REST, XmlHttpRequest, XSLT, CSS and HTML in addition to your existing server-side technologies. As if that wasn't enough, each of the AJAX frameworks has its own data formats and custom framework formats.

An application's "attack surface" approximates the ways in which an attacker can cause damage to your application or its users. The more technologies you use, the bigger your attack surface.

Here, then, are three simple ways of reducing your AJAX application's attack surface:

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"?>

Nail it

Remember, your AJAX application's attack surface is under your control. The choices you make can drastically affect the size of your application's attack surface. Be sure you ask questions about where your code runs, what data formats and protocols are involved, and which parsers and interpreters get invoked. And most importantly, be sure to nail down how you're going to keep code and data separate.®

Jeff Williams is chair of the OWASP and chief executive of AspectSecurity.

Choosing a cloud hosting partner with confidence

More from The Register

next story
Apple's new iPhone 6 vulnerable to last year's TouchID fingerprint hack
But unsophisticated thieves need not attempt this trick
SMASH the Bash bug! Apple and Red Hat scramble for patch batches
'Applying multiple security updates is extremely difficult'
Oracle SHELLSHOCKER - data titan lists unpatchables
Database kingpin lists 32 products that can't be patched (yet) as GNU fixes second vuln
Who.is does the Harlem Shake
Blame it on LOLing XSS terroristas
Researchers tell black hats: 'YOU'RE SOOO PREDICTABLE'
Want to register that domain? We're way ahead of you.
Stunned by Shellshock Bash bug? Patch all you can – or be punished
UK data watchdog rolls up its sleeves, polishes truncheon
Ello? ello? ello?: Facebook challenger in DDoS KNOCKOUT
Gets back up again after half an hour though
Desperate VXers enslave FREEZERS in DDoS bot
Updated Spike malware targets Asia
Heatmiser digital thermostat users: For pity's sake, DON'T SWITCH ON the WI-FI
A stranger turns up YOUR heat with default password 1234
prev story

Whitepapers

Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
Intelligent flash storage arrays
Tegile Intelligent Storage Arrays with IntelliFlash helps IT boost storage utilization and effciency while delivering unmatched storage savings and performance.
Beginner's guide to SSL certificates
De-mystify the technology involved and give you the information you need to make the best decision when considering your online security options.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.
Secure remote control for conventional and virtual desktops
Balancing user privacy and privileged access, in accordance with compliance frameworks and legislation. Evaluating any potential remote control choice.