> 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
