The most obvious way around magic_quotes_gpc is with integer arguments
since you don't have any quotes in the SQL. I show some examples of
this in my SANS class on PHP/Web security.
Also, other databases escape the quotes differently. M$ SQL Server
uses a quote to escape a quote (''). I think it's so common since it's
easier than doing proper input validation, but definitely has its weaknesses.
It's sort of a default/fallback thing but still should not stop you from
using proper input validation. In PHP, the easiest is to use things like
is_int(), is_alphanum(), or regex to match only what you want. Be sure
to do positive validation (allow in only good chars) rather than try to
filter out what you don't want since you'll inevitably miss something.
But if the app relies upon magic_quotes so heavily, what if you want
to use a different back-end someday? Or what if you take the code
and put in a different php.ini where magic_quote_gpc is turned off?
I might use it in my apps as a fallback "just in case" but will never rely
upon it. First line of defense is always validating input right when you
first read it from the superglobal and assign it to a local var.
Steve
At 10:55 PM 12/10/2005, Todd Hendricks wrote:
I'm very curious as to what level of protection magic quotes
provides against SQL injection attacks
(for MySQL, specifically) under PHP. I have a rather lengthy app
that relies upon magic_quotes_gpc
to sanitize database input, and information that goes straight back
to the presentation layer from a
form is then stripslash'ed.
My question is, what are some ways around magic_quotes that I need
to watch out for.. and as a
followup, if it's such a bad security idea, why was it included at
all much less enabled by default
(this seems to smack of the register_globals problem, only to a
lesser extent)?
I do understand that it would be a good idea to redo the entire app
using mysql_real_escape, but in
this single-developer environment, I'd like to avoid doing a massive
revamp unless it's of
penultimate importance to do so, because that cuts in to
feature/usability development time.
Regards,
- Todd
==================================================
Steve Slater
Hands-On Security
http://www.handsonsecurity.com
SANS LAMP and Web Security Class
http://www.sans.org/sans2006/description.php?tid=249
