I have a coding whiz as a colleague on some freelance assignments and he not only codes well, but also plays great badminton and sometimes seems ultra cautious(and here is someone who would agree). The other day we were discussing the use of AJAX for some local web page activities, and Paulo would have none of it. I said to Paulo –” you use GMail and JotSpot and really like both. And you and I know that both use AJAX big time in their implementations – so how can you now think of rejecting AJAX for our small app which will not even be external customer facing ?”. Paulos reply was that AJAX was security immature and that unless you get AJAX code from a trusted source like Google or Jotspot (now a part of Google) – then you run a security risk.
I could not believe Paulos stubbornness so I tried a different approach. I said “this is a small application, and all we will be doing is using AJAX for local desktop use – nearly zero risk of being hacked.” Paulo agreed but then countered that if we used the AJAX model locally other freelancers who came in to expand the system could use our AJAX base more broadly for external server communications. Since Paulo was responsible for the backend of the system I let it go and we coded in JSP and I thought nothing about it until this item about JavaScript security risks from Martin Heller in Infoworld in early January 2007:
Now the full details of the problem is from a paper at the Chaos Conference by Stefano Di Paola and Giorgio Fedon – but the security threat is very real as Martin points out. The prototype construct is used all over JavaScript code, especially for larger object enabled systems as in the case of AJAX frameworks. And even if prototype is not used the code remains vulnerable for JavaScript 1.5 and earlier versions by direct hacking of objects.
In general, this problem is also present in AJAXs RIA competitor Flash because ActionScript versions 1,2, and 3 where the prototype semantics have been borrowed and retained throughout. Now some may argue that Flash is less vulnerable to prototype contamination as the Flash .swf container is “compiled code” with container hashes for added protection. However ghosting and dynamic loading of Flash .swf do present opportunities for “exact substitution” by malevolent hackers.
As for JavaScript 2.0, the prototype functionality was also retained as can be seen here. In sum, this looks like a case of “Houston, we have a problem in several popular RIA language/script implementations.” What this problem may do is force rethinking dynamic scripting capabilities with special attention on JavaScript. The reason JavaScript will get attention is that it forms the basis for all AJAX frameworks and is the prototype (ohhhh …. bad pun) for Flashs ActionScript straight through to version 3.0. What this problem may do is also break the logjam on JavaScript where version 2 has waited in limbo for several years awaiting language and browser vendors to update their JavaScript implementations.
Now just as an aside for Java-based RIA aficionados like Droplets and Nexaweb, Java does not have this same problem. And as for Paulo, he was doubly right. Other freelancers came in recently on “our” project and they have implemented external, server-based routines using AJAX.
(c)JBSurveyer 2007
If you liked this, let others know: 
Slashdot 
Digg 
del.icio.us 
reddit 
newsvine 
Y! MyWeb