A prof said that SQL injection is misnamed because it actually occurs from the program generating the SQL (e.g. Perl, PHP etc.) and I'm wondering is SQL "complex" enough to have any vulnerabilities that are actually it's fault?
When a language is dynamically interpreted, it makes it seductively easy to build the expression from dynamically obtained parameters. E.g. "
See for instance this question for an example of the kind of things which is not captured by the "character escaping" mental framework. Whenever I see the functions
Nonetheless, there is a proper way to build SQL expressions dynamically without getting into the "data is code" issues: parametrized expressions. This is about working with the abstract representation of the SQL code, the one after parsing. When we use parametrized expressions, we do not try to reverse the parsing step, and security is much enhanced (and it is good for performance, too).
So it is not really SQL's fault; the programmer is still to blame, for not using the right solutions which exist and are documented. We may still consider that SQL designers, and, in particular, the people who integrated SQL in PHP, should have made some effort to make dynamic SQL expression building a bit harder when parametrization is not used. For a better language design (with regards to this specific issue), see LINQ: it keeps the syntax where it belongs, i.e. in the source code, not in runtime-interpreted character strings.
Most of the time SQL injection happens because people do not properly use it in their code. If you use SQL in your code you need to use prepared statements instead of using appending variables to your SQL string.
SQL is just a tool, if you don't use that tool properly you are going to have a bad time.
If you hold the knife by its blade you will get cut. But that's not the blade's fault.
SQL has the same inherent weakness as most languages: it will do exactly what you tell it to do.
The problem arises when you don't properly clean input, or the database users has permissions beyond what they need, allowing untrusted third parties to tell it what to do. If they tell it to do something bad... it's going to do something bad.
Various implementations have had various vulnerabilities over the years, including the fairly recent discovery that some MySQL builds would allow you to log on with any password roughly 1 in 256 times: http://nakedsecurity.sophos.com/2012/06/13/anatomy-of-a-bug-the-mysql-authentication-disaster-patch-now/
But SQL injection is generally a flaw in the program between the user and the database (PHP website, etc)