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

[markov_chain]

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

That article was a mixed bag

[Beryllium Sphere(tm)]

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?

Re:Best security practices

[nine-times]

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

I'm really asking. 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? If so, why doesn't someone replace javascript with something better.

Fortran in Haskell

[Fahrenheit 450]

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.

Re:Gmail vs. Outlook Web Access

[jascat]

It amazes me how people have such a false understanding of what exactly "AJAX" is. People talk about how complicated it is, which leads to insecurity. You're making requests and passing information back to the server via GET or POST. The only difference from the "traditional" way is that rather than visiting a different page, or having a self-processing page, you're having Javascript handle the sending and updating of a portion of the page. When you look at it from this perspective, you could potentially see a gain in server side security because you could build in input validation at the client side and at the server side. In theory, you could do some small scale protection of the client by incorporating validation at the client side for what gets returned to the Javascript. It all depends on how thorough you want to make it. Laziness is going to get you anytime you are dealing with user interaction, no matter what the platform is.