The Injection Sequel

July 31, 2012

It still amazes me, sometimes, that SQL Injection ever came into vogue, becoming one of the poster children of web application vulnerability.  It’s outright jaw-dropping that in 2012, an iconic web company would fall victim to this technique.  I could go on and on, about the number of things that went awry and/or should’ve been done.  But this appears to be a chronic failure, with each generation of software engineering re-inventing the same bug all over again, like an endless nightmare of unlearned remedial lessons.  SQL injection attack is a variation on one of the oldest secure computing tenet no-no’s, and that is the implicit granting of permissions.

The list of victims of implicit permit is long and sordid, and can be easily traced back to a time predating the so-called modern web, back when consideration of security did not play a role in application development.  History buffs may remember the jokes about Sendmail, with each passing week a new bug would be exposed.  Or the packet filters [ that eventually became firewalls ] that permitted everything, and rules were written to exceptionally deny.  The problem in both cases is a faulty approach… the rules should’ve always been explicitly permit and implicitly deny, because as creator of these software and logic, one should already know [ in advance ] what is permitted and within bounds of execution.  Sendmail shouldn’t have unplanned passing of parameters.  Firewalls shouldn’t allow packet traversal unless it was known and expected.  Yet in each case, programmers blacklisted unexpected behavior only after each successful breach, repeatedly.  It took many weeks/months/years before explicitly permit and implicitly deny became the default for both programs.  In hindsight, that seems crazy.

Yet that is exactly what is happened, and apparently happening, with SQL injection attacks — the careless and negligent handling of input data, and then additionally passing it onward into a database without limiting access [ or other ] permissions.  This implicit permit problem continues today and elimination does not likely in the near term.  Already, the next-generation of OWASP Top 10 reads like a bad re-run, as the rise of mobile applications have led to an equal rise in intrusions based on untrusted input.  Let me repeat that, input is not to be trusted.  We’ve seen this movie.  We know the ending.  We know how to slay this particular dragon, and it’s not implicit trust or permission.  It takes nominal more effort to implement the right solution — to explicity permit and implicity deny.  Do it already, so that we may go back to writing other, original, insecure code instead.


Eddie is a technology enthusiast and a blogger, now, who loves all things Internet and mobile, as if those were two separate things. As part of, he's looking to battle the forces of evil, fight crimes and purchase security upgrades to the Metaverse.