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 google.com 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*the.net. Special to Dark Reading