Hi all,
As some of you know that I'm trying to to eliminate script inclusion attack.
I come up with another idea which may have consensus.
PHP compiler is fast enough for almost all apps without script preloading.
However, large sites take advantage of opcache_compile_file() to maximize
the performance/response.
How about have a preloaded scripts configuration?
In addition, how about have a option that allows preloaded script only?
This way, PHP will execute only scripts listed in the "whitelist".
This is perfect solution for eliminating php script inclusion attacks.
In addition, users don't have to preload script one by one using
opcache_compile_file().
These options may be PHP/Zend or opcache options.
I hope everyone like the idea.
Any objections and/or comments?
Regards,
P.S. It's for PHP 7.1, of course.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo
OhgakiAs some of you know that I'm trying to to eliminate script inclusion attack.
I come up with another idea which may have consensus.PHP compiler is fast enough for almost all apps without script preloading.
However, large sites take advantage ofopcache_compile_file()to maximize
the performance/response.How about have a preloaded scripts configuration?
In addition, how about have a option that allows preloaded script only?This way, PHP will execute only scripts listed in the "whitelist".
This is perfect solution for eliminating php script inclusion attacks.
In addition, users don't have to preload script one by one using
opcache_compile_file().These options may be PHP/Zend or opcache options.
Does it mean you preload every script you could use ? In a typical application with potential access to, say, 4,000/5,000 PHP scripts, does it mean you will preload them all before running anything ? I hope it is not the case because it's generally impossible to know in advance which files you'll need. That's even the main benfit of autoloading.
An idea I had during a previous thread about script inclusion is a way to register a list of patterns that paths should match. The main script would register them and, then, every include/require would be filtered through the list. It just requires to run realpath() and match the result against a set of patterns. Don't know the performance impact. Just an idea.
Regards
François
None of this whitelisting-by-filename would be practical for our setup.
Have a look at what Smarty does with compiled templates and cached pages:
PHP includes generated on the fly, with filenames that are not known in
advance. For such usage a whitelisting per realpath prefix, would be the
only reasonable approach.
best regards
Patrick
None of this whitelisting-by-filename would be practical for our setup.
Have a look at what Smarty does with compiled templates and cached pages:
PHP includes generated on the fly, with filenames that are not known in
advance. For such usage a whitelisting per realpath prefix, would be the
only reasonable approach.
That whitelist is called open_basedir.
http://php.net/manual/en/ini.core.php#ini.open-basedir
johannes
Am 16.05.2015 16:32 schrieb "Johannes Schlüter" johannes@schlueters.de:
That whitelist is called open_basedir.
http://php.net/manual/en/ini.core.php#ini.open-basedir
Ahem. open_basedir is neither a list, nor is is restricted to restricting
include/require, which is the topic Yasuo is musing to do something about.
best regards
Patrick
Hi Johannes,
On Sat, May 16, 2015 at 11:32 PM, Johannes Schlüter johannes@schlueters.de
wrote:
That whitelist is called open_basedir.
http://php.net/manual/en/ini.core.php#ini.open-basedir
I'm trying to eliminate risks of script inclusion attack. open_basedir is
not good enough to
prevent
include('/path/to/upload/attack_image_file.png');
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Patrick,
None of this whitelisting-by-filename would be practical for our setup.
Have a look at what Smarty does with compiled templates and cached pages:
PHP includes generated on the fly, with filenames that are not known in
advance. For such usage a whitelisting per realpath prefix, would be the
only reasonable approach.
I'm aware of this, too. Thank you for bringing this issue up.
Options are
- Have some exceptions for dynamically created scripts
- Libraries should have precompile feature. e.g. precompile templates for
production. - Users/libraries should create intelligent white list for dynamically
created scripts.
(The file to be compiled does not have to exist at startup)
I prefer 3rd option.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Francois,
On Sat, May 16, 2015 at 10:04 PM, François Laupretre francois@php.net
wrote:
De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo
OhgakiAs some of you know that I'm trying to to eliminate script inclusion
attack.
I come up with another idea which may have consensus.PHP compiler is fast enough for almost all apps without script
preloading.
However, large sites take advantage ofopcache_compile_file()to
maximize
the performance/response.How about have a preloaded scripts configuration?
In addition, how about have a option that allows preloaded script only?This way, PHP will execute only scripts listed in the "whitelist".
This is perfect solution for eliminating php script inclusion attacks.
In addition, users don't have to preload script one by one using
opcache_compile_file().These options may be PHP/Zend or opcache options.
Does it mean you preload every script you could use ? In a typical
application with potential access to, say, 4,000/5,000 PHP scripts, does it
mean you will preload them all before running anything ? I hope it is not
the case because it's generally impossible to know in advance which files
you'll need. That's even the main benfit of autoloading.
The idea is preload everything in memory at startup. I'm thinking creating
the list like
find /var/www/myapp -name '*.php' > my_script_list
and use the list as white list.
We need to consider the case app has too many files for memory. Keeping
compiled
files in disk may be an option.
An idea I had during a previous thread about script inclusion is a way to
register a list of patterns that paths should match. The main script would
register them and, then, every include/require would be filtered through
the list. It just requires to runrealpath()and match the result against a
set of patterns. Don't know the performance impact. Just an idea.
I think the idea is good enough. However, it seems there are people does
not like it
because it requires a little overhead.
Good part of new idea is it does not require any overhead (except startup
delay for
compiling all scripts before execution) It also maximize performance when
app starts.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
In addition, how about have a option that allows preloaded script only?
I imagine it would be not hard to do with an extension overriding
compile_file, etc. the same way opcache does?
This way it can be implemented as independent functionality not needing
modification of the engine or opcache.
--
Stas Malyshev
smalyshev@gmail.com
Hi Stas,
On Sun, May 17, 2015 at 4:53 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:
In addition, how about have a option that allows preloaded script only?
I imagine it would be not hard to do with an extension overriding
compile_file, etc. the same way opcache does?This way it can be implemented as independent functionality not needing
modification of the engine or opcache.
Right. Users could implement whitelist by themselves.
However, isn't it nice to have this feature? It does not have any
performance penalty.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
Right. Users could implement whitelist by themselves.
I'm not talking about userspace implementation, I'm talking about
extension - which would make it work with any code as soon as extension
is loaded.
However, isn't it nice to have this feature? It does not have any
performance penalty.
It may be nice for some use cases, true - but that doesn't mean it
should be part of opcache. I think it's better to have it as an
extension - easier to debug, easier to develop, less complex code, etc.
--
Stas Malyshev
smalyshev@gmail.com
Hi Stas,
On Sun, May 17, 2015 at 6:16 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Right. Users could implement whitelist by themselves.
I'm not talking about userspace implementation, I'm talking about
extension - which would make it work with any code as soon as extension
is loaded.
I see.
Interesting idea.
However, isn't it nice to have this feature? It does not have any
performance penalty.It may be nice for some use cases, true - but that doesn't mean it
should be part of opcache. I think it's better to have it as an
extension - easier to debug, easier to develop, less complex code, etc.
Good point. Preload module may be a good option.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net