ID: 48727 User updated by: matthew dot wilkinson at gmail dot com 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:
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. Previous Comments: ------------------------------------------------------------------------ [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
