|
 |
Recent
Articles |
Spry 1.5 - New "Session Expired" Support I blogged about the Spry 1.5 preview a few days ago and finally made time to whip up a quick demo of one of the new features - Session Handling
First and foremost...
$65m, Bad Use Of Javascript Javascript is one of my favourite web technologies. When I stop to think how the Internet would be without Javascript I can't help but think how much less productive and enjoyable my days would be. Take for instance...
Speed Up Page Load Times W/ Mod_deflate In a report from November, 2006 Akamai and JupiterResearch concluded that 4 seconds is the threshold an online shopper is willing to wait for...
LAMP Development - Backbone Of The World Wide Web The World Wide Web has always been an entity that needed a little bit of help in order to run effectively. As long as there has been the Internet, there have been tools to help keep it running well. More times...
Frames And Model-Glue Dan asked the following question about frames and Model-Glue: Basically, my question is about using frames within my application. I basically want to use a...
How Many Rows Of Data To Use With Spry Bob sent in an interesting email to me: Ray, we're about to use spry on one of our sites but i was wondering what you would recommend to be the max records to return in the XML? We may have 2,000 records returned at...
SEO-Friendly Ecommerce One of the major drawbacks when taking the dynamic approach to web development is the resulting product not being optimized for the search engines. A number...
|
|
 |
|
04.04.07
Love Ajax? Hate The Exploits
By David A. Utter
Bringing certain content-updating behaviors to web pages without reloading them has been a key piece of the 'Web 2.0' online application meme; it now appears the criminals could have a way to break them open too.
First Jikto hits the web, and now this. JavaScript hijacking vulnerabilities in a number of popular web application frameworks, including ones from Google, Microsoft, and Yahoo, could be a threat until their libraries receive fixes.
Fortify Software posted an advisory about the JavaScript issue. Their description of the problem resembles what Jikto can accomplish. Here's the Fortify summary:
The attack works by using a <script> tag to circumvent the Same Origin Policy enforced by Web browsers.
This is Hoffman's discussion of Jikto, a JavaScript based web scanner that has the potential to silently install on a web browser and probe websites for cross-site scripting vulnerabilities:
As my Shmoocon presentation slides discuss, Jikto bypasses the "Same Origin Policy" by using a proxy website like the-cloak, proxydrop, Google Translate, etc.
Part of Hoffman's source code for Jikto has been released on the Internet. Fortify took aim at several frameworks in their analysis of the possibility for a JavaScript threat to exploit them:
We analyzed 12 popular Ajax frameworks, including 4 server-integrated toolkits - Direct Web Remoting (DWR), Microsoft ASP.NET Ajax (a.k.a. Atlas), xajax and Google Web Toolkit (GWT) -- and 8 purely client-side libraries -- Prototype, Script.aculo.us, Dojo, Moo.fx, jQuery, Yahoo! UI, Rico, and MochiKit. We determined that among them only DWR 2.0 implements mechanisms for preventing JavaScript Hijacking.
JavaScript transports data, making it possible that an unauthorized application could read the data going to a legitimate site. If that data includes confidential information, then a hijack can bring that data to another party.
The concept was demonstrated quite painfully to Google early in 2006. Jeremiah Grossman detailed a GMail flaw that could reveal someone's GMail contact information. Google fixed that problem shortly thereafter.
Frameworks will be updated to resist JavaScript hijacking attempts. Ajax developers will want to verify their applications can resist potential break-ins and be aware of the ramifications of the
problem:
The loophole in the Same Origin Policy is that it allows JavaScript from any website to be included and executed in the context of any other website. Even though a malicious site cannot directly examine any data loaded from a vulnerable site on the client, it can still take advantage of this loophole by setting up an environment that allows it to witness the execution of the JavaScript and any relevant side effects it may have. Since many Web 2.0 applications use JavaScript as a data transport mechanism, they are often vulnerable while traditional Web applications are not.
About the Author: David Utter is a staff writer for WebProNews covering technology and business.
|