Slashdot Mirror
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."
It should also be possible to add a function that you run for each http request that filters the request for common attacks, and also handles the key the parent talks about.
/relative JS noob who writes a lot of actionscript so therefore *thinks* he knows a language ;o)
So when you're writing a command to make a request, you pass your request into your pre-written function which has any request-related security processes written into it. This way things are reasonably seamless in that you don't have to worry about security every time. I think.
When the posters fear their moderators, there is tyranny; when the moderators fears the posters, there is liberty.
You are absolutely correct. The example the author provides of the .len paramter not being checked by the web app is a prime example of the kinds of problems that plague any web application, AJAX or not. Input validation, session validation, user authentication and so forth are required by EVERY web application. This part particularly irritated me:
That is true of most common methods of session management. For instance, PHP's very own built-in session management, which many people use, uses nothing more than a cookie value to manage the session. If you want to secure any web-app that uses sessions through cookies (again, AJAX or not) you'd better be using an HTTPS connection and cookies that are flagged to only be transmitted across a secure connection, and the author never touches on this point.
Add to that the whole nonsense about POST being "more secure" or "harder to fake" and it becomes clear that these are the words of a novice web programmer. And clearly this article illustrates nothing more than a web programmer's first experiences with examining the security of a web app.
But, he's linked to slashdot's main page, with plenty of AdSense links... so good for him.
I have discovered a truly remarkable sig which this margin is too small to contain.
Not quite. The article does a horrible job in explaining it, but basically, one problem is that if an attacker can induce you to view a page containing JavaScript, that JavaScript can execute GET and POST requests under your authority.
So, for example, if the attacker knows that you use Foo Webapp, then he can put up a page on his own site that executes requests corersponding to that web application, and send you a link saying "hey, look at this!" or whatever.
Here's the thing - because it's your browser making the requests, and because those requests are going to Foo WebApp's domain, your browser will send your cookies along with the request, proving that it's you.
What this means is that you not only have to prove that it's you making the request, you also have to prove that it's a request you meant to make. User authentication alone is not enough.
The typical solution to this is to additionally include another random cookie-type value as a hidden field in every form you generate. Because your attacker doesn't have access to the pages you are viewing, he won't have access to that value, so he can't construct forms that submit that value to Foo WebApp. In this way, you can reliably determine that it's a valid form submission that comes from your own web application.
None of this, of course, is dependent upon Ajax being used. Ajax is a red herring here. This security concern applies to all web applications, whether or not they use Ajax.
Bogtha Bogtha Bogtha
If a functionality is remotelly available via a public network then anybody can try to hack into your system via it.
Without AJAX: A web application serves pages via single HTTP calls, possibly with one or more parameters, per page.
- Hackers can try getting into your system via this web application by tweaking the parameters, URL, HTTP headers, etc of the requests used to retrive pages
With AJAX: A web application serves pages via a single HTTP call, possible with one or more parameters, per page. Additionaly, JavaScript embedded in the page will, typically in response to user input, send extra HTTP requests to get more information (mostly in XML or plain text format).
- Hackers can try getting into your system via this web application by tweaking the parameters, URL, HTTP headers, etc of the requests used to retrive pages or extra information.
Same principle for both, it's just that with AJAX there is a bigger number of entry points (more "handlers" for HTTP requests) since asynchronous HTTP requests from the Javascript code also require server-side code to process those requests (and generate responses).
Can you trust that nobody will try to get into your system by hand-executing an HTTP Request to a request handler that's supposed to only be called by Javascript code? Of course not!
It's the same reason why when an HTTP form is submited to the server you still check (on the server side) the validity of the information submited for that form even though your Javascript validator also does a full validation of the form before allowing the user to submit it.
Programmers that don't implement checks on information submited to the server and/or feed it directly to interpreted language engines (such as SQL query executers) without escaping or protecting it (in some other way) will ALWAYS leave gaping security holes open, AJAX or no AJAX.
An incompetent programmer is always an incompetent programmer.