Stefan Esser wrote: > My 2cents, > > the actually best would be to completely forbid the usage of URLs inside > include/require and > introduce a new keyword: include_url that works like the current include > would work and > rename allow_url_include into allow_dangerous_urls (for include_url only). > > Basically this would protect everyone from URL includes with no way > around and if someone > really really wants this dangerous feature he has to explicitly request > it via include_url.
Hi, Although I think this is a decent idea, I would rather see a way that harmless url wrappers like phar (pecl.php.net/phar and more to the point pear.php.net/PHP_Archive) that only ever access local files can be more easily white-listed while even preventing any accidental network access by pecl extensions. The include_url solution, although effective, introduces another level of confusion to an already confusing situation: include require include_once require_once include_url include_url_once require_url require_url_once I had suggested a while back that it might also be possible to use an internal zend engine flag that is set during a call to include/require and friends that automatically disables all network access functions while the stream wrapper open and read of file contents is being called, prior to parsing the php into opcodes. This would mean a new zend API function (or macro) would need to be created that E_ERRORs out if include/require is being called, and it would need to be inserted in the front of all ftp, curl, pecl/ssh2, pecl_http, pecl/gopher, fsockopen and whatever else uses the so-called "internet" that I've forgotten. Fortunately, the list is finite. In this way, user stream handlers could be trusted, as they would simply not work (uncatchable E_ERROR) if any remote access is attempted. The same is true of pecl stream wrappers. As I recall, the last I heard was Rasmus said on IRC "that actually might work" and then it was forgotten by all parties including me. :) My idea would *not* protect against third-party extensions, but since these are not distributed with PHP and PHP has no control over them anyways, I doubt that this will be a real issue, as large hosting companies are unlikely to install anything third-party except perhaps Zend Optimizer. If "include_url" is introduced, it could be a large headache for PHP_Archive and will be a large headache for pecl/phar. Perhaps I'm the only one with this issue, but I think achieving full no-way internet include is relatively simple without introducing new keywords. I do like using "dangerous" in the ini settings, that is far more descriptive and accurate. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
