Stanislav Malyshev wrote: > SE>>And If I am not completely mistaken here unlike php://filter a > SE>>userstream will not give the THIS_IS_AN_INCLUDE_FLAG down to a stream > SE>>itself opens. > > I think I see what you mean now - i.e. that the user implementation might > be tricked into opening URL for include even though direct opening URL for > include is not allowed, and since it would do e.g. fopen, it may work > around the allow_url_include. > > I would say in most cases prohibiting anything but plain file wrapper for > include might be OK, however I know about a number of instances of > legitimate wrappers used for include - e.g. archive files like phar and > there are other, custom solutions that I saw that use wrappers as base. > Maybe it would be a good idea also to pass a flag to stream_open saying it > is used for include - though it won't fix broken code of course.
Hi, There is just such a flag passed to wrapper_open (at least inside pecl streams, I imagine you're talking about user streams) but that most likely would not be secure at all, as it puts the onus on the streams implementor, which is the problem right now. This is why I suggested disabling all remote access while calling a stream's open and read for include purposes, it centralizes the security access inside the zend engine where it is possible to audit and easier to control. In my opinion, it would be a pity to lose the design benefits of stream wrappers in the effort to gain more security when security can be gained without losing the benefits. I think it would be good to allow disabling all urls as Stefan suggested, but if there is a way to restrict to truly local stream wrappers, I would need to be educated as to how this is less secure than outright disabling urls. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
