Is Your AJAX App Secure?

ShaolinTiger writes "An article looking in detail at some of the security problems with AJAX, how to find them and how to approach them or fix them. Security with AJAX is of course an important consideration as it's asychronous and a malicious user could write data back to your database if implemented incorrectly."

JUG

[eldavojohn]

Well, I'd like to say that this is an issue rarely addressed--which is alarming considering how widely AJAX is used these days.

In the article, he addresses a token used to generate random strings:

One should let the page, or some include javascript, generated on the server side, include some token that the performs some operation on which gives a result which is used in any consecutive request to the webserver. The webserver should not allow any request with another 'sequence number', so to speak.

The servers' 'challenge-string' should be as random as possible in order to make it non-predictable: if one could guess what the next sequence number will be, it is again wide open for abuse.

And I think one of the most commonly used Universally Unique IDentifiers (UUID) generators is Java UUID Generator (JUG) [safehaus.org] which can be used by any type of application that can communicate with Java libraries (most apps capable of XML messaging can anyways).

Of course, this can be no better than pseudorandom [wikipedia.org] as we all remember from our courses. :-)

How is this different

[El_Muerte_TDS]

How is this different from securing a "normal" dynamic website?

But we already know this...

[liliafan]

Pretty much everything in this article seems to be a complete rehash of things most web developers should already know, you should always be checking for possible xss/css problems, you should never depend on a cookie, never provide more information to the user than they absolutely require, always treat all input as tainted until it has been correctly validated, just because this article relates to a new technology doesn't mean it is refering to new vulnerabilities.

I am sure that some people can learn a little about security from this article but if you learn anything new reading this, you should go to any sites you have written in the past and take them down right away because chances are you already have a security hole. I recall quite recently a friend of mine was quite shocked that his AJAX application could perform sql injection attacks on his database, on looking at his code he was entirely trusting everything that came to it, I almost slapped him for that mistake.

Re:How is this different

[grazzy]

There was a new buzzword in the middle of the sentence.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Enough with "Enough already"

[Bogtha]

What, how is an article that talks about security vulns hype?

It's hype because Ajax has absolutely no bearing whatsoever on the topic at hand. Web applications that don't use Ajax are just as vulnerable to these problems as web applications that do use Ajax, and the problems are solved in exactly the same way.

Yet somehow, the submitter has managed to get a badly-written article that offers nothing novel whatsoever to the front page of Slashdot merely by arbitrarily inserting the latest buzzword as many times as possible.

Re:Enough with "Enough already"

[gregarican]

You hit the nail on the head regarding the source of my rant. The article is just cashing in on the craze and adds nothing of value to the broader subject of web app security as it applies to all of the non-AJAX world. The cashing in idea reminds me when I was a kid growing up in the 70's. When roller skating was popular all of these shows threw skating rink scenes into their episodes for no apparent reason just to cash in. Disco dancing obviously another sad, sad example too. Someone please mod me offtopic now :-)

semantics of GET and POST

[pikine]

Your remark really concludes this topic, and I think any further remarks are redundant. I just want to point out that in the HTTP specification (RFC 2616) section 13.9, it says the following about GET requests:

Unless the origin server explicitly prohibits the caching of their responses, the application of GET and HEAD methods to any resources SHOULD NOT have side effects that would lead to erroneous behavior if these responses are taken from a cache.

And in section 9.5, about POST requests:

Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields.

Thus, the only semantic difference between GET and POST is only on side effects. There is no sense in saying one is more secure than another, or one is easier to fake than another.

If we think of a web server as a function, GET requests means that, let y1 = f(x1) and y2 = f(x2), then x1 = x2 implies y1 = y2. POST requests means there exists y1 and y2, y1 != y2, such that y1 = f(x) and y2 = f(x) for some two applications of f with x. Here y, y1 and y2 are the "web pages" (more generally, resources), and x1, x2, x are the HTTP requests.

Of course, for a practical, dynamic website, the functional property does not usually hold, and that's why we have "cahce control", which attempts to establish what functional property holds under certain conditions.

ny

[Pieroxy]

I feel like I am entering the twilight zone...

This is an issue that has not changed one bit since the dawn of the web: Everything that comes in your server through an HTTP(S) request is to be assumed 'insecure' by definition. The only assumption one can make about such data is that it comes from a specific user if a proper session id is provided, nothing else.

This is a very very very common misconception in almost every application I have worked on. People (devs) seems all to think that a javascript consistency check is all it takes to ensure the user will not submit an amount too high, or anything else for that matter.

The approach is flawed because of one thing: Everything that runs out of your box can be fooled with. And JavaScript is so easy to fool with that it is a shame that ANYONE would rely on any piece of JavaScript without any security/safety check on the server side.

AJAX is just another extension based on the same principle. Anyone can fool an HTTP request. Anyone can fool a Browser. Anyone can execute arbitrary Javascript code in your browser to modify its behavior: Just type the code in the address bar.

This issue is just insane!

Is Your AJAX App Secure?: As secure as any webapp. Consistency and security checks needs to be made on every data coming in your system. Short of that, it is just swiss cheese: Full of holes.