Re: PHP 5.1
| From: | val khokhlov | Date: | Fri, 04 Feb 2005 09:34:12 +0000 |
| Subject: | Re: PHP 5.1 | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-14640@lists.php.net to get a copy of this message | ||
Hello Rasmus,
Friday, February 4, 2005, 11:00:23 AM, you wrote:
RL> It comes down the fact that every single piece of data you get from GET,
RL> POST, Cookie and some Server variables *must* be at the very least be
RL> passed through htmlentities or striptags before you can display any part
RL> of them.
and can you tell if i'm going to display it, store in database or save
to file? for example, i have a content-management system, and there're many
scripts that are supposed to take html code as input values. if i'm going to
store it to db, i use *_escape_string() [not addslashes()!]; when i'm
going to display it i can use htmlspecialchars() or use plain output (for
example, to use it for preview or inside iframe)
nobody but a developer can tell the purpose of an input value; so, in
my opinion, any input filtering is unlikely to help anyway and will
certainly broke existing apps.
and i'm agree with Ron that magic_quotes_gpc was a very big mistake -
now i'm required to do
if (get_magic_quotes_gpc()) $s = stripslashes($s);
on every input value because addslashes() is of no use to me - i need a
database-dependent escape_string() call for storing into db, or
htmlspecialchars() to display on page, etc. and there're many hostings where
i can't turn magic_quotes_gpc off. it'd be a disaster if this mistake is
repeated with input filtering
--
Best regards,
val mailto:val@vk.kiev.ua