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
| ||
|
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
Powered by blists - more mailing lists