Helping you drive digital innovation
Subscribe
RSS Feed of the Mendix Blog
Thanks for Subscribing

Keep an eye out for Mendix resources coming straight to your inbox.

Ajax security perception

on January 19, 2007

Share:

It seems like a month doesn’t go by without a new whitepaper detailing interesting new ways to maliciously apply JavaScript comes out. And this is fine. The problem I have is not with the papers themselves (I enjoy reading them – a lot of novel code appears there) but rather, how the media picks them up. Sure, ‘AJAX is insecure’ makes for clickable headlines, but it’s bad reporting.

When a security issue is reported the first thing that is relevant is discovering whether this is an implementation bug or an architectural flaw. Implementation bugs are fairly trivial to fix (but might have a lot of short-term impact). Architectural flaws are big time trouble.

Ajax security issues tend to fall into neither category. In fact, they usually are not even Ajax security issues. At all.

These issues generally focus on the interesting things you can accomplish as an attacker once you have already breached security by performing a form on how of malicious code injection.

There is nothing inherently insecure about Ajax applications. Their security (or insecurity) depends entirely on how the service provider manages the content delivered to the client.

So the Ajax security alerts don’t really tell us anything about Ajax security in itself. It is by now a well-established maxim in the security community that once an attacker manages to execute arbitrary code on your computer – it’s not your computer anymore. Why would anyone assume the rules have changed because the web jumped up a number in the media?

As an attacker, if you manage to inject your code into a page you can pretty much go hog-wild with the user session. But this is nothing new. For Ajax security the surface area available for attacks is fairly limited. Once you circumvent that the sky’s the limit, of course. There are any number of ways in which it is possible to get around the single domain policy found in all modern browsers. Some of these have even become a de-facto standard for Ajax developers and have lead to comments stating that such policies are pointless (I respectfully disagree here, but more on that later).

The content provider has a trusted role. A function of that role is to sanitize the content. LISP programmers and security programmers have been comfortable with the idea that code equals data and vice versa for a long time. This is for others a rather novel concept, but it’s high time everybody else caught up.

And shifting blame on end-users (a popular activity in the IT world) is simply not acceptable. As developers we have to shield end-users from technological complexity. This includes security. When people use our applications they implicitly trust us. As technology developers we have to honour that trust.

It makes for some interesting food for thought.

The bottom line is that security is hard and we can’t expect end-users to ever comprehend the complexities involved. So dumping security resonsibility on end-users is fairly stupid.

It’s up to us to write decent systems.

Subscribe to Our Blog

Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.

RSS Feed of the Mendix Blog
Derek Roos

About Derek Roos

As chief executive officer, Derek leads a pioneering team of software industry experts with the mission to bridge the gap between business and IT, making business application development dramatically easier, faster and collaborative. As a result, the company is achieving tremendous global growth and disrupting the way many of the world’s leading companies are innovating and differentiating. Derek earned a Master of Science degree in Business Administration from Erasmus University, Rotterdam. He is a highly sought speaker at IT conferences and is guest lecturer at several universities. Derek has received the Ernst & Young Emerging Entrepreneur of the Year 2012 Award. Keep in touch at @MendixCEO.

Comments are closed.