Feeds

Reduce your exposure to AJAX threats

Three-step guide

Choosing a cloud hosting partner with confidence

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.

Beginner's guide to SSL certificates

More from The Register

next story
Russian hackers exploit 'Sandworm' bug 'to spy on NATO, EU PCs'
Fix imminent from Microsoft for Vista, Server 2008, other stuff
Microsoft pulls another dodgy patch
Redmond makes a hash of hashing add-on
FYI: OS X Yosemite's Spotlight tells Apple EVERYTHING you're looking for
It's on by default – didn't you read the small print?
'LulzSec leader Aush0k' found to be naughty boy not worthy of jail
15 months home detention leaves egg on feds' faces as they grab for more power
Forget passwords, let's use SELFIES, says Obama's cyber tsar
Michael Daniel wants to kill passwords dead
Kill off SSL 3.0 NOW: HTTPS savaged by vicious POODLE
Pull it out ASAP, it is SWISS CHEESE
Facebook slurps 'paste sites' for STOLEN passwords, sprinkles on hash and salt
Zuck's ad empire DOESN'T see details in plain text. Phew!
prev story

Whitepapers

Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Cloud and hybrid-cloud data protection for VMware
Learn how quick and easy it is to configure backups and perform restores for VMware environments.
Three 1TB solid state scorchers up for grabs
Big SSDs can be expensive but think big and think free because you could be the lucky winner of one of three 1TB Samsung SSD 840 EVO drives that we’re giving away worth over £300 apiece.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.