Feeds

Reduce your exposure to AJAX threats

Three-step guide

Securing Web Applications Made Simple and Scalable

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.

The smart choice: opportunity from uncertainty

More from The Register

next story
BMW's ConnectedDrive falls over, bosses blame upgrade snafu
Traffic flows up 20% as motorway middle lanes miraculously unclog
Putin: Crack Tor for me and I'll make you a MILLIONAIRE
Russian Interior Ministry offers big pile o' roubles for busting pro-privacy browser
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
Manic malware Mayhem spreads through Linux, FreeBSD web servers
And how Google could cripple infection rate in a second
How long is too long to wait for a security fix?
Synology finally patches OpenSSL bugs in Trevor's NAS
Don't look, Snowden: Security biz chases Tails with zero-day flaws alert
Exodus vows not to sell secrets of whistleblower's favorite OS
Roll out the welcome mat to hackers and crackers
Security chap pens guide to bug bounty programs that won't fail like Yahoo!'s
prev story

Whitepapers

Top three mobile application threats
Prevent sensitive data leakage over insecure channels or stolen mobile devices.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.