It kind of feels like SQL injection shouldn't be a thing anymore, but it is. In fact, some may argue that even a three-year-old can do it.
Particularly worrying, though, is the possibility that some popular frameworks may still have some major weaknesses when it comes to SQL injection. According to Peter Bex in this post from Code Yellow B.V., that's exactly the case. Beginning with FuelPHP, he explores the vulnerabilities created by the framework and how they ought to be handled.
Central to the issue, Bex argues, is the assumption that users will follow safe and consistent naming conventions, avoiding special characters and identifiers that would require escaping:
We believe that the failure mode of accidentally passing user controlled names to filtering or ordering functions should be proportionate to the mistake: at worst, it should cause a limited information leak. Instead, this breach of the abstraction provided by the query builder exposes us to a critical vulnerability by allowing arbitrary SQL to be injected. Besides, we believe that completely putting the responsibility of filtering the input on the user is unacceptable.
Finally, the behaviour is simply incorrect: what if we really want to query a column or create a column alias containing a special character? This might happen, for example, when working with legacy databases with weird naming conventions, or when naming columns for a COPY OUT statement.
But it was not just FuelPHP that had these problems; a number of other PHP frameworks, such as CakePHP and CodeIgniter, were similarly problematic. But after exploring INSERT and UPDATE functions, Bex discovered an even more severe issue in Laravel's code: the way Laravel was set up, a user up to no good might use some clever placement of quotes and "password" keys in a POST request and end up with a SQL statement that looks like this:
UPDATE "users" SET "email"='firstname.lastname@example.org',"password" = ? WHERE "id" = ?
In other words, minimal effort would allow a user to freely reset a password to whatever they'd like.
Bex managed to contact these frameworks and the problems have been fixed, but they signify a lack of awareness surrounding the problem. Upon exploring outside of the PHP space to see how other frameworks handle SQL injection - in particular, their handling of identifier quoting - he offers a positive shout-out only to Ruby on Rails.