ID: 48727 Updated by: [email protected] Reported By: matthew dot wilkinson at gmail dot com Status: Bogus Bug Type: Filter related Operating System: Irrelevant PHP Version: 5.2.10 New Comment:
I would love to turn it on by default, but I missed the boat on that by some 10+ years. At this point we can't do that. The best we can do is give administrators the ability to do this. It depends a bit on which side of the fence you are watching this from. For companies deploying many different applications on their servers, this option is invaluable. They can apply their own company-specific set of filters, deploy the various applications and go through and fix the few places that may break because they were not aware of the filter. Failing safely is the goal here and saying it doesn't solve the problem is untrue. It solves the problem for that company and for the admin who knows what he is doing. So, we aren't punishing people who know what they are doing on that side of the fence, we are giving them a much needed tool. On the other side of the fence, for someone writing portable software to run in as many environments as possible, it is more work, you are right, because you have one more difference to worry about. It is no harder to deal with than the magic_quotes situation though, and since that is now gone, we have swapped a rather useless option you need to worry about for a useful option, that you still need to worry about. Previous Comments: ------------------------------------------------------------------------ [2009-06-29 22:07:19] matthew dot wilkinson at gmail dot com While I see your point, since each server will have it's own "firewall" or even not one at all, this does not solve the problem because there is no consistancy across servers. Programmers who fail to check whether there is a default filter or not, or even server administrators who don't even know the option is there can still unwittingly create security holes, while the few who do will most likely be in the minority. This then punishes good programmers for doing things right, but allows irresponsible or lazy programmers and administrators to punch huge holes in your "firewall" without even realising it. I am not suggesting that the filtering of GET, POST etc. be disabled, I am merely suggesting that it not be configurable, and the same filtering is applied consistently, say "special_chars", in order that your "firewall" is actually there, programmers know that it will be there, and it is providing a measure of security against common attacks, such as SQL injection. ------------------------------------------------------------------------ [2009-06-29 21:50:32] [email protected] Definitely not. This is the only thing that allows someone to enforce a server-wide security policy on questionable code. And yes, it is magic_quotes-like, but it is magic_quotes done right. Having code be responsible for its own filtering has demonstrably failed miserably. With a default filter you have what I like to call a data firewall, much like a network firewall. You filter everything by default and then poke holes in that data firewall from your application. The traditional approach of letting everything through and then trying to remember to apply filters in the right places simply doesn't work. There should also be very few places where you need the raw user data. You should document those places so security-aware users can audit and apply their own data security in those places. ------------------------------------------------------------------------ [2009-06-29 21:39:43] matthew dot wilkinson at gmail dot com Description: ------------ While the data filtering extension is a fantastic thing, is providing the filter.default configuration option not just presenting a repeat of what magic quotes brought? ie. scripts will have to check if inputs are already filtered, potentially have to unfilter them or work around it. It should be the scripts responsibility to filter inputs if they need to be, and as magic quotes proved, when PHP tries to do it for the programmer, and in a configurable, non-consistent way, it becomes a hassle and inconvenience rather than a security feature. For these reasons, I think the filter.default and filter.default_flags configuration options should be removed, and no filtering done by PHP unless a script explicitly uses the filter_* functions. Reproduce code: --------------- --- >From manual page: filter.configuration --- ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=48727&edit=1
