
SQL Injection Cheat Sheet - ausjke
https://www.netsparker.com/blog/web-security/sql-injection-cheat-sheet
======
thyrsus
I think this is useful; the next step in usefulness would be an automated test
suite that looked for these vulnerabilities; and the next level in usefulness
would be a chart describing common ways these problems get into code - I don't
do SQL professionally, but every time I look at it, there's some language
specific API, and without deep knowledge of the language and API, I'm not
_sure_ that I'm not unintentionally allowing data to be interpreted as code.

E.g.: I'm competent in perl, and I'm pretty sure I could prevent data from
getting interpreted as code there, but I won't make any such claim for ruby or
java or .... though I can usually read those languages.

~~~
kbenson
The answer is basically the same for every language. Use SQL interfaces that
support bound variables[1]. It's not about remembering to correctly sanitize
input, it's about adopting practices that _eliminate the possibility of that
class of attack_. Forcing databases to consider each argument as an atomic
item (not a string to be interpreted) is one such way to do so.

There are still other attack vectors, such as viewing non-associated records
by tweaking parameters, but that's not SQL injections, it's leaking content
through loose ownership checking, and that may or may not be a problem in the
DB or the application, depending on whether you are relying on the DB for user
level permissions and ownership, or the application.

1: [https://metacpan.org/pod/DBI#Placeholders-and-Bind-
Values](https://metacpan.org/pod/DBI#Placeholders-and-Bind-Values)

