Lateral SQL injection paper

[jim at manico.net (Jim Manico)]

> Anyone else have a take on this new attack method?

If I use Parameterized queries w/ binding of all variables, I'm 100% 
immune to SQL Injection.

In Java (for Insert/Update/etc) just use PreparedStatement + variable 
binding.

There are similar constructs in all languages.

Although the attack is cool - the defense is still the same.

Grey Box Testing (code review and pen testing) will uncover all SQL 
Injection flaws in even the largest app in very little time.

 - Jim


> Greetings SC-Lers,
>
> Things have been pretty quiet here on the SC-L list...
>
> I hope everyone saw David Litchfield's recent announcement of a new 
> category of SQL attacks.  (Full paper available at 
> http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf)
>
> He refers to this new category as "lateral SQL injection" attacks.  
> It's very different than conventional SQL injection attacks, as well 
> as quite a bit more limited.  In the paper, he writes:
>
> "Now, whether this becomes "exploitable" in the "normal" sense, I 
> doubt it... but in very
> specific and limited scenarios there may be scope for abuse, for 
> example in cursor
> snarfing attacks - 
> http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf.
>
> In conclusion, even those functions and procedures that don?t take 
> user input can be
> exploited if SYSDATE is used. The lesson here is always, always 
> validate and don?t let
> this type of vulnerability get into your code. The second lesson is 
> that no longer should
> DATE or NUMBER data types be considered as safe and not useful as 
> injection vectors:
> as this paper has proved, they are. "
>
>
> It's definitely an interesting read, and anyone doing SQL coding 
> should take a close look, IMHO.  It's particularly interesting to see 
> how he alters the DATE and NUMBER data types so that they can hold SQL 
> injection data.  Yet another demonstration of the importance of doing 
> good input validation  -- preferably positive validation.  As long as 
> you're doing input validation, I'd think there's probably no need to 
> back through your code and audit it for lateral SQL injection vectors.
>
> Anyone else have a take on this new attack method?  (Note that I don't 
> normally encourage discussions of specific product vulnerabilities 
> here, but most certainly new categories of attacks--and their impacts 
> on secure coding practices--are quite welcome.)
>
>
> Cheers,
>
> Ken
>
> -----
> Kenneth R. van Wyk
> SC-L Moderator
>
> KRvW Associates, LLC
> http://www.KRvW.com
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
> as a free, non-commercial service to the software security community.
> _______________________________________________
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20080428/88b40127/attachment.html