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."

Comments

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) 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 as we all remember from our courses. :-)

Re:JUG

[stunt_penguin]

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.

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.

/relative JS noob who writes a lot of actionscript so therefore *thinks* he knows a language ;o)

How is this different

[El_Muerte_TDS]

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

Re:How is this different

[grazzy]

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

Re:How is this different

[stromthurman]

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:

If the XmlHttp-interface is merely protected by cookies, exploiting this is all the easier: the moment you get the browser to make a request to that website, your browser is happily sending any cookies along with it.

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.

Obligatory

[frodo from middle ea]

I write only static HTML you insensitive clod.

Challenges of AJAX

[cyberjessy]

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.

That statement is a little misleading, as security is not directly related to requests being asynchronous. I think what the poster meant is that being asynchronous, AJAX application make lots of calls to the back end. In a non-AJAX app, typically you fetch the data during the page load. In AJAX app, users request sections of the page to be refreshed, meaning a lot more finely grained methods to the backend are exposed.

non-AJAX:
    LoadMainPage()
AJAX:
    LoadTitles()
    LoadSections()
    LoadSummary()

Isn't that always a threat?

[MikeRT]

Hasn't the threat of a SQL injection always been a threat, dating back to the pre-AJAX days of development? Why is this even news? Proper error handling and input checking should be enough to minimize these problems.

Tinfoil Response

[0110011001110101]

You sir, are a sucker. I have found a way to beat the dreaded AJAX Google Maps insecurities. Simply put, I have a new house built every couple of years. My current house will be done in a week or so, and according to Google Maps (evil AJAX house bombing helper) my new cul-de-sac does not even exist. It's just a lot of trees... now who would bomb trees?

Please please please, buy a new house, or next time the Google Spyplane comes to take pictures, teepee your neighborhood with Tinfoil, I'm sure your neighbors will understand once you explain it to them.

Re:Sequence numbering? For sure?

[Bogtha]

The only difference between guessing this sequence number and guessing the session ID in a cookie is only that of duration

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.

Network security 101

[Aceticon]

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.

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.