| Author |
Messages |
|
Chris (guest)
 |
| 03/16/2006 11:39 AM |
 Quote
 Reply
 Alert
|
I'm doing testing on an app for SQL injection vulnerabilities. In analyzing the stored procs, there is one field where they run dynamic SQL and concatenate in a string from the user. However, the caller is replacing ' with '' and the claim is that this has made it secure.
This smells like crap to me, but I haven't found a way to break it. If they're gonna run dynamic SQL, is replacing the ' with a '' really enough to prevent attacks? |
|
|
|
|
Chip Andrews (guest)
|
| 03/16/2006 7:38 PM |
Quote
Reply
Alert
|
Not in all cases. For example, let's say the parameter is an integer. In that case you may not need any quotes at all and the code could still be vulnerable.
Also - even with text, there is the opportunity that truncated text could still resulting in exploitable code. For example, if they trim off the first 15 characters of input, then if you entered 14 letters and a single quote, the code would drop the added single quote created by the replacement. Again, the code may be vulnerable again if this occurs.
As you have found, converting single quotes to two single quotes does help - but it is not a panacea.
Chip |
|
|
|
|
Chris (guest)
|
| 03/23/2006 10:35 PM |
Quote
Reply
Alert
|
Thanks! I'm familiar with the integer attack vector, though if the application or stored proc keeps the number typed as an integer. I'll play with that some more, though.
I'll play around with the overflow - it seems like they would have to really screw up their SQL to make it vulnerable, but it will be fun trying 
Thanks for the help! |
|
|
|
|
Vimal (guest)
|
| 10/03/2006 5:12 AM |
Quote
Reply
Alert
|
Can anybody suggest what is THE appropriate way for fixing SQL injection through EXEC statement in stored procs?
Your help would be much appreciated. |
|
|
|
|
Chip Andrews (guest)
|
| 10/13/2006 11:19 AM |
Quote
Reply
Alert
|
It's the same as in the application - input validation. If you want to preserve the capability to insert legitimate single quotes into a char field then you have to normalize the string to ensure that the two single quotes are converted to 4. As you can imagine - this requires some heavy testing and I do not recommend you use EXEC statements unless absolutely necessary due to the care that must be taken.
Example:
Entered data: Captain's Walk (trouble)
Becomes this after application normalization: Captain''s Walk (better - if direct query)
When passed to EXEC it becomes this: Captain's Walk (trouble)
So to fix this your Stored proc using EXEC needs to convert
This: Captain''s Walk
To This: Captain''''s Walk
i.e. exec ('SELECT ''Captain''''s Walk''')
Try it!
Chip |
|
|
|
|
|