[thelist] Avoiding SQL Injection

Joshua Olson joshua at waetech.com
Mon Mar 21 17:18:42 CST 2005


> -----Original Message-----
> From: Ken Schaefer
> Sent: Monday, March 21, 2005 5:04 PM

> I am surprised that the use of prepared statements and 
> parametised queries has not been brought up.

Without a reference as to which database is in use, such suggestions may or
may not be applicable.  Also, the techniques will also differ depending on
the server-side scripting language as well.

> Attempting to sanitise bad input  is, in the final
> analysis, a losing battle. Instead, the use of parametised 
> queries is the way to avoid SQL injection. You are putting 
> the burden of avoiding SQL Injection
> onto your data access technology, rather than attempting to 
> come up with your own algorithms.

I'm not clear what you mean by "in the final analysis", and I'm 100% sure I
know what you mean by "sanitize".  If you mean to replace invalid characters
with valid characters, then I may agree with you.  

If you mean to reject bad input entirely if it's "invalid", then I'm not
sure I agree with you.  So long as your "own algorithms" are simple and
attach the simple cases, it should be easy to filter out bad input before
burdening the database.  Heck, there are basically two different database
type... numbers and strings.  Any entry level programmer can figure out a
way to validate numbers!  Likewise, any entry level programmer can figure
out how to escape a string appropriately for a particular database.
Finally, any entry level programmer can figure out how to ensure that the
encoding type of an input string is valid for a particular database.

At the most simple level, what else is there to protect against SQL
Injection?  Maybe destroy all lazy programmers who don't enforce string
validation?  That would probably help.

<><><><><><><><><><>
Joshua Olson
Web Application Engineer
WAE Tech Inc.
http://www.waetech.com/service_areas/
706.210.0168 




More information about the thelist mailing list