The biggest threat to modern web applications is the API – Advanced Persistent Ignorance. Developers rely on all sorts of APIs to build complex software. This one makes code insecure by default. API is the willful disregard of simple, established security designs.

First, we must step back into history to establish a departure point for ignorance. As one example, almost seven years ago on July 13, 2004 PHP 5.0.0 was officially released. It included this new feature:

A new MySQL extension named MySQLi for developers using MySQL 4.1 and later. This new extension includes an object-oriented interface in addition to a traditional interface; as well as support for many of MySQL’s new features, such as prepared statements.

Of course, any new feature can be expected to have bugs and implementation issues. Even with an assumption that serious bugs would take a year to be worked out, that means PHP has had a secure database query mechanism for the past six years.1

The first OWASP Top 10 list from 2003 mentioned prepared statements as a countermeasure.2 Along with PHP and MySQL, .NET and Java supported these, as did Perl, Python, and Ruby On Rails. In fact, PHP and MySQL trailed other languages and databases in their support for prepared statements.

SQL injection itself predates the first OWASP Top 10 list by several years. One of the first description of the general class of injection attacks was the 1999 Phrack article, Perl CGI problems. SQL injection was a specialization of these problems to database queries.

So now we’ve established the age of injection attacks at over a dozen years old and reliable countermeasures at least six years old. These are geologic timescales for the Internet.

SQL injection vulns shouldn’t exist in 2011.

Coding mistakes most often imply implementation errors – bugs due to typos, forgetfulness, or syntax. People are fallible, they make mistakes.

But modern SQL injection vulns are a symptom of bad design. For six years, prepared statements have offered a way to eradicate a class of vulns. It takes actual effort to make them insecure.

In practice, prepared statements can’t handle every complex query that app owners might want to create, but it can handle the majority of them. And we still see vulns appear in simple queries that could have started out as prepared statements.

Maybe one of the two billion PHP hobby projects on Sourceforge could be expected to still have these vulns, but not real web sites. Let’s review the previous few months:

The list may seem short, but there’s an abundance of sites that have had SQL injection vulns. We just don’t have a crowdsourced equivalent for it like xssed.org tracks cross-site scripting.

XSS is a little more forgivable, though no less embarrassing. HTML injection flaws continue to plague sites because of implementation bugs. There’s no equivalent of the prepared statement for building HTML or HTML snippets. This is why the vuln remains so pervasive: No one has figured out the secure, reliable, and fast way to build HTML with user-supplied data. This doesn’t imply that attempting to do so is a hopeless cause. On the contrary, JavaScript libraries can reduce these problems significantly.

For all the articles, lists, and books published on SQL injection one must assume that developers are being persistently ignorant of security concepts to such a degree that five years from now we may hear yet again of a database hack that disclosed unencrypted passwords.

There may in fact be hope for the future. The rush to scaleability and the pious invocation of “cloud” has created a new beast of NoSQL datastores. These NoSQL datastores typically just have key-value pairs with grammars that aren’t so easily corrupted by a stray apostrophe or semi-colon in the way that traditional SQL can be corrupted. Who knows, maybe security conferences will finally do away with presentations on yet another SQL injection exploit and find someone with a novel, new NoSQL Injection vulnerability.

Advanced Persistent Ignorance isn’t limited to SQL injection vulns. It has just spectacularly manifested itself in them. There are many unsolved problems in information security, but there are also many mostly-solved problems. Big unsolved problems in web security are password resets (overwhelmingly relying on email) and using static credit card numbers to purchase items.

SQL injection is a mostly-solved problem. Using prepared statements isn’t 100% secure, but it makes a significant improvement. User authentication and password storage is another area of web security rife with errors. Adopting a solution like OpenID can reduce the burden of security around authentication. As with all things crypto-related, using well-maintained libraries and system calls are far superior to writing your own hash function or encryption scheme.

On the other hand, what does it mean that a mostly-solved problem remains so prevalent? Maybe it’s because software development is more complex than function calls and appsec needs to take more action than just awareness.

Not all security has to be hard. Nor does it have to impede the developer experience or speed of development. There are crypto and JavaScript libraries that provide design patterns and reuseable components for web sites.

Education about current development practices can go far, but it needs to be grounded in constructive patterns to follow rather than just mistakes to avoid. In other words, give developers examples of secure design principles and how to adopt those principles. It’s the subtle difference between “Don’t make this list of mistakes” vs. “Here’s how to securely design software.”

  1. MySQL introduced support for prepared statements in version 4.1, whose first alpha release was April 3, 2003. ↩

  2. “A6 Command Injection Flaws” from OWASPWebApplicationSecurityTopTen-Version1.pdf ↩