Experts Say Ajax Not Inherently Insecure

An anonymous reader writes "Jeremiah Grossman (CTO of WhiteHat Security) has published Myth-Busting - an article dismissing the hyped-up claims that AJAX is insecure. He says: 'The hype surrounding AJAX and security risks is hard to miss. Supposedly, this hot new technology responsible for compelling web-based applications like Gmail and Google Maps harbors a dark secret that opens the door to malicious hackers. Not exactly true ... Word on the cyber-street is that AJAX is the harbinger of larger attack surfaces, increased complexity, fake requests, denial of service, deadly cross-site scripting (XSS) , reliance on client-side security, and more. In reality, these issues existed well before AJAX. And, the recommended security best practices remain unchanged.'"

Strawman

Way to make up an issue and then show off attacking it.

Vulnerability in practice is just as bad or worse

When something is this widely adopted and this tempting to rapidly trot out (because PHBs are desparate for that shiny stuff as they head to the next board meeting), the fact that you're suddenly introducing a wildly more complex set of GETs and POSTs and layered hoo-hah on an interactive page (never mind the purpose of the app) means that all of the stuff that always introduces vulnerabilities will be there, multiplied by the new complexity. And, of course, with a smaller crowd of talented, experienced people truly able to quickly size up the risks as something goes live.

It's not the (non-existent?) inherent security problems in the bundle of techniques we're referring to, it's the weaknesses that show up in the practice of shoddy implementation, cheezy hosting platforms, etc. There's nothing wrong with AJAX, it's the AJAX-envy among less sophisticated operators that we have to worry about. We just have to quit saying it's 'easy' to implement, because none of the underlying bits and pieces are (in terms of being bullet-proof) are 'easy,' and a browser-agnostic soup of a couple dozen of those bits is that many times harder.

Best security practices

From TFA: "What can I do to protect myself as a user?"

> One of the best ways to protect yourself is to turn off Javascript in your browser settings.

The more things change, the more things stay the same.

Best security practice has always been to turn off ActiveX, Javascript, Flash, and any other means by which untrusted executable content is automatically downloaded to one's machine and then automatically executed.

Re:Best security practices

Sites should function without script for accessibility and only the bad guys would stand to lose from a more realistic approach to security by browser vendors.

When you can write a new version of Google's spreadsheet program that uses only HTML and CSS, I'll go along with the idea that we should get rid of javascript.

Re:Best security practices

Downloading the HTML via WGET and reading it VI is the only secure way to surf the net.

Yeah...

...and in the movie Mars Attacks! the Martians kept telling the U.S. government they weren't going to invade. Hmmm.. Maybe THAT'S where the Bush administration got their inspiration from for the premptive strike. Certainly would explain a lot...

Existing Best Practices

Yup, existing best practices takes care of all of the security issues for AJAX: disable Javascript. Problem solved.

With open-source, you can examine the source before you run the program, and can take steps to ensure that the program you run is compiled from the source you examined and that it's unchanged since the last time you ran the program. There's no good way to do the same thing with Javascript ... you're expected to nod agreeably when the website says "just trust us".

"Not trusting someone who /demands/ that you trust them without evidence" should be the #1 best practice out there.

Where the heck did this hype come from?

And who is honestly saying these things? Am I alone in not seeing the percieved risks here?

All AJAX really gives you is that first 'A': asynchronous. All the other underlying mechanics of client-to-server communications over HTTP apply. This means that your security checklist is absolutely no different than using a good old-fashioned [form].

To slam AJAX as insecure as a technology is just bad thinking to begin with - it's a tool, that's all. Whether or not it's used in a secure fashion is really more a best-practice and/or training issue.

Besides, didn't we already go over all this when Web-Services were a big deal?

That article was a mixed bag

There's some justice in saying that Ajax doesn't introduce any new problems over and above Javascript, but that is faint praise and doesn't allow for the fact that buzzword-compliant organizations are now creating more web sites that require Javascript.

His advice about keeping web apps secure is sound and practical but incomplete. The last OWASP conference I went to, one of the speakers pointed out that there's an Ajax development toolkit out there in which you can't tell a priori whether a piece of functionality you program will end up on the client or on the server. "Avoid toolkits like that" should be on the list of security precautions.

>AJAX is a web browser (client-side) technology. It does not execute on the server.

The XMLHttpRequest certainly does execute on the server and allows a range of parser attacks that you were less likely to get with other technologies. Which would you rather validate, a set of CGI parameters or a blob of XML?

Fortran in Haskell

This appears to be yet another case of, "You can write Fortran in any language" where the author ignores that some technologies make it much easier to write Fortran than others. Obviously with a number of things you can avoid the bad stuff by avoiding the bad stuff -- but when bad stuff is the default mode of operation, rather than the odd, explicit corner case then yes... there's an issue.

Put another way, it's a lot easier to not write Fortran in Haskell than it is in C.

Yeah -

It's your fault, jackass!

deadly cross-site scripting

I swear officer, he was alive a minute ago. He was just sitting in front of his PC trying to check his bank balance!

Attack surfaces plural

This is a worthwhile article to keep on file. Its offers a clear and practical analysis of AJAX in terms of security principles, though biased toward server security and dismissive or incorrect with respect to client security. Read it critically.

Indeed AJAX is not a new technology but a set of existing technologies in combination. Here's the issue though. JavaScript is a known point of vulnerability for clients. Secure clients may be hardened against attacks by disabling JavaScript. Good web design has therefore always required that pages function correctly without use of JavaScript, rather than forcing a client to be configured for greater vulnerability in general for the sake of accessing one website in particular.

But AJAX pages, by definition, unconditionally require JavaScript on the client. Hardened clients need not apply. If your security policy is not concerned with client security, or if your operation can afford to exclude some client systems, then you can regard the security of the AJAX client, as an attack surface, to be out of scope.

However, a general analysis of AJAX security also has to consider tightly integrated applications where client and server security are interrelated. Many web services exist for account administration, inventory control, system configuration, and other operationally critical forms of information management. Note how these activities are controlled by the client. In this context it's fine for servers to perform client authentication and input checking, but the advice to "never trust the client" completely misses the point of developing these applications.

Therefore, the article is incorrect to suggest that AJAX solutions need not be concerned with client security. Moreover, it's evident that AJAX creates a larger attack surface on the client. There are environments where you can decide to exclude these issues from consideration. In a general analysis of security, you cannot.

My experience

The first web game that I wrote in PHP 3/4, called Merchant Empires (www.merchantempires) was hacked mercilessly. Of course, those were the good old games of the web when SQL injection was possible on a large number of main stream sites.

My second web game, called Grand Strategy (www.denizengames.com), is a full fledged Ajax application (written using DWR and Dojo) and the game hasn't been hacked (that I know of). Of course, I can only hope if those same Russian hackers hit it, they are as kind as they were before and they send details after they get tired of toying with the game.

Gmail vs. Outlook Web Access

FTA: Furthermore, in my experience, AJAX-enabled web applications are no more functionally complex than standard web applications. ... Gmail is less complex than Outlook Web Access.

Gmail and OWA both use AJAX. Heck, Microsoft created the XMLHTTPRequest object. Comparing Gmail to OWA to prove this point just doesn't make sense.

If Bandwidth Were Infinite...

then AJAX would not exist.

In the long term bandwidth will be (practically) infinite and whether processing is done on the server or the client will become irrelevant except that server-based processing will always be more secure and controllable.

AJAX is a temporary tool to enhance client-server interactivity until almost everyone has a high-speed Internet connection. Once that occurs such hacks as AJAX will disappear.

And good riddance! Because of it's arcane nature, security problems and greater development cost, I look forward to the day when AJAX fades.

Lack of understandig

I think that there are none "inherently insecure" things. Anything can get somehow secured. I think that given a program that is specifically designed to be insecure one can still somehow (maybe by modyfiyng the enviroment it runs it or whatever) relatively secure. Well security in fact is quite relative.

So it is not that using AJAX itself is insecure. It is that probably lot of people will try to make AJAX apps since it is trendy right now. But AJAX *is* quite complicated or just new stuff. Somebody without experience and deep understanding how these things (and for me they are quite complex) works will probably make mistakes using some code generator and generally don't understanding fully what is going on.

It is nothing new. Security is mostly about knowledge and understanding. You can't make something secure that you do not know deeply and don't understand.

It is not technical (like this technology is insecure) issue IMHO.

Oh good golly, come on !

You allow excessive processes to be run on client side, yet you say its secure ?

anything relegated to client side is exploitable to hell.

I'll tell you now and I'll tell you again

HTTP doesn't support client-side security. Not a single server supports client-side security. The only thing you can do is try to secure a client but you can't rely on the client not being compromised.

Avoiding XSS and Drive-by scripting

The original article is right that there aren't any really new problems with AJAX apps, but they are different, so some mistakes are easier to make and some mistakes are harder.

Two of the mistakes that I've found easier to make with Ajax apps are XSS and drive-by-scripting attacks.

XSS attacks arise when a user can put text on your site that runs with the domain privileges of your site. Once they can do that, it's easy to steal user information, cookies, etc. and send it back, or make modifications to user data on their behalf.
The way to avoid XSS attacks is by properly escaping all text converted to html or javascript. The difficulty arises for two reasons
1) DOM manipulation is just too slow, so you end up having to generate html. Generating html safely requires keeping a lot of escaping conventions in mind.
2) Users often want to enter rich text, so you end up passing around some strings that are plain text and some that are (hopefully properly sanitized) html.

The first can be addressed by templating -- use something PHP or JSP like to generate your html. You can make it fast, and make it obvious what's escaped and what's not. It's not a silver bullet, but it makes the problem manageable. If you want to get fancy, you can make it smart enough to know that substitutions in HREFs should be encodeURIComponented, and substitutions in onClick should be escaped as javascript strings. Just make sure that people don't have to work around the system for those rare, but necessary cases where they know they've got safe content. It's much better for there to be clear, easily-audited exceptions to the rule than for people to have to bypass your system entirely to "fix" a critical bug late on Friday night.

The second problem is harder. A good static type system for javascript might allow different types for Strings that contain plain text vs. html vs. CSS vs. javascript. Then some simple static analysis could warn you when you add plain text to html to compose a string. Unfortunately, there aren't many such tools, so my recommendation is to use naming conventions. I know everyone hates anything that smacks of Hungarian notation, but do you find it easier to spot the bug in
var name = document.form.myform.elements.myinput.value; ...
nameNode.innerHTML = '<div>' + name + '</div>';
or
var nameAsText = document.form.myform.elements.myinput.value; ...
nameNode.innerHTML = '<div>' + nameAsText + '</div>';

In the second case, you're documenting what a variable contains, so someone reviewing the code has a hope of knowing what escaping schemes need to be applied when.

Drive-by-scripting attacks occur when someone malicious finds that you're using some neat JSON-like javascript to communicate between the browser and the server. It seems like a good idea and it is, because eval is fast, and you need every bit of speed because javascript interpreters are dog-slow.

And the cross-domain policies ensure that noone can do an xml-http-request and get back the javascript, and if they do, it's safe because it has no side-effect.
Unfortunately, anyone can write a script tag, and they can replace the Array constructor. So if your message contains an array, and they can trick your user into visiting their site, then you're screwed.

What do you do? Instead of sending over
[valuable, user data]
send over
while(1); [valuable, user, data]

That way, the constructor for the data they were trying to steal never gets executed, and no other javascript on their site executes, so hopefully the user realizes that that's not a good site to visit.

How does that help you? Well, since you're using XHR, and obeying the cross-domain policy like the fine upstanding citizen you are, you can just get the response text, and strip the "while(1);" from the front and go about your merry way.

Finally,

It's not that it's inherently insecure

It forces you down a design path that leads to insecure code. If you want to plug every hole, you've got to do ten times as much work.

I wish there was some HTML attribute or some simple way of telling the user's browser things like "Don't let any of this part of the DOM tree be scripted from outside", or "this script is only allowed to do AJAX from these domains". Sort of like SELinux for HTML.

Re:Did someone say Mythbusting?

Where are the pics of Kari?

this thread needs more pics of Kari