Re: [PHP-DEV] PHP 5.1 - operator overloading
TS>>No, you don't have to go that far. For starters, one could allow function TS>>(and possibly operator) overloading, based on type hints. The following is TS>>legal PHP5: That will already open the can of worms. And make each function call to go through all the hoops of signature matching. TS>>That's it. That's all you need for function overloading. You can safely keep Then you couldn't make operator+ that adds an integer to complex (and make it different from one adding complex to complex ) - because typehints do not include integers. TS>>sure we'd find a way to deal with any "worms". Sure. Just make another C++ and you are OK. The problem is we don't want another C++. TS>>overload resolution. However, how much on an impact this would have on TS>>execution speed remains to be seen. Exactly. Do you have any base to claim the speed impact would not be serious? Bring it forward. TS>>It was a reaction to the oft-mentioned argument that essentially says: "We TS>>don't need more advanced features." I got that feeling when you said "Using Nobody ever said "we don't need more advanced features". You know perfectly it is not true. What was said is that we probably don't need *this particular* feature. This has no relation to discussion of any other feature or discussion about having features in general. Having discussion in family-fight style along the lines of "You never listen to me!" rarely results in anything useful. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 - operator overloading
TS>>An advantage of function objects in C++ is that they can be used where TS>>functions are expected. Nevertheless, there are some features that can be Depending on what you mean of "expected". You can't use such object as a function pointer, for example. Yes, you can write Object() and make that do Object->operator(). In PHP that won't work, because $object() already has meaning. TS>>used to get something similar, such as create_function(): create_function is entirely different thing. It actually dynamically creates a function (which C++ can't do) which you can call by name. __call handler is much more like - though not entirely - to the operator() concept. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Exactly right! Who knows what I'm gonna do with my input? - html output? - text output? - pdf output? - stdout or stderr output? - binary output? - 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, > valmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
For the 18th time, nobody is talking about enabling it by default. -Rasmus Ron Korving wrote: Exactly right! Who knows what I'm gonna do with my input? - html output? - text output? - pdf output? - stdout or stderr output? - binary output? - 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
Re: [PHP-DEV] PHP 5.1
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:
register_filter('var1', FILTER_NUMBER);
register_filter('var2', FILTER_EMAIL);
register_filter('var3', 'my_customer_filter');
?>
Michael
Rasmus Lerdorf wrote:
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
Re: [PHP-DEV] PHP 5.1
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,
for example, can get through no matter how badly you may have written
the application. That is, the control of my server's security policy
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:
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:
register_filter('var1', FILTER_NUMBER);
register_filter('var2', FILTER_EMAIL);
register_filter('var3', 'my_customer_filter');
?>
Michael
Rasmus Lerdorf wrote:
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
Re: [PHP-DEV] PHP 5.1
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
"Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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,
> for example, can get through no matter how badly you may have written
> the application. That is, the control of my server's security policy
> 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:
> > 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:
> > >
> > register_filter('var1', FILTER_NUMBER);
> > register_filter('var2', FILTER_EMAIL);
> > register_filter('var3', 'my_customer_filter');
> >
> > ?>
> >
> > Michael
> >
> > Rasmus Lerdorf wrote:
> >
> >> 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
Re: [PHP-DEV] PHP 5.1
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 Ron Korving wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 > > Ron Korving wrote: > > 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.n
Re: [PHP-DEV] PHP 5.1
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
On February 6, 2005 10:21 am, Rasmus Lerdorf wrote:
> 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
>
> Ron Korving wrote:
> > 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Ron Korving wrote: 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). Once again, I am open to other solutions to the problem as stated. I don't see how an output filter could ever work. You can't exactly filter out raw html at the output stage since just about every PHP application ever written spits out HTML. People keep wanting a taint mode in PHP where user data can't be used for anything until validated and thus untainted. That would break far more things than this implementation since every single application would have to be modified for taint support whereas this approach only requires changes to the specific places in an application where raw data is required. And by the way, the security policy may include other things that aren't limited to output vulnerabilities like XSS. I might for example never want null characters coming into my system unless it is a file upload. I am pretty sure weeding out nulls isn't going to break your code in any way while at the same time it may very well plug security problems in a number of places. How about if I state it this way. As an application developer you are not expected to work around local security policies. Checking for and using the supplied filtering functions would be a good idea since they are likely faster and more robust than the userspace equivalents. Given that the hook has been available and documented for 2 years you can't possibly know what sort of filters are in place today and I can assure you that your code is unlikely to work in my environment. Having a standard set of filtering functions available that work in conjunction with the input filtering hook at least gives you a way to have a chance at working in my environment. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Benj Carson wrote: 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? I think the main problem is that Ron and Rasmus are talking about different stuff: a) Ron is a developer who knows how handle data in a secure way and doesn't want any magic to interfere. All he needs is easy support to do the necessary escaping depending on the use. I'm not sure if PHP doesn't already have the proper tools to do this. b) Rasmus is concerned about servers with lots of badly written code on it where he wants to provide a method to prevent security problems for these leaky programs by not letting any dangerous data come through thus compromising the server. Concerning a): - Something which might help me as a developer to track (initial) leaks down could be variable tainting. A simple scheme (direct output and basic string concatenation/construction) might help or might be bad. Dunno, would need more thoughts but OTOH I'm pretty sure this has been discussed in length here on the list :-) Concerning b): - A default filter might help, it definitely _will_ cause problems and lots of programs will need fixing so it's a very double-edged sword. Making it easy to disable it would result in little more security as people running into (even minor, i.e. easily fixable) problems would do just that: Disable it. You guys have more experience with magic_gpc to judge if it's leading to more problems than it solves. I'm very ambivalent about the whole thing but I think it's important that you stop rejecting the other side's points because you're looking at different problems. Over and out, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Ron Korving wrote: > > 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). > > Once again, I am open to other solutions to the problem as stated. I > don't see how an output filter could ever work. You can't exactly > filter out raw html at the output stage since just about every PHP > application ever written spits out HTML. People keep wanting a taint > mode in PHP where user data can't be used for anything until validated > and thus untainted. That would break far more things than this > implementation since every single application would have to be modified > for taint support whereas this approach only requires changes to the > specific places in an application where raw data is required. > > And by the way, the security policy may include other things that aren't > limited to output vulnerabilities like XSS. I might for example never > want null characters coming into my system unless it is a file upload. > I am pretty sure weeding out nulls isn't going to break your code in any > way while at the same time it may very well plug security problems in a > number of places. > > How about if I state it this way. As an application developer you are > not expected to work around local security policies. Checking for and > using the supplied filtering functions would be a good idea since they > are likely faster and more robust than the userspace equivalents. Given > that the hook has been available and documented for 2 years you can't > possibly know what sort of filters are in place today and I can assure > you that your code is unlikely to work in my environment. Having a > standard set of filtering functions available that work in conjunction > with the input filtering hook at least gives you a way to have a chance > at working in my environment. > > -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Benj Carson wrote:
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.
Neither does mine.. but...
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?
This would break pretty much every application ever written.
Consider:
http://www.yahoo.com/";>Yahoo!";
?>
The same scheme of proposed filters could instead be applied just-in-time as
values hit an output function.
This way, when I echo a $_GET variable, it could automatically be run
through htmlentities()
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
Re: [PHP-DEV] PHP 5.1
On February 6, 2005 12:27 pm, Sean Coates wrote:
>
> This would break pretty much every application ever written.
> Consider:
> echo " href="http://www.yahoo.com/";>Yahoo!"; ?>
>
Yeah, I realise the output filter would have to be intelligent. It couldn't
blindly filter every echoed string.
> 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";
>
The tainting model would not necessarily have to work the same way as it
does in Perl. Instead it could mark which parts of a string originated
from outside of PHP and then the output filter could only apply to those
regions. As strings are concatenated and sliced, the tainted regions would
be tracked and would stick with the strings themselves (e.g. as a list of
regions attached to each ZVAL?). For example:
$name = $_GET["name"]; // $name is marked as tainted from 0 to
// strlen($_GET["name"]) - 1
echo $name; // filter $name{0,} and output
$one = 'na';// $one is untainted
$two = 'me';// $two is untainted
$name = $_GET[$one.$two]; // $name is marked as tainted from 0 to
// strlen($_GET[$one.$two]) - 1
$tmp = "Hello $name"; // $tmp is marked as tainted from 6 to
// strlen($name) + 5
echo $tmp;// $tmp{0,5} is output; $tmp{6,} is passed to
// htmlentities() and then output.
$tmp = substr($tmp, 5); // $tmp is marked as tainted from 0 to
// strlen($name) - 1
$query = "INSERT $name INTO names"; // $query{7,strlen($name)-1} is tainted
mysql_query($query); // $query{7,strlen($name)-1} is passed to
// mysql_escape_string(), the rest of the string
// passes unfiltered.
I'm not sure of the feasibility of such a scheme (and obviously it would
have a performance impact), but it would "do the right thing".
That said, I think a standard set of input filters available to all PHP
developers would be a good thing. It would keep the number of posts about
email regexps to a minimum, among other things ;)
Benj
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Thu, 2005-02-03 at 19:58, Terje Slettebø wrote: > > From: "Stig S. Bakken" <[EMAIL PROTECTED]> > > > > On Thu, 3 Feb 2005, Sebastian Bergmann wrote: > > > > > Andi Gutmans wrote: > > > > Comments/Flames/Praises to this list :) > > > > > > Just curious: Have you considered adding the operator overloading > > > patch [1] by Johannes Schlüter that has been floating around for a > > > while? > > > > Operator overloading in PHP? Over my smoking carcass! > > > > PHP 5 returns object handles, which lets you do _exactly_ the same thing, > > only without the obscurity. > > You mean $a + $b? add($a, $b) is _not_ "exactly the same thing". > > > Nobody needs overloaded operators. Code should be readable, not > > cuddly-cute. > > Hm, I'm surprised by this response from someone who's name I recognise as an > active PHP contributor. The answer strikes me as either arrogant and/or > ignorant (note: I'm not saying you are that, but that's how the reply comes > across, given what what operator overloading is about). As I've pointed out > in other postings in this thread, operator overloading is about much more > than "just" "syntactic sugar". In C++, for example, it enables important > things such as function objects (being able to pass an object to a function, > for example, and have it behave as a function, enabling functional > programming, as well). This is not possible (possibly without jumping > through major hoops) in PHP. > > However, I see from this and other threads, that there's not much chance of > evolution of PHP to support more "advanced" features (which are common in > other scripting languages, as mentioned). It seems basic OO support is about > the only thing the PHP community can handle when it comes to expressiveness > in the language. Oh, well. > > Oh, and the comment about "Code should be readable, not cuddly-cute": > Operator overloading is about being able to express your intent clearer in > the code - leading to _more_ readable code than the corresponding function > alternative (see my arithmetic example in another posting). It has nothing > to do with cuteness, and everything to do with being to express your intent > clearly in the code. But it seems the community isn't ready for this. Too > bad. Maybe in PHP 10. My take on this is that you are, in many more cases than not, able to express your intent much clearer with good method names. This is especially true if operator overloading were not part of the language initially. Your example with complex math is an exception. Please explain how you see operator overloading making functional programming possible/easier in PHP? - Stig -- "Nearly all men can stand adversity, but if you want to test a man's character, give him power." - Abraham Lincoln -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
I'm sorry to keep dragging this out.. - A default filter might help, it definitely _will_ cause problems and lots of programs will need fixing so it's a very double-edged sword. Making it easy to disable it would result in little more security as people running into (even minor, i.e. easily fixable) problems would do just that: Disable it. You guys have more experience with magic_gpc to judge if it's leading to more problems than it solves. The reason magic_quotes_* doesn't work (apart from database ambiguity, regarding quote-escaping mechanisms) is that it may or may not be "on" on any given server (where the code may run). Therefore, to be safe, a good developer must do something like: $safe_a = get_magic_quotes_gpc() ? $_GET['a'] : addslashes($_GET['a']); // absolute simplest form My point is that magic_quotes_gpc is completely useless in an environment that may be shared by more than one application, or in an environment that isn't specifically designed for the application. The developer MUST check for it to be safe, so for a well-written application, it might as well be always off. Also, by the time user-code is executed, it's too late. The GPC mechanism has already run.. and can't be un-done. I _do_ have experience working in a "dirty" environment where I'm required to leave magic_quote_gpc "on" because of a legacy application, and my new application (ie, libraries we mix in with the "old" app) must perform the check for it (because we intend to eventually move away from all dependency on magic_quotes_gpc, and turn it off -- but that takes time, and money, and I have "real work" to do (according to my management)). I'm very ambivalent about the whole thing but I think it's important that you stop rejecting the other side's points because you're looking at different problems. Oh, to be clear, I agree that a central, "proper" way to filter input variables is definitely a good idea. I do, however, think that this should always be a user-space-called function. I also understand that this WOULD be useful in a very tightly controlled environment. I don't have any problem (and I already acknowledged that I carry no weight, here, so take this with a big grain of salt) with sticking something like this in PECL. This cannot be something that would be turned off in user-space, only turned ON in user-space, IMO. Yes, I understand that no one is advocating turning filtering on by default for all PHP apps (a la the register_globals switch), but even the possibility that this will be turned "on" by the admins of any significant fraction of server administrators (say 5-10%) means that all new code I write will have to check for this if there's ANY possibility that the "tainted" data would be useful. Again.. sorry for blabbing. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.1
Guys, I'm sure I'll annoy the heck out of some on this list, but there's still the question whether PHP should prevent any case of dumbness on the developer side. Whatever we do, some developers out there will be way more idiotic than we can ever imagine. And if any company choses that 16-year-old PHP "professional", (who, of course, delivers the same quality code as anyone else who's doing software development for a living), and their server gets hacked or something because of weaknesses in the code, they deserve it. PHP won't get more "respect" from the business side by implementing drop dead stupid stuff like automagic validation, but rather by getting what I mentioned a few days earlier - proper Unicode support, for example, or namespaces. Spare your breath for the important stuff. Nobody needs what's just being discussed here. Just my 0.02$, David > -Original Message- > From: Sean Coates [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 06, 2005 10:43 PM > To: Christian Schneider > Cc: Benj Carson; internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 5.1 > > I'm sorry to keep dragging this out.. > > > - A default filter might help, it definitely _will_ cause problems and > > lots of programs will need fixing so it's a very double-edged sword. > > Making it easy to disable it would result in little more security as > > people running into (even minor, i.e. easily fixable) problems would do > > just that: Disable it. You guys have more experience with magic_gpc to > > judge if it's leading to more problems than it solves. > > The reason magic_quotes_* doesn't work (apart from database ambiguity, > regarding quote-escaping mechanisms) is that it may or may not be "on" > on any given server (where the code may run). Therefore, to be safe, a > good developer must do something like: $safe_a = get_magic_quotes_gpc() > ? $_GET['a'] : addslashes($_GET['a']); // absolute simplest form > > My point is that magic_quotes_gpc is completely useless in an > environment that may be shared by more than one application, or in an > environment that isn't specifically designed for the application. The > developer MUST check for it to be safe, so for a well-written > application, it might as well be always off. Also, by the time user-code > is executed, it's too late. The GPC mechanism has already run.. and > can't be un-done. > > I _do_ have experience working in a "dirty" environment where I'm > required to leave magic_quote_gpc "on" because of a legacy application, > and my new application (ie, libraries we mix in with the "old" app) must > perform the check for it (because we intend to eventually move away from > all dependency on magic_quotes_gpc, and turn it off -- but that takes > time, and money, and I have "real work" to do (according to my > management)). > > > I'm very ambivalent about the whole thing but I think it's important > > that you stop rejecting the other side's points because you're looking > > at different problems. > > Oh, to be clear, I agree that a central, "proper" way to filter input > variables is definitely a good idea. I do, however, think that this > should always be a user-space-called function. I also understand that > this WOULD be useful in a very tightly controlled environment. I don't > have any problem (and I already acknowledged that I carry no weight, > here, so take this with a big grain of salt) with sticking something > like this in PECL. > > This cannot be something that would be turned off in user-space, only > turned ON in user-space, IMO. > > Yes, I understand that no one is advocating turning filtering on by > default for all PHP apps (a la the register_globals switch), but even > the possibility that this will be turned "on" by the admins of any > significant fraction of server administrators (say 5-10%) means that all > new code I write will have to check for this if there's ANY possibility > that the "tainted" data would be useful. > > Again.. sorry for blabbing. > > S > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Feb 6, 2005, at 5:02 PM, David Zülke wrote: Guys, I'm sure I'll annoy the heck out of some on this list, but there's still the question whether PHP should prevent any case of dumbness on the developer side. Whatever we do, some developers out there will be way more idiotic than we can ever imagine. And if any company choses that 16-year-old PHP "professional", (who, of course, delivers the same quality code as anyone else who's doing software development for a living), and their server gets hacked or something because of weaknesses in the code, they deserve it. PHP won't get more "respect" from the business side by implementing drop dead stupid stuff like automagic validation, but rather by getting what I mentioned a few days earlier - proper Unicode support, for example, or namespaces. Spare your breath for the important stuff. Nobody needs what's just being discussed here. Just my 0.02$, I disagree. The fact that XSS attacks remain one of the largest issues plaguing large so-called enterprise sites points to data validation being a hard thing to remember to always do, and to do 'right'. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Feb 6, 2005, at 2:14 PM, Christian Schneider wrote: Benj Carson wrote: 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? I think the main problem is that Ron and Rasmus are talking about different stuff: a) Ron is a developer who knows how handle data in a secure way and doesn't want any magic to interfere. All he needs is easy support to do the necessary escaping depending on the use. I'm not sure if PHP doesn't already have the proper tools to do this. I don't know Ron, but you should almost certainly change that to 'Ron is a developer who thinks he knows how to handle data' The key point being that few people intentionally write exploitable code (and no amount of automatic fixup will save you from those crowd). Even people that are aware of security issues in input validation routinely make mistakes. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
David Zülke wrote: Guys, I'm sure I'll annoy the heck out of some on this list, but there's still the question whether PHP should prevent any case of dumbness on the developer side. Whatever we do, some developers out there will be way more idiotic than we can ever imagine. And if any company choses that 16-year-old PHP "professional", (who, of course, delivers the same quality code as anyone else who's doing software development for a living), and their server gets hacked or something because of weaknesses in the code, they deserve it. PHP won't get more "respect" from the business side by implementing drop dead stupid stuff like automagic validation, but rather by getting what I mentioned a few days earlier - proper Unicode support, for example, or namespaces. Spare your breath for the important stuff. Nobody needs what's just being discussed here. The Unicode stuff is coming too, don't worry, but you are dead wrong about nobody needing a way to enforce a corporate-wide security policy. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Sunday, Feb 6, 2005, at 23:07 Europe/Copenhagen, George Schlossnagle wrote: I disagree. The fact that XSS attacks remain one of the largest issues plaguing large so-called enterprise sites points to data validation being a hard thing to remember to always do, and to do 'right'. So how do you feel about impact magic_quotes had on preventing SQL injection attacks? In my own personal opinion it had marginal positive impact at best and it didn't prevent people writing queries like "delete from customer where customer_id=".$_GET['id']. It did however had a major negative impact on the portability of the PHP code written. Most objections here on ini triggered filter mechanism stem from the fear that we're heading towards the same outcome. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Fri, Feb 04, 2005 at 01:00:23AM -0800, Rasmus Lerdorf wrote:
> And everyone here understands
> that &{ needs to be stripped or entitied as well, right?
"&{"? Can you elaborate what that is and why it's a problem,
please?
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Feb 6, 2005, at 6:51 PM, Edin Kadribasic wrote: On Sunday, Feb 6, 2005, at 23:07 Europe/Copenhagen, George Schlossnagle wrote: I disagree. The fact that XSS attacks remain one of the largest issues plaguing large so-called enterprise sites points to data validation being a hard thing to remember to always do, and to do 'right'. So how do you feel about impact magic_quotes had on preventing SQL injection attacks? In my own personal opinion it had marginal positive impact at best and it didn't prevent people writing queries like "delete from customer where customer_id=".$_GET['id']. It did however had a major negative impact on the portability of the PHP code written. I think that magic_quotes was the wrong solution for the SQL injection problem. The right solution for that is to use a database layer with auto-escaping built into it (via something like PDOs emulated bindings). I realize that's not a real answer to your question, but I think that the issues with magic_quotes (which I agree is a travesty) stem from it being the wrong solution to the problem it tried to tackle. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
David Zülke wrote: Guys, I'm sure I'll annoy the heck out of some on this list, but there's still the question whether PHP should prevent any case of dumbness on the developer side. Whatever we do, some developers out there will be way more idiotic than we can ever imagine. And if any company choses that 16-year-old PHP "professional", (who, of course, delivers the same quality code as anyone else who's doing software development for a living), and their server gets hacked or something because of weaknesses in the code, they deserve it. PHP won't get more "respect" from the business side by implementing drop dead stupid stuff like automagic validation, but rather by getting what I mentioned a few days earlier - proper Unicode support, for example, or namespaces. Spare your breath for the important stuff. Nobody needs what's just being discussed here. Just my 0.02$, David I'll add my agreement to this message. If proper unicode support is coming as Rasmus says, that's great; but functionality with this much potential for disrupting portability should remain in PECL. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ApacheCon Europe 2005 - Call for Papers
Hello all, the CfP for ApacheCon Europe 2005 is open: http://www.apachecon.com/2005/EU/index.html/e=MjAwNS9FVQ submission deadline: 22h30 EST Friday, 04 March 2005 ApacheCon Europe 2005 will be held from July 18th to 22nd in Stuttgart/Germany. /Georg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
