Posted by Michael Fesser on 02/26/07 22:40

..oO(MattMika)

>I was under the impression that escaped strings would be written to
>the DB like O/'Reilly, but its not.

Correct. The escaping just prevents the escaped char from being seen as
something special. The escaping char itself is never written to the DB
or anywhere else.

Consider this:

print "<a href=\"URL\">...</a>";

Obviously you don't want the backslashes to appear in the final HTML
output. And they won't, because they are just used to prevent PHP from
interpreting the associated " chars as string delimiters.

Of course the above would be better written as

print "<a href='URL'>...</a>"; or
print '<a href="URL">...</a>';

but you should get the idea.

>Also, should I worry about escaping all data in GPC or only user input
>$_POST and possibly modified $_GET data? For instance, should I escape
>$_POST arrays populated by checkboxes? I assume it could be hacked for
>injection purposes as well so should be checked.

| Rule #1: Everything (this means really _everything_!) coming
| into the server from the client must be considered harmful.

GET data, POST data, COOKIE data, HTTP headers - they all can be
manipulated. Technically spoken every client is your enemy, so you have
to (re)act accordingly. But that's not enough. Even if some malicious
data makes it safely into your DB doesn't mean the danger is over. For
example if you re-use the previously stored data in an UPDATE query
without proper escaping, it could still wreak havoc, just a bit delayed.
So:

| Rule #2: Always use escaping or prepared statements when writing to a
| DB, even if the data may come from a previous SELECT query.

In case of the mentioned checkboxes or radiobuttons - validate them
against an array of all allowed values and use the value from that array
for further processing.

Micha

[Back to original message]