|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #48727 filter.default repeating past mistakes?
Submitted: 2009-06-29 21:39 UTC Modified: 2009-06-29 22:28 UTC
From: matthew dot wilkinson at gmail dot com Assigned:
Status: Not a bug Package: Filter related
PHP Version: 5.2.10 OS: Irrelevant
Private report: No CVE-ID: None
 [2009-06-29 21:39 UTC] matthew dot wilkinson at gmail dot com
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


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-06-29 21:50 UTC]
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 22:07 UTC] 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 22:15 UTC]
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.

 [2009-06-29 22:28 UTC] matthew dot wilkinson at gmail dot com
Is this not something to consider enabling by default for PHP 6 then, seeing as a lot of backwards compatibility is being broken already, why not make some necessary changes such as this?
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Jul 24 11:01:32 2024 UTC