4 ms·
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 wou
by thyrsus 11y ago
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 11y agoThe 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