Wednesday, April 5th, 2006

Is your application secure enough?

Category: Ajax, Security

Ajax security is on everyone’s minds these days, whether it’s just a simple internal application or a large, public-facing hulking app. Worrying about the security of your project is never a bad thing, and to try to help direct your thoughts in the right direction, I wanted to share this post on Darknet.org.uk that asks the question “Is your application secure enough?”

We see it all around us, recently. Web applications get niftier by the day by utilising the various new techniques recently introduced in a few web-browsers, like I.E. and Firefox. One of those new techniques involves using Javascript. More specifically, the XmlHttpRequest-class, or object.

Some web-enabled applications, such as for email, do have pretty destructive functionality that could possibly be abused. The question is — will the average AJAX-enabled web-application be able to tell the difference between a real and a faked XmlHttpRequest?

Do you know if your recently developed AJAX-enabled or enhanced application is able to do this? And if so — does it do this adequately?

The post mentions some of the problems that can be caused by lax security, usually by improper handling on the server-side. He also mentions one possible solution to handling security in your app – a “sequence numbering” kind of scheme involving a challenge string in the request (as random as possbile) sent with the request for the server to validate. He also briefly mentions Javascript injections and some of the issues it can cause as well.

Posted by Chris Cornutt at 7:43 am
9 Comments

+++--
3.4 rating from 30 votes

9 Comments »

Comments feed TrackBack URI

Whats the deal. If you made insecure apps before ajax you will continue the bad habits with ajax. Ajax is not some black magic, basically a form submit… just sent without refreshing… why is this even news worthy?

Comment by Mario — April 5, 2006

I think it is newsworthy as new developers are flocking to ajaxify their apps before even thinking about common security flaws common to all of their pages. I’m seeing alot of developers completely trusting the user input, thinking their ajax server page is only getting requests from their scripts. Security awareness is always news.

Comment by Jim Plush — April 5, 2006

I agree, its similar to any dynamic web application but a lot of people flocking to web apps don’t look at the basic issues with web transactions.

Yah AJAX is just a new way of doing old things and it cuts down on refreshing whole pages, but it does add new vectors of attack so I think it should be a consideration, especially for developers going straight into AJAX.

Comment by ShaolinTiger — April 5, 2006

I think the article was pretty terrible–the whole issue of POSTs being harder to ‘fake’ is pretty silly.

In addition, the business with cross-site request forgery is pretty off topic, especially considering XHR does not allow you to make cross-site requests.

Securing ajax apps is no different than securing any other dynamic webapp. The real risk is that with all of this exuberance and fine-grained access, people can fail to see the forest for the trees.

Comment by Ed Frederick — April 5, 2006

What do you think about this solution? The idea is unfinished since not “all” possibilities is delt with yet.

When the document is requested from the server, the server creates a uniqueId and set it as a session variable and also writes it to the documents javascript. Now the session variable is explictitly bound to the window requesting the document.

On every Ajax request made to the server, the variable has to be sent as well. Before the serverside Ajax handler does anything, it checks whether the session variable is the same as the sent variable;
– If it is the same continue (request origins from a page issued by the server)
– Else ignore the request (request origins from untrusted source)

This is the serverside…about clientside code injection:
– The drag’n drop injection can be cancelled.
– Location bar injection is possible way to inject code (open a window without location bar?)
– GreaseMonkey is a huge problem; an attacker can build custom tools to attack the server. I don’t know how this can be stopped.

This is not a definite solution but augments the security a nudge. I am very intressted in other and/or additional suggestions. This is an important topic.

Comment by Hakan Bilgin — April 6, 2006

After reading the post I discovered at “Darknet.org.uk”, I discovered that the author is talking about a similar solution though setting the “token” on the serverside as a session variable will bind the token to the visitors window, making the server-client-communication more trusted. This phenomenon seems to have escaped the author.

Comment by Hakan Bilgin — April 6, 2006

At first, I wasn’t sure… but now… I’m almost sure…

AJAX web-apps seem to be as secure as the ASP/PHP you build it on.

If you know how to manage ASP/PHP sessions properly and implement them into the pages you make your XMLHTTP calls to… your security should be as strong as it always has been.

The AJAX security scares seem to only really be relevant to coders who have no common sense and haven’t dealt with authentication-at-all-stages before. (ie. Somebody who isn’t a secure web-app developer in the first place… which is something they should learn at the server-side code stage anyway!!!)

I know… that’s kinda rough.. but I’m sure I’m not far off the truth.

(at least.. having developed lots of web-apps… that’s what I’ve observed so far.)

Comment by Tim Leonard — April 6, 2006

i agree with tim leonard. this whole web 2 ajax thing has turned a lot of web designers into programmers; which is a good thing, but the issue of security is so important it should be learnt as a fundamental.

what people are missing is that we’re still dealing with plain jane http here, nothings really changed.

Comment by sean g — April 6, 2006

It will secure if script on server is secure! (PHP secure => Ajax secure :D)

Comment by Le Khac Nhu — April 11, 2006

Leave a comment

You must be logged in to post a comment.