Fighting Injection Attacks with StringBorg

Martin Bravenboer writes about a new way to fight code injection attacks. The most infamous example of this kind of attack is the SQL injection, which is caused by careless developers simply inserting a string from user input into their program, like this (PHP example):

$results = mysql_query("SELECT * FROM users WHERE "
. "userid = {$_GET['id']}");

When you see something like this you should start screaming “no no no!” immediately. This query works fine if $_GET[‘id’] contains “3” as its value, but what if it filled in by a malicious user who fills in “3; DROP TABLE users;” Woosh, and your users table is gone.

The most obvious solution to this problem is escaping and checking your inputs. If you expect an integer input, check if it actually is. However, a programmer is still human (or so they clame) and is bound to make mistakes.

StringBorg attempts to solve this problem by adding special syntax for a “guest language” in the “host language”. The host language in the example above is PHP, the guest language is SQL. StringBorg introduces some new syntax for the different guest languages. It will most likely act as a precompiler. You write the code with special syntax in one of the supported languages (I think Java and PHP are currently supported), StringBorg takes this code and transforms it into normal safe PHP or Java code. Now what does this code look like? Here’s a snippet in Java:

String s = "'; DROP TABLE Users; --";
SQL e = <| username = ${s} |>;
SQL q = <| SELECT password FROM Users WHERE ${e} |>;

More examples can be found here.

In itself I’m a fan of integrating guest and host languages more. The C# team is doing very interesting work on this with LINQ, which will likely also solve this injection problem. However, that’s just C# (and VB.NET). StringBorg, although only addressing the injection problem, is an essentially generic solution. It could be implemented for any guest and host language in a more-or-less straight-forward way (assuming you scribble programming language grammars during your lunch break). And what’s nice is that you only have to do it for each guest programming language once. StringBorg already has support for shell, SQL, LDAP and JavaScript as guest languages, so if you wanted to add these safety features to, say, Python, you would only have to add support for Python as a host language and you’d get all this guest language support for free.

But let’s do a reality check. This is still very much an academic project. You can’t really expect the mainstream public to first compile and install 7 pieces of software that StringBorg depends before installing StringBorg itself. Furthermore these features will break IDE support for that language. I think Eclipse would not really appreciate my nice <| bladiebla |> notation. So there should be IDE support available too. If the StringBorg authors are serious about this project and want “normal” people to use it, it should come in a self-contained package. In case of using Java as a host language, it should come with IDE support and Ant tasks. And of course: docs, docs, docs!

I think StringBorg in itself is a interesting project, but it’s quite far from being ready from actually being used by non-academic developers. You can find the StringBorg website here, but it does not have a lot of information. Watch Martin Bravenboer’s blog for more information on StringBorg.