| Author |
Messages |
|
Sumayah (guest)
 |
| 12/26/2007 10:24 AM |
Quote
Reply
Alert
|
hi every one, does any one know of any counter measures against encodes SQL injection in case of dynamic queries? what about sql randomisation as prposed in the SQLRand paper. SQLrand: Preventing SQL Injection Attacks StephenW. Boyd and Angelos D. Keromytis thank you for the help in advance. |
|
|
|
|
Chip Andrews Posts:113
 |
| 12/26/2007 4:31 PM |
Quote
Reply
Alert
|
Encoded SQL isn't terribly difficult to detect since your normal input validation routines should already be checking for encoded data. If you need to allow encoded data, then simply decode it before applying your validation. Methods for this will vary based on language and database platform. Hopefully you are already using parameterized queries for all database access as this will greatly increase your defensive posture with little effort. As for the SQLRand paper: I was not very impressed at first glance. First - they imply that since web applications are still vulnerable that the current defenses (input validation, secure development methodologies) are not sufficient which is clearly not the case. The fact that people are not adhering to the recommended development policies regarding SQL injection is the problem - not some magic security "snake oil" which is being peddled here. Finally, even if this single point of failure proxy solution could be made to work, there are still multiple issues. First - not all SQL injection requires the use of operators (which they randomize as a defensive measure). Try this: select * from users where id=? how does SQLRand protect against this? select * from users where id=1; xp_cmdshell 'net user test test /add' It doesn't. Since I inject no operator, there is nothing the proxy can add in the way of defense. I do commend them for the paper - it is worth discussing and there is certain room for new ideas. However, at this time I see this as another IDS/IPS device. Helpful - but not a silver bullet. Chip |
|
|
|
|
mulhall (guest)
 |
| 01/16/2008 6:00 AM |
Quote
Reply
Alert
|
| There is no magic bullet for SQL Injection, and no substitution for good coding practises and input validation. |
|
|
|
|
Ray (guest)
 |
| 07/01/2009 5:26 PM |
Quote
Reply
Alert
|
Chip- With respect to your second example.. there's gotta be a way to disable the batch statements feature in Mssql, right? right?? Don't laugh! :), I have an Oracle background. And I'm aware of the other countermeasures. But, c'mon, Microsoft, don't tell me you don't support disabling multiple statements. I have a feeling this is gonna be bad... ray |
|
|
|
|
|