Exactly right! Who knows what I'm gonna do with my input? - html output? - text output? - pdf output? - stdout or stderr output? - binary output? - <whatever> output? - file i/o? - mysql query? - mssql query? - db2 query? - encryption?
It is a BIG mistake to just assume any of these. And how about the values I get from files or database queries? They're not filtered. So what is stopping me from outputting potentially bad data from another source than $_GET or $_POST? It is a very very bad thing to assume. It's just like what happened with magic_quotes_gpc... People assumed (god knows why) that every $_GET or $_POST var was going to be used in a MySQL query. Awful judgement by the one who called that. If you, for example, use both the MSSQL and MySQL extension at the same time you had an even bigger problem, because both escape strings in their own ways. Please, don't make php.ini decide what I can and cannot do with my data. Now I know it's only a default, but it will mean I'm going to have to consider that this default could be anything on a given server and therefor code my way around the default at all times. Security is good, but this has the potential to to be a huge pain in the ass. Don't make a not-very-easy-to-reverse mistake. Ron "Val Khokhlov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
