> 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@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.
_______________________________________________
