Message-ID: <C6AF3ECACA6E9A46A2CB2FABCDCB35C403D58A81@swilnts810.wil.fusa.com>
Date: Mon Apr 25 13:02:52 2005
From: Glenn.Everhart at chase.com (Glenn.Everhart@...se.com)
Subject: FW: Introducing a new generic approach
	todetecting SQL injection

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@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk]On Behalf Of Mohit
Muthanna
Sent: Friday, April 22, 2005 3:27 PM
To: Paul J. Morris
Cc: full-disclosure@...ts.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
**********************************************************************

Powered by blists - more mailing lists