> 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 <[EMAIL PROTECTED]> To: Kenneth Van Wyk <[EMAIL PROTECTED]> Cc: Secure Coding <SC-L@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. > > - 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 dont take > > user input can be > > exploited if SYSDATE is used. The lesson here is always, always > > validate and dont 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@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. > > _______________________________________________ > > > > _______________________________________________ Secure Coding mailing list (SC-L) SC-L@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. _______________________________________________
