Secure Coding mailing list archives
Lateral SQL injection paper
From: joe at joeteff.com (Joe Teff)
Date: Tue, 29 Apr 2008 02:09:27 -0500
If I use Parameterized queries w/ binding of all variables, I'm 100% immune to SQL Injection.
Sure. You've protected one app and transferred risk to any other process/app that uses the data. If they use that data to create dynamic sql, then what? jt -----Original Message----- From: Jim Manico <jim at manico.net> To: Kenneth Van Wyk <ken at krvw.com> Cc: Secure Coding <SC-L at securecoding.org> Date: Mon, 28 Apr 2008 15:27:58 -0400 Subject: Re: [SC-L] Lateral SQL injection paper
> 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. - JimGreetings 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 holdSQLinjection 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 injectionvectors.Anyone else have a take on this new attack method? (Note that Idon'tnormally 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-lList charter available at -http://www.securecoding.org/list/charter.phpSC-L is hosted and moderated by KRvW Associates, LLC(http://www.KRvW.com)as a free, non-commercial service to the software security community. _______________________________________________
Current thread:
- Lateral SQL injection paper Kenneth Van Wyk (Apr 28)
- Lateral SQL injection paper Jim Manico (Apr 28)
- Lateral SQL injection paper Joe Teff (Apr 29)
- Lateral SQL injection paper Steven M. Christey (Apr 29)
- Lateral SQL injection paper Arian J. Evans (Apr 29)
- Lateral SQL injection paper Mary and Glenn Everhart (Apr 29)
- Lateral SQL injection paper Joe Teff (Apr 29)
- Lateral SQL injection paper Jim Manico (Apr 28)