full-disclosure - FW: Introducing a new generic approach to detecting SQL injection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri Apr 22 20:26:50 2005
From: mohit.muthanna at gmail.com (Mohit Muthanna)
Subject: FW: Introducing a new generic approach to
	detecting 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."