I consider the mere possibility of SQL injection a failure of engineering.
Like most things in new advances in tech. When SQL API's were first designed no attention was paid to security at all, it almost wasn't even an after thought. As a result, SQL injection is possible.
SQL, like the last letter in the name suggests, is a language. That being said, one can effectively think of it as a limited scripting
language for moving crap around in a DB. I emphasize the word scripting because it's the important factor in what makes SQL injection possible.
Like all scripting languages, every time it is ran from source it must first be lexically analyzed into a stream of tokens which is then parsed into an AST (abstract syntax tree) which is then stepped through by the runtime. This is roughly how most non compiled scripting languages work on run. The exception would be non scripting languages such a C/C++ which are compiled once instead, meaning the parsing/compilation process only happens once.
SQL's original weakness to injection had everything to do with bad engineering. It's the mistake of letting the user add an arbitrary string of ascii to the buffer before it is lexically analyzed and then parsed
. If user data were to be referenced via symbol tables from the AST after compilation has taken place, then SQL injection would of never have been possible.
Thankfully, MySQL and others have followed suite and created a mechanism known as prepared statements ( http://dev.mysql.com/tech-resources/art ... ments.html
). They work by first compiling the query and then binding user data after the compilation process. The result is that since compilation has already taken place, the user data is just that, user data and can do absolutely nothing to modify the structure of the underlying AST.
However, prepared statements work like GCC or VS, which is to say it's a compiler that compiles the query before hand and passes the user data in later.