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
