Talk:SQL Injection Prevention Cheat Sheet

There are a couple of suggestions for this page that I would like to discuss (not sure whether I do have access to edit the page?)

Anyway, one thing is that VIEWs are not mentioned; I find that it is an important feature that can help enforce the least-privilege principle by providing finer granularity on read accesses. One web-app may need to validate logins, so its associated db user would need access to username and password fields; a different web-app of the same system may need access to the username only; if we're restricted to per-table privileges, that other db user would necessarily get read-access to the password.

A related mechanism would be that of splitting tables to a fine granularity --- in this example, the username would be in one table, password on a different table --- the login db user is granted read access to both tables (but even then, it would be beneficial to define a view that hides the inner join details of the SQL statement), whereas the other db user gets read access to the table containing the username only.

One other detail: I disagree with the stored procedures item. Stored procedures per se do absolutely nothing in favor of security --- the funny thing is that the detail is emphasized; we have to use stored procedures in combination with prepared statements or ensure proper escaping. Well, that's exactly the same situation with normal SQL statements; the stored procedure does not change anything in terms of needed an SQL statement to access the data; the exact same issues apply.

So, I suggest that "Use of stored procedures" be removed as one of the countermeasures --- it could be mentioned in the other countermeasures that they apply to stored procedures as well as to normal SQL statements reading directly from tables or views.

Cal-linux (talk) 13:45, 9 July 2015 (CDT)