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

Vulnerability in practice is just as bad or worse

[ScentCone]

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.

Existing Best Practices

[Anonymous Coward]

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?

[Anonymous Coward]

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?

Re:Best security practices

[hotdiggitydawg]

Is javascript really that horrible?

Yes.

I know it can be used in annoying ways, how difficult is it to do something outside of superficial changes to the browser?

A computer is practically worthless to most people if you cannot use it to browse the internet nowadays. So, forget about things outside the browser, and start thinking about user-website interaction through the browser. You can rely on so many trivial vectors to build an effective attack to manipulate a user's browsing experience, and in the case of most sheeple they'll be none the wiser. And the proliferation of it with the latest AJAX fad simply means more people are likely to have it on globally by default rather than have a degraded browsing experience.... as well as more sites with forms and other input vectors for XSS and other attacks too.

It seems like you should be able to have a simple scripting language that can only really manipulate superficial aspects of web pages without any real increase to the security risk. I thought this was what javascript was. Am I wrong?

Largely, you're correct. But it's scope of manipulation is such that it can be effectively used to dupe gullible and/or less tech-savvy users into doing something foolish... It's an effective tool in the right hands, in as much as a hand-grenade is. Give it to someone who has no idea how it functions, with a "Pull Me" tag on the ring-pull, and the consequences will eventually be dire... even if it's not the fault of the grenade itself.

Re:Best security practices

[owlnation]

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.

Of course that is true. It's just that it's a real pain in the ass. Well, no mortal being requires ActiveX for any reason, and I block the horror that is Flash with the (truly joyous and wonderful) Flashblock extension - and rarely ever allow it to run, mostly just for YouTube.

It's the Javascrpt that's the pain really. I tried using the noscript extension for a while, but it was actually more of an inconvenience than the risk of running something malicious. Seems that a very high number of webpages - and the most improbable ones too - use javascript and are dysfunctional if you disallow it. I'm not sure how to win with this - a little risk for a higher quality of web browsing? It's what I do, but not what I want.

Re:That article was a mixed bag

[leighklotz]

>Which would you rather validate, a set of CGI parameters or a blob of XML?
Um, a blob of XML. Quoting and escape characters are a big source of vulnerabilities. XML has well-defined quoting rules. CGI parameters have no structure, so structure must be done ad hoc. XML structure can be validated on the server using XML Schema or Relax, or other mechanisms.

Re:Best security practices

[nine-times]

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.

deadly cross-site scripting

[gad_zuki!]

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