Free ESG report : Seamless data management with Avere FXT

Whatever you think of "Web 2.0" (it's really not mandatory to release everything in permanent beta) you probably thought that this generic approach to mashups, Ajax and all that good stuff didn't change the usual coding "good practice" rules much.

Well, Brian Chess of Fortify Software says you're wrong. Although Web 2.0 style applications can be written securely, there's a temptation to handle all the data in JavaScript and that, he claims, can be seriously insecure.

Fortify calls this new vulnerability "JavaScript Hijacking" and it lets an attacker pose as an application user, with access to sensitive data transmitted between application and browser using JavaScript as the transport mechanism. This means the false users may be able to "buy and sell goods, trade stocks, adjust security settings for an enterprise network or access and manipulate customer, inventory and financial information", according to Fortify Software's press release.

The attack uses a <script> tag to get around the "Same Origin Policy" enforced by web browsers - traditional web applications aren't vulnerable as they don't use JavaScript for data transport.

Out of 12 popular Ajax frameworks analysed by Fortify – Direct Web Remoting (DWR); Microsoft ASP.NET Ajax (a.k.a. Atlas); xajax; Google Web Toolkit (GWT); Prototype; Script.aculo.us; Dojo; Moo.fx; jQuery; Yahoo! UI; Rico; and MochiKit – only DWR 2.0 implements mechanisms that control JavaScript Hijacking. The rest neither provide protection nor mention the possibility in their documentation.

Download Fortify's advisory on this issue here.

Obviously, this vulnerability needs to be accepted by the Web 2.0 community as a whole but Jeremiah Grossman, CTO of WhiteHat Security has already verified its reality in some circumstances.

"New technology often leads to new risks and opens unforeseen avenues of malicious attack," he says. "Once understood, developers need to ensure the necessary safeguards are in place when they break new ground. Those responsible for the security of Web 2.0 deployments need to take this issue seriously and implement the steps necessary to resolve the issue before the risk results in an incident."

The solution to this issue really lies in the frameworks and any sample code they ship. It's not enough to make sure that your framework can be made secure; any code examples you provide must exemplify this "good practice" where appropriate. Luckily, Chess finds that most frameworks providers are receptive to this view and will address the problem in their next release (as will Fortify, in the next release of its security analysis tools); although a few people still adhere to the rather old-fashioned "not our problem if people are stupid" view.

However, probably many Web 2.0 programmers don't use the frameworks and perhaps leave the "x" off Ajax and handle all their data in JavaScript. These people really need to check their code for this vulnerability and fix it.

Or, perhaps, do something different. According to Chess, JavaScript security has been a bit of a disaster since its inception, probably because it has been pushed well beyond what it was originally intended for. Adobe's Flash is much better architected for security (not perfect, but better), he says, and perhaps that makes it a better basis for Web 2.0 style programming. ®

5 ways to reduce advertising network latency