Re: FW: Introducing a new generic approach to detecting SQL injection

[Mohit Muthanna <mohit.muthanna () gmail com>]

> 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/