A 'Swift' Kick to the Secure Development Process

I’m not a big fan of tools that make it easy for mere mortals to develop fancy Websites. While I can’t say that the democratization of the Web is a bad thing, I think that there are some things that frankly should only be done by people who know what they are doing.

I could go into a long discussion about incompetent site developers, but I suspect that most security pros already know the problems of having "secret" data residing on the client side of the client-server equation, and cross-site scripting vulnerabilities.

Recently, while reading some papers from the 2007 ACM Symposium on Operating Systems Principles, I found a paper about a system called Swift. It was developed by a group at Cornell University, with the goal of making it easier for developers to create secure, robust, and high-performance Web applications.

There is a lot to Swift, so if you want the full picture, check out the paper in its entirety. I’m just going to highlight some of the important bits.

Basically, the system allows a developer to write code using a variant of Java, applying sensitivity labels to variables. The code is then fed into a series of programs which use the labels to determine which code must live on the server, which can live on the client, and which should be in both places. It takes care of synchronization, and translates the requisite client code into JavaScript. The resulting application, while not necessarily as fast as an optimally designed system, seems to have minimal performance cost.

In addition, the system uses the Google Web Toolkit to handle the generation of the client code, which decouples the user interface from the critical security components of the system. Fixes to GWT, such as those required by the recent cross-site vulnerability will be transparently adopted by a simple recompilation.

Of course, this also means that the code is vulnerable to any bugs in the Web toolkit chosen, but the loose coupling of the front end toolkit allows the developer to choose a suitable client-side framework.

Swift is a really cool idea, but one that only real Java programmers will be able to use – which I consider a Good Thing. Further, the use of labels requires that developers specifically think about data flows in advance, which could actually do more for security than the Swift compilers themselves.

Do yourself a favor and send your development teams to check it out. Currently in version 0.9, with a license that doesn’t allow for commercial use, it is clearly not quite ready for deployment. But Swift – or something like it – needs to be part of your bag of tricks, and you’ll impress the pants off your developers by pointing them toward it today.

— Nathan Spande has implemented security in medical systems during the dotcom boom and bust, and suffered through federal government security implementations. Special to Dark Reading