Talk:SQL Injection Prevention Cheat Sheet - Revision history

Jmanico at 19:13, 9 July 2015

2015-07-09T19:13:40Z

Jmanico at 19:13, 9 July 2015

2015-07-09T19:13:18Z

Jmanico at 19:02, 9 July 2015

2015-07-09T19:02:52Z

Cal-linux: Created page with "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 me..."

2015-07-09T18:45:56Z

Created page with "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 me..."

New page

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.

[[User:Cal-linux|Cal-linux]] ([[User talk:Cal-linux|talk]]) 13:45, 9 July 2015 (CDT)

@@ Line 1: / Line 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. [[User:Cal-linux|Cal-linux]] ([[User talk:Cal-linux|talk]]) 13:45, 9 July 2015 (CDT)
 a) 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, or would you care to add this in? [[User:jmanico|jmanico]]
 ) 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.) [[User:Cal-linux|Cal-linux]] ([[User talk:Cal-linux|talk]]) 13:45, 9 July 2015 (CDT)
 a) 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 :)  [[User:jmanico|jmanico]]
 ) 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. [[User:Cal-linux|Cal-linux]] ([[User talk:Cal-linux|talk]]) 13:45, 9 July 2015 (CDT)
 a) I agree so I removed it. Check it out now...  [[User:jmanico|jmanico]]

@@ Line 1: / Line 1: @@
-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. [[User:Cal-linux|Cal-linux]] ([[User talk:Cal-linux|talk]]) 13:45, 9 July 2015 (CDT)
-) 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.) [[User:Cal-linux|Cal-linux]] ([[User talk:Cal-linux|talk]]) 13:45, 9 July 2015 (CDT)
-a) 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
+a) 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 :)  [[User:jmanico|jmanico]]
-) 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.)
+) 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. [[User:Cal-linux|Cal-linux]] ([[User talk:Cal-linux|talk]]) 13:45, 9 July 2015 (CDT)
-a) 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 :)
+a) I agree so I removed it. Check it out now...  [[User:jmanico|jmanico]]