Full Disclosure mailing list archives
RE: FW: Introducing a new generic approach todetecting SQL injection
From: <Glenn.Everhart () chase com>
Date: Mon, 25 Apr 2005 07:56:19 -0400
Let me opine here that the technique is wreckless (i.e., prevents wrecks, a good thing) and is NOT reckless (unadvised or unthinking). I am well aware that it has been hypothesized that regular expressions can be used to filter database inputs. However I have not seen nor heard tell of any proofs that regular expression parsers can duplicate what the SQL and other parsers in a real application do. If there are such proofs I would be glad to know of it, for then certainly one could rely on regexp parsers to remove any possible attack. If they are not equivalent, however, (and I strongly suspect they are not), there will be cases where regular expression cleanup cannot discern when an attack (especially a new attack) is in use. The proposed scheme or variants are intended to use the precise parsers used for the input to look for odd behavior which might mean an attack is under weigh [old Naval expression]. For that reason the proposed scheme seems likely to find some attacks which regexp filters would not imagine. Now, regular expression filters certainly can block attacks in many cases, but they often do so by impoverishing the range of inputs which otherwise would be legal. This kind of activity is precisely what has led to insistence upon changes to well accepted human behavior because someone could not figure out how to program a computer to parse it. (In the US, the postal 2 character state codes are an excellent example of this. So are parsers that will not permit the correct spelling of people with last names like O'Toole or Harris-Grey. Folks: are computers to be the bosses here or are people (we)?) There are alternatives to the database protection and use of a separate database which can be devised; Paul and I have discussed a few. If the use of the exact parsers is a useful tool, there are also means which can be added to systems at several levels to make such parsers less costly to invoke. If there is something wrong with the technique, then it should not be used. However if not, it would be more useful to design ways to make it more efficient, and perhaps extensions which might make it more sensitive. There is much messaging on this and other lists which discusses vulnerabilities. It would seem just to ask that some who claim they are interested in system security be more forthcoming with defensive techniques. Of course, if there is a proof somewhere that regexp parsers can be equivalent to the SQL parsers plus all the other unicode, etc., parsers which exist in a real app, and that such are available for the various different SQLs, unicode parsers, etc., so that they can truly know what is going on, then I stand corrected and there is no need for other machinery. If not, it'd be awfully nice to see the attack proofs of concept accompanied by defensive ones more often. A person might wonder what the motives are that are involved... (I also consider that decisions on what legal filenames, URLs, personal names, or the like may look like are design decisions that generally do not and should not belong to web application designers. While I have no personal use for a personal name of 25 XOFF characters (or a filename similarly), many folks use OS filesystems that permit such filenames, and I believe an adult should be able for nonfraudulent use to pick what he/she will be called, even if it is weird or ridiculous. If these are to be abandonned, it should be the result of a broad based decision, not the result of failure of imagination of some app designers.) (Some will remember the relevant French legislation after the old Royal laws were dropped after the 1798 revolution...societies have had such rules but they get decided by the society.) Glenn Everhart -----Original Message----- From: full-disclosure-bounces () lists grok org uk [mailto:full-disclosure-bounces () lists grok org uk]On Behalf Of Mohit Muthanna Sent: Friday, April 22, 2005 3:27 PM To: Paul J. Morris Cc: full-disclosure () lists grok org uk Subject: Re: [Full-disclosure] FW: Introducing a new generic approach todetecting SQL injection
Once the allowed character set gets beyond $sanitized = preg_replace("/[^a-zA-Z0-9]/", "", $untrusted) especially into the realm of unicode character strings where valid input from a user may include the characters ; % ' " and #, sanitizing by filtering can indeed get difficult.
Don't use simple regexp matching. Google for a good escaping / encoding library for your language of choice. Check the database API bindings for your language to see if it supports quoting.
Let me suggest an elaboration on Glenn's idea that poisons a query with a known error, fires the poisoned query including the untrusted input against a test database, and looks to see if the expected error from the poisoning occurs. Untrusted input that contains a sql injection attack should raise a different error than expected.
This technique, though novel, is really _wreckless_misuse_of_resources_.
Note, I wouldn't use this in cases where $sanitized = preg_replace("/[^a-zA-Z0-9]/", "", $untrusted) would work perfectly well, but only in cases where the scope of valid characters was quite large.
I'll reiterate; unless your regexp is robustly tested don't use it. There are many libraries out there for URL/Base64/Unicode/etc. etc. encoding, decoding and escaping. Use them to clean up your input. If your database API supports it, use prepared statements and parameter binding. Don't use simple string interpolation (without quote handling). It's really that easy. -- Mohit Muthanna [mohit (at) muthanna (uhuh) com] "There are 10 types of people. Those who understand binary, and those who don't." _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ********************************************************************** 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/
Current thread:
- RE: FW: Introducing a new generic approach todetecting SQL injection Glenn.Everhart (Apr 25)
- <Possible follow-ups>
- RE: FW: Introducing a new generic approach todetecting SQL injection Glenn.Everhart (Apr 25)