Timeline for SQL query sanitation (black list)
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 31, 2012 at 18:54 | vote | accept | AaronS | ||
| Jan 18, 2012 at 18:09 | comment | added | dr jimbob |
Agree with Also bear in mind to not disclose any errors, but you should still log errors on your server (to an admin read-only file).
|
|
| Jan 18, 2012 at 12:21 | comment | added | Lucas Kauffman | I actually agree with Krysztof. | |
| Jan 18, 2012 at 12:16 | comment | added | Krzysztof Kotowicz | You can't solve it in application, there's ton of ways to obfuscate malicious query. Use db/table level access control and allow selecting only from needed tables. | |
| Jan 18, 2012 at 11:18 | comment | added | Lucas Kauffman | aaah I see, well yea least privileged should do it then :) | |
| Jan 18, 2012 at 11:13 | comment | added | AaronS | Admin can write SQL query "Delete * from Table1" and application should protect from this. | |
| Jan 18, 2012 at 11:08 | comment | added | Lucas Kauffman | If you do not need to enter any parameters, how can they inject then ? | |
| Jan 18, 2012 at 11:02 | comment | added | AaronS | These SQLs doesn't get any parameters. And I don't want that admin will have to create stored procedures. Least-privileged access sounds promising, but I would prefer to try to solve it on application level. Thanks | |
| Jan 18, 2012 at 10:34 | history | answered | Lucas Kauffman | CC BY-SA 3.0 |