Hi Stas,
On Sat, Feb 28, 2015 at 1:53 PM, Stanislav Malyshev <smalys...@gmail.com>
wrote:
> > I have no intention to change current include/require syntax, except
> adding
> > 2nd parameter.
>
> This is a bit misleading since include is not a function, so there's no
> 1st parameter. Instead, it's a syntax construct. Of course, syntax
> construct's grammar can be changed, though I'm not sure if that wouldn't
> lead to unexpected effects in the parser. But maybe not.
>
Although it is variable length parameters, we already have "echo".
I'll check it see if Zend has problem with 2nd parameter when I write patch.
>
> Bigger issue is that if somebody is knowledgeable enough in security to
> go and change their code to use this option, why they aren't
> knowledgeable enough to fix their includes so this option is not required?
The root cause of the issue here is preciseness of the setting.
I think you agree that current "allow_url_include=Off" with INI_SYSTEM is
not precise at all.
We need to consider local and remote wrapper separately.
We may better to consider removing all remote wrapper support from
include/require.
It's rarely used and user can execute remote script easily with PHP. e.g.
eval(readfile('http://host/script')).
That said, one other possible solution is disallow most local wrappers for
include/require
and restrict script file extension. AFAIK, phar and user wrappers are the
exception
for "allow_url_include=Off", but there may be others. If we remove most
local wrapper
support(php://input, user wrappers, etc) from include/require, we don't
need 2nd parameter. i.e.
include('phar://phar_file.phar/script_in_phar.php'); // Requires .phar
extension to load PHP script from phar.
This requires users to change filename. Therefore, I propose to check
wrapper type
by 2nd parameter, but filename extension check works also. I don't mind to
use
this option.
There may be users that uses local wrapper to encrypt script files, etc. We
need
research if disabling most wrappers for include/require have problem or
not.
If there are other ideas, I appreciate it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
