On: Rookie coding mistake prior to Gab hack came from ...

[jahabrewer]

A mistake can be both "rookie" and widely prevalent. That's exactly how I'd describe SQL injection.

[wwww4all → jahabrewer]

Go ahead and try to implement a fix to sql injection bug in any of your systems. I can guarantee there’s a sql injection issue somewhere.

The reason it’s so prevalent is because it’s not a rookie issue and very difficult to fix properly, without impacting significant changes.

That’s why OWASP has it as huge part of security analysis and resolution.

[rsynnott → wwww4all]

> I can guarantee there’s a sql injection issue somewhere.

This class of sql injection issues can be eliminated by simply enforcing that all queries are string literals.

[twodave → rsynnott]

I'd amend to this "... or composed of local string literals". Programmatically-generated SQL can be advantageous in terms of maintenance, readability and even performance, depending on the situation.

[tehjoker → rsynnott]

Concur. Adding parameters to a query is what a "bind" is for.

[acdha → wwww4all]

> The reason it’s so prevalent is because it’s not a rookie issue and very difficult to fix properly, without impacting significant changes.

Neither of these claims is true. Placeholders have been the recommended way to do this since the 1990s (I remember having this same talk with Perl & PHP 3 newbies) and one of the points of using a framework like Rails is that these are much easier to avoid if you use an ORM. The problem in this case is that they found a problem they (probably incorrectly) believed couldn’t be expressed in the ORM _and_ ignored the placeholder support _and_ didn’t validate their inputs. None of those require advanced experience to fix and at least the latter two are trivial to implement.