My point is that with magic_quotes on in PHP, php already escapes
quotes for you in all inbound variables. This makes the process
automatic, and therefore fool proof, which is kinda the whole point.
You want a mechanism that there isn't an easy way around, like
forgetting to db_quote once in a while. I'm just trying to find out
if there is an example where magic quotes by itself doesn't work, and
there is a viable injection attack possible, and if so, what it is, so
I can figure out how to prevent it ;).
Alex.
On 11/1/05, Matthew D. Fuller <fullermd@over-yonder.net> wrote:
> On Tue, Nov 01, 2005 at 08:57:04AM -0500 I heard the voice of
> Tom Lane, and lo! it spake thus:
> >
> > If you rely on applying an escaping function then it's pretty easy
> > to forget it in one or two places, and it only takes one hole to be
> > vulnerable :-(.
>
> The trick is to make it a religious ritual. I escape things into _q
> variables:
>
> $name = $_REQUEST['name'];
> $name_q = db_quote($name);
>
> And have myself thoroughly trained to ONLY use _q variables in
> building queries. Of course, once in a while, I forget to _create_
> the _q version before using it, but then I get a nice loud error
> message castigating me for it. I often (not consistently) create _q
> variables even for known-good strings and such that I hardcode into
> the program.
>
> It could well be that using prepared statements is by various metrics
> a "better" way to go about things. But I'm far too lazy to try and
> reprogram my fingers ;-)
>
>
> --
> Matthew Fuller (MF4839) | fullermd@over-yonder.net
> Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
> On the Internet, nobody can hear you scream.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
