« Previous article — Next article »

OWASP meetings are depressing

April 7th, 2009 Posted by D Webber

Our local OWASP chapter met last night for a talk on “rich internet applications” (meaning Ajax, Flash, MS Silverlight, Adobe AIR etc.).

It was grim. The talk (given by this guy) mainly focused on how business logic, passwords and encryption keys are being embedded into client-side Flash applications, under the mistaken assumption that compiled Flash is an impenetrable black box.

But as we’ve known for decades, everything client side can be tampered with. Flash in particular can be easily decompiled into original source code, often exposing all manner of vulnerabilities.

By now most web developers understand basic browser security issues like hidden fields aren’t and Javascript can be viewed and changed by the user. But switch to a client-side environment where the code is “compiled” like Java applets, Flash, MS Silverlight or Adobe AIR and many developers reset to a default mindset that seems to be:

  1. The “compiled” code and data cannot be viewed or altered.
  2. Communications between a “compiled” client and the server cannot be viewed or altered.
  3. Only my client can communicate with the server and use it’s exposed APIs

It may be a shocking to learn, but even compiled C code can be decompiled with at least some fidelity to the original source. Bytecode compiled apps like Flash and  Java are much easier: flash apps can be returned to near-original source code with SWFScan, Java with Cavaj and others. And no need for fancy tools when plain text (e.g. embedded passwords) can be pulled from any binary using the good old Unix strings command.

Traffic between client and server is easily intercepted with Paros or WebScarab (yes, even when encrypted by SSL), and these tools are also great for mapping server-side APIs for which an attacker can write their own code to invoke the methods.

AJAX apps are not compiled, but widely-used optimizers like YUI compressor seem to lead to that “security through compiler” mindset. I even had a developer argue the sensitive code in their Javascript library was secure because it was “stored on the server” (as an external .js file).

It’s not just web apps though. I’ve seen the same assumptions in all fat client code, whether elderly Powerbuilder and Visual Basic apps or the latest .NET, C or C++. However, most of those are deployed in the semi-trusted environment of an organization’s intranet. Still vulnerable, but at least not exposed to the entire universe.

Is there something special about web development that prevents improvement? Sometime in 1998 I wrote Writing Security Web Applications and 11 years later the same mistakes are being made, both in regular web applications and “rich” ones.

Only now instead of passwords and encryption keys being stored in the clear in hidden form fields and cookies, they’re embedded in Flash, along with business logic talking directly to internet-exposed server APIs.

As I said, OWASP meetings are depressing.

Posted in Web security |
Tags: , , ,

Comments for this article are closed.