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?)

1) 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. 1a) This seems to be somewhat addressed here : https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Least_Privilege but I'll add a few notes on views

2) 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.) 2a) I think this is a bit 2 much detail for a cheat sheet, but go ahead and add it in. It will not hurt any :)

3) 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. 3a) Stored procedures can help limit the attack surface (just provide access to your stored procs and turn off select, insert, update and delete and so on...

4) 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. 4a) Well actually, I do agree with you here :)

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