At the end of the day, though, isn't this just security through obscurity? If the attacker uses an injection string that creates an always-false condition, then the injection succeeds, does it not?
PaulM -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 2:33 PM To: full-disclosure@lists.grok.org.uk Subject: [Full-disclosure] FW: Introducing a new generic approach todetecting SQL injection Folks - The following scheme looks like it could be helpful, apart from runtime cost (which would tend to be limited since it is only where using human entered data). Anyone see serious holes? Concur? Disagree? This seemed just crazy enough to work when it occurred to me... Thanks Glenn Everhart As you know, blocking SQL injection with filters on characters is painful and not always successful. I got thinking about it and thought of an approach that might detect such activity, and which is pretty generic. The idea is that SQL in web apps gets used by shoving some SQL command code into a DBMS, tacking one or more user inputs (possibly edited) onto a prefix part that is part of the app. In examples, this is often a SELECT statement but in principle others could be used. Then after the input there will be other stuff to complete the statement. Normally when valid input is present, this gives legal SQL that does something. However when there is SQL injection, generally you see the user input piece being some condition to cause the initial statement to be legal all the time followed by whatever mischief is desired, followed by something to comment out whatever else is there since it would otherwise make the whole not look legal. If I want to detect SQL injection, one way to do it could be to put in the prefix and the user piece, and follow it with some condition that will prevent the statement from working when valid input is present...the idea is to wind up with something like select password from users where user = '<user input>' and hell has frozen over and 1 = 0 (so the undisturbed statement will never be executed if valid input is present). If you try to parse this with the user input and it comes out to be valid and ok to execute, that would seem to indicate something strange is going on with <user input> and that an attack is going on. Now a problem is that you don't want to allow your database to be corrupted with some such attack before you can react, seeing that allowing your business to be hosed and THEN complaining seems inadequate. Even if there is nothing that will allow such statements to be run in a test mode, though, they could be run against a dummy database whose corruption would not matter. At any rate this seems like a technique worth a look as a way to detect mischief which is at any rate different from character filters and could make apps a bit safer. Glenn C. Everhart 18 April 2005 A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -R.A.H. ********************************************************************** This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you ********************************************************************** _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
