Stewart Stremler wrote:
> begin quoting George as of Thu, Aug 23, 2007 at 09:35:23AM -0700:
> [snip]
>> Here is a simple function that will take eliminate most SQL injection
>> attacks:
>>
>> function filter_sql($input) {
>> $reg = "(delete)|(update)|(union)|(insert)";
>> return(eregi_replace($reg, "", $input));
>> }
>
>..
from sig (the worthwhile part of this particular post :-) ):
> sElEcT * fRoM mYtAbLe wHeRe nAmE = "" oR 1 = 1 Or NaMe = ""
I thought I remembered that parameterized queries (or prepared
statements?) are somehow supposed to help protect against composing
something like SS's added sig joke.
Ummm, searching a bit gives
http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html
"""Why use prepared statements?
There are numerous advantages to using prepared statements in your
applications, both for security and performance reasons.
Prepared statements can help increase security by separating SQL logic
from the data being supplied. This separation of logic and data can help
prevent a very common type of vulnerability called an SQL injection
attack. Normally when you are dealing with an ad hoc query, you need to
be very careful when handling the data that you received from the user.
This entails using functions that escape all of the necessary trouble
characters, such as the single quote, double quote, and backslash
characters. This is unnecessary when dealing with prepared statements.
The separation of the data allows MySQL to automatically take into
account these characters and they do not need to be escaped using any
special function.
"""
I also remember that the parameter gets interpreted at the server as a
single string (ie as if [if not actually?] quoted), so that embedded
logic or separators or sub-clauses would not change the syntax.
[But] I think I'd like to test for myself whether MySQL really does it's
automatically-thing in a reliable way -- by trying some SS-type attacks,
as above.
The other thing that comes to mind in this general area, is some
general handwaving: *never* compose from user input an SQL statement.
Never even accept SQL statements from a form. Instead, accept an index
into the web-server resident code containing the actual SQL (or
parameterized queries, I guess).
If you have a lot of PHP (or any) forms, it might be well worth adopting
some formal security review process for forms and form handling.
Can't help on PHP specifics. If you don't have it, you may want to pick
up the latest edition of Paul DuBois' MySQL Cookbook. The 1st edition
does seem to confirm that PHP doesn't (didn't) have too great support
for prepared statement features, but he certainly is a knowledgeable
authority in this area (as, you probably know).
Regards,
..jim
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
