r.korving

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

rasmus

For the 18th time, nobody is talking about enabling it by default.

-Rasmus


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

michael.virnstein

I'm not a developer of php, but developing in php, i can say that it'd
be nice to be able to filter *any* data, *if I want to*, not just $_GET,
$_POST etc.. I think it is a good idea to have a easy to use filter api,
but please don't make it an ini setting, so i have to call a function to
get the original data if it is enabled or have to call ini_set first to
disable it. I know you'd like to help securing applications even for not
experienced programmers, but that's not the way to go imo.
I honestly don't want someone to dictate which data is ok for my
application and which is not. Simply give me a nice api, with default
filter types and probably the possibility to register custom functions
to filter data, so i can call the functions if i want to. Or let me
register filter types for certain variables, something like:
<?php

register_filter('var1', FILTER_NUMBER);
register_filter('var2', FILTER_EMAIL);
register_filter('var3', 'my_customer_filter');

?>

Michael


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

rasmus

From a developer's perspective I can see your point. But if I am going
to run your application on my server, I want a way to make sure no XSS,


has to be up to me, not you. So while there will be filtering functions
for you to use, there will also be an ini setting for administrators to
force a default filter.

-Rasmus Michael Virnstein wrote:


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

r.korving

Well there you go. A default filter. So I don't know what you mean with "For
the 18th time, nobody is talking about enabling it by default.", because an
administrator might. And I as a developer have no clue. Personally, I don't
see why a webserver admin should need to secure his server through means of
a default filter. There are good ways to secure a machine. This is not one
of them You don't secure a server by setting a default that a user can
override. So really, that is no argument.

Like I said before. If a webserver admin dicatates the default way $_GET and
$_POST data is perceived, a website developer has no choice but to use this
filtering mechanism on every input variable he receives, because he just
can't rely on PHP's default behaviour anymore. You see, not everybody agrees
that you can't do without input filtering (myself for example), so in the
end, there's no doubt in my mind that forcing a new magic default on
PHP-users will make a lot of people unhappy.

Ron


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

rasmus

Well, you already have the problem. The filter hook has been in PHP5
for 2 years now and people are using it already. And yes, your code is
likely not to work on those servers if you are expecting raw html tags
to get through.

There are plenty of people who have to operate under a mandated security
policy. That policy may state among many other things that no
user-originated raw html tags may ever be displayed. Now, if I gave you
that problem and a couple of thousand servers running millions of lines
of PHP code, how would you solve it?

My solution is to block everything and then go and fix the few places
where raw tags are actually supposed to get through and make sure those
few places are validated correctly.

You seem to be be indicating that you would go through every line of
code and make sure every single application did all validation correctly.

Want to wager a guess at who would be done first?

I am wide open to other approaches to solving this problem.

-Rasmus


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

r.korving

My problem with this approach is that data is reformatted before being used,
while my philosophy has always been to always store data in it's raw
original version and format when outputting (which would always be
consistent). So in this case, if someone (say in the forum of a website)
starts using html, I would store the raw data in some database table.

This makes it example for certain users to say "I want to see html code in
other people's posts" and others to say "I don't want to see their html
code". In the first case I will output the text in a pretty raw form, and in
the second case I will pass the data through htmlentities(). Personally, I
think it's a bad idea to alter data before storing, because you can never go
back to the way it was. If I store certain information, I store it raw. When
I output it, I can choose how to reformat the data, because it's not always
a HTML-based situation I'm going to be in.

So yes, your approach is faster, but less flexible. My approach is
consistent. I always store and handle my data raw, and when I output it, I
consider reformatting. In your case you create exceptional situations where
the default filter (which is server based, not application or website based)
is not applicable. Problem is though that many people won't be able to rely
on a default filter and therefor have to filter everything on input. And
with the way I want to handle my data (only reformatting on output) I don't
want to do any filtering at all on the input. Only on the output.

It's a very weird idea to me to filter out HTML on input, because the only
place where HTML tags could be abused is in the output. So that's where
filtering should take place, imho. Maybe it's hard to figure out a way to do
this the easiest way, but failing to come up with an output filtering idea
should not result in input filtering "just because it's easier" (which, I'm
very sorry to say reminds me once again of magic_quotes_gpc... it's much
easier to define such a rule globally, but you end up with a lot of crap).

And I don't mind writing "htmlentities()" all the time when I output data
from my databases to a browser. You talk about a global policy, but a
developer's policy should always include good security. So going over all
code and add "htmlentities" will not happen to said developer. He has
already done that while coding. Maybe if the name of "htmlentities" was only
4 characters like "echo", some people would be more eager to do output
filtering from the start?

By the way, I use PHP for software development and I'm never in the position
where a webserver admin would control what I can and cannot do, but I'm just
anticipating trouble for people who are in that position.

Ron

the

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

benjcarson

My opinion may not carry any weight here, as I'm just a user of PHP, but
this discussion has given me a few ideas. As Ron and Val (and others) have
pointed out, there's no way for PHP to know how an *input* value is going
to be used. Would it perhaps be better to filter *output* values?

The same scheme of proposed filters could instead be applied just-in-time as
values hit an output function. I'm not sure how exactly it could be
implemented, but something similar to the pg_{select|insert|update|delete}
scheme might work. For html output, echo() and print() could be modified.

This way, when I echo a $_GET variable, it could automatically be run
through htmlentities(), and when I insert the same variable into a database
it will be run through pg_convert()/pg_escape_string(). I can see there
being difficulties identifying dangerous values if variables have been
interpolated into a string, but perhaps a tainting model could solve this.

(The in-house PHP framework that we use does basically the above. Our
database objects read metadata for the tables they manipulate and their
__set() methods automatically convert values to the appropriate column
types. Our template objects and functions automatically use htmlentities()
or addslashes() as required when outputting variables.)

Just my $0.02,


Benj Carson


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

r.korving

If you think there are a lot of people who want this feature as you propose
it, then I won't oppose such implementation. I guess the only thing I
wouldn't be able to live with would be a default setting after a fresh PHP
install where there is a non-raw filter in place. Beyond that, if there are
a whole lot of people who would like to see this feature (you are obviously
experienced with situations where such a default filter setting would come
in very handy, so I have no doubt there are more people who agree) then I
can't oppose it.

But please, don't make the magic_quotes_gpc mistake of having it behave
non-raw by default in a fresh php.ini. Please, let the default be "raw"
(with of course the possibility for people to change it).

Ron


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

sean

Neither does mine.. but...


This would break pretty much every application ever written. Consider: <?php
echo "<html><body><a href="http://www.yahoo.com/">Yahoo!</a></body></html>";
?>

See the discussion on variable-variable superglobals.

You could definitely catch:
echo "Hello {$_GET['name']}\n";

and MAYBE:
$name = $_GET['name'];
echo "Hello {$name}";

but (without a LOT of reference catching, and other nasty hackery that
may or may not work in the end) not:
$one = 'na'; $two = 'me';
$name = $_GET[$one.$two];
echo "Hello $name";

....

But I'm with Derick on this.. it's another magic_quotes_* waiting to
happen, if it can EVER be turned on by default. (MHO).

S

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php