bugtraq - Re: SQL Smuggling

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]

Message-ID: <20080909233423.GF2512@sentinelchicken.org>
Date: Tue, 9 Sep 2008 16:34:23 -0700
From: Tim <tim-security@...tinelchicken.org>
To: douglen@...mail.com
Cc: bugtraq@...urityfocus.com
Subject: Re: SQL Smuggling

> We released a research paper a few months ago, regarding a sub-class
> of SQL Injection that has not received attention till now. The crux is
> that when it comes to SQLi, protection and detection do not typically
> take the architecture into account; this can allow smuggling attacks
> which are not blocked or discovered.
> 
> The paper can be found at:
> http://www.ComsecGlobal.com/framework/Upload/SQL_Smuggling.pdf 
> 
> From the paper:
> "This paper will present a new class of attack, called SQL Smuggling.
> ...

I don't see how this is a new class of attack.  You've merely outlined
some techniques to bypass broken data validation routines.  In SQL
injection, as with any injection vulnerability, the correct way to fix
it is to rely on the syntax of the language to encode data which may be
interpreted as /special/.  

Yes, this is database specific.  That's not new.  That's why you need to
rely on the database's routines for treating data as data and not as SQL
syntax.  This is what parameterized statements are for.  You rely on the
database driver or database server itself to correctly separate data
from syntax.  If this is still injectable, then it's a vulnerability in
that particular database, but still isn't a "new class of attack".

Relying on data validation alone will eventually land you in hot water.
You can't always reject last names such as "O'Leary" just because of the
apostrophe.  Correct encoding is the way to *fix* it, and data
validation should only be used to slow down the bad guy if you forgot to
encode something and to enforce business logic.  (Go back and read this
paragraph again.  It's the important one.)

As for attacks against signature validation... uh, don't even go there.
We all know that's a losing battle.  Just look at how bad AV has become.

In summary, your paper would be better presented as a collection of fun
SQL injection attacks against commonly broken data validation routines.

tim