This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Talk:SQL Injection Prevention Cheat Sheet"

From OWASP
Jump to: navigation, search
 
(One intermediate revision by the same user not shown)
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?)
+
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)
 +
<br/>
 +
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, or would you care to add this in? [[User:jmanico|jmanico]]
  
−
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.
+
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.) [[User:Cal-linux|Cal-linux]] ([[User talk:Cal-linux|talk]]) 13:45, 9 July 2015 (CDT)
−
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
+
<br/>
 +
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 :)  [[User:jmanico|jmanico]]
  
−
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.)
+
3) 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)
−
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 :)
+
<br/>
−
 
+
3a) I agree so I removed it. Check it out now...  [[User:jmanico|jmanico]]
−
 
 
−
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 :)
 
−
 
 
−
[[User:Cal-linux|Cal-linux]] ([[User talk:Cal-linux|talk]]) 13:45, 9 July 2015 (CDT)
 

Latest revision as of 19:13, 9 July 2015

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. Cal-linux (talk) 13:45, 9 July 2015 (CDT)
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, or would you care to add this in? jmanico

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.) Cal-linux (talk) 13:45, 9 July 2015 (CDT)
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 :) jmanico

3) 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)
3a) I agree so I removed it. Check it out now... jmanico

Retrieved from "https://wiki.owasp.org/index.php?title=Talk:SQL_Injection_Prevention_Cheat_Sheet&oldid=197271"