Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Breadth & Depth

3:30 PM -- There's been a lot of talk lately about Ajax, Ruby on Rails, and dynamic Flash applications. Web applications are cluttered with dozens of technologies amongst dozens of protocols and standards. Assessing relative risk is a daunting task for even the most experienced Web application security veteran.

Over the last few months I've heard a lot of theories about how these
types of complex dynamic applications create more risks to application
security. Frankly, I'm just not sold on the idea that adding additional layers on an application adds security risk on a line-of-code by line-of-code basis. However, there are hidden risks that people are largely unaware of.

There's a concept in application security that deals with muddying
waters. Keeping the security waters un-muddied is a matter of having all security dealt with in single choke points where they can do the most for the least amount of work. It also makes the application easier to secure, as there are fewer places that aren't covered by your choke points. A simple example of this is a database access layer that
restricts access to your database for all incoming requests so that no
SQL injection attacks are possible.

The muddying comes in when you apply multiple technologies to a single
application. It's not so much that you have to worry about the
particulars of the language itself, but rather that instead of just
being able to place the ownership of the security issues on one area of the code, you must disperse the responsibility amongst several
technologies. Each technology may have very different ways of dealing
with the security risk at hand. For instance, code that is built into
dynamic JavaScript must be encapsulated and dealt with in a very
different way than HTML, and vice versa.

By adding a layer of additional code on top of the application, you must ensure that it is secure. When I found the security issue in Google several months ago, it was an issue of how JSON was being rendered directly. There was no way for the application to render the code to the page because of well designed filters in the JavaScript itself. However, it was irrelevant, because the JSON could be rendered directly by getting users to click on a link, allowing me complete access to the domain, to steal cookies, phish passwords, or anything else I would have liked to do. Thankfully I'm not one of the bad guys!

The point is that you cannot rely on a single point to protect you from all security issues when you muddy the waters with multiple types of code that must interoperate and individually protect themselves, requiring multiple points by which the programmers must identify and harden. So while Ajax is not going to make you insecure, it will increase the attack surface area that developers must protect.

— RSnake is a red-blooded lumberjack whose rants can also be found at Ha.ckers and F* Special to Dark Reading