Re: Comments on PHP security
| From: | Stanislav Malyshev | Date: | Sun, 14 Jan 2007 12:52:05 +0000 |
| Subject: | Re: Comments on PHP security | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-27442@lists.php.net to get a copy of this message | ||
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.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/