Why’s SQL injection so prevalent?

5 Comments

1. 

   Nelson Minar

   January 22, 2013 at 8:12 pm

   I’m surprised it’s so easy to write insecure code in PHP. One nice thing about Python’s database drivers is the way they do string substitution with automatic escaping protects you from the most naive SQL injection attacks.
2. 

   John

   January 23, 2013 at 1:09 pm

   “I’m surprised it’s so easy to write insecure code in PHP.”

   That’s the funniest thing I’ve read all day.
3. 

   bryan

   January 23, 2013 at 5:03 pm

   “I’m not surprised it’s so easy hard to write insecure well-formed, elegant, and robust code in PHP.”

   FIFY 🙂

   I think we see so many SQL Injection vulnerabilities is a perfect storm of conditions:

   1) PHP is typically a beginner’s language. Thus, you get beginner-level code. Also, said language is easy enough to pick up so that one can write crap code that sort-of works well enough. (Also, copy-and-paste programming.) 2) Most people are Dunning-Kruger when it comes to security, so whatever “security” they will implement will be severely flawed. 3) There is no (or a very large) feedback loop when it comes to SQL Injections. If someone makes a syntax error in their code, they will see it pretty quickly when they try to run the code. A SQL Injection vulnerability can languish for months or even years before it is exposed, and even then no one may notice.

   99) The lack of a “preview comment” function kills kittens.
4. 

   Chris Adams

   January 23, 2013 at 8:37 pm

   Also: the core developers do not care. I remember calls for warnings in the docs back in the early 3.x era. When PDO came out, requests there also went unanswered even though the new driver was a prime time for a suggested safe pattern. (Similar suggestions were made for other notorious hazards; as I recall the only one which was eventually acted upon was disabling register_globals)

   By 5.x, I switched to Python — there are many reasons why I prefer it but foremost is that the core developers are both conscientious and responsive. bugs.php.net was either a black hole or rejection central – often sounding akin to “real men don’t need safety guards on this bandsaw – just be careful!”
5. 

   jim winstead

   January 23, 2013 at 11:12 pm

   i find it funny to write an article complaining about the incorrect/incomplete examples elsewhere, and then in your demonstration of the correct way to handle things, totally punt on error handling.

   php’s ease of use has always been complicated by how closely many of its extensions hew to their underlying C API. and unfortunately, the mismatch between php’s loose typing and C’s more defined data types has turned out to be a fertile ground for security problems.