Timeline for Is reliance on parametrized queries the only way to protect against SQL injection?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 26, 2013 at 16:00 | comment | added | mike30 | Even the invocation of a proc can be a problem. command = "someProc " + arg1; Parameterization protects you. Procs do not. Although people do seem more inclined to parameterize when using a proc. | |
| Jul 21, 2011 at 18:16 | comment | added | Bruce Ediger | To reinforce what Craig writes above, see databasesecurity.com/dbsec/lateral-sql-injection.pdf, "Lateral SQL Injection: A New Class of Vulnerability in Oracle" | |
| Jul 21, 2011 at 11:52 | comment | added | Chris Walton | @Jon - I have altered the title of the question, and made some edits to the question, in the light of Craig's correction. I was not aware of the assumption I was making in the question, until I started receiving replies. | |
| Jul 21, 2011 at 11:48 | comment | added | Jon Hopkins | @Chris - I think what Craig is saying here is that you can't assume that procs actually do protect you. It's perhaps not a complete answer, more a correction of the assumption in the title. | |
| Jul 21, 2011 at 10:36 | comment | added | Falcon | +1 In addition to that, I'd like to state that stored procs are mostly considered secure because it is the only way to prevent users from directly accessing tables while still maintaining a way to retrieve the data. It's the only way to ensure row-based and column-based privileges when the user needs to have direct database access with his client without anything in between. | |
| Jul 21, 2011 at 10:35 | comment | added | Chris Walton | Thank you for the focus on parameterised queries, rather than procs. However, I am asking whether the database can be protected by methods other than by such queries - in particular methods that are confined to the database layer only. | |
| Jul 21, 2011 at 10:27 | history | answered | Craig | CC BY-SA 3.0 |