Is Your AJAX App Secure? 142
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 (Score:4, Insightful)
In the article, he addresses a token used to generate random strings: 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 (Score:5, Insightful)
But we already know this... (Score:2, Insightful)
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 (Score:5, Insightful)
Comment removed (Score:5, Insightful)
Re:Enough with "Enough already" (Score:3, Insightful)
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" (Score:3, Insightful)
semantics of GET and POST (Score:5, Insightful)
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:
And in section 9.5, about POST requests:
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 (Score:4, Insightful)
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.