Vulnerabilities in include/require should be fixed there, IMHO, not by
limiting the feature set of the language.
On Sun, Apr 8, 2012 at 5:34 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi,
>
> 2012/4/9 Arvids Godjuks <arvids.godj...@gmail.com>:
>> 8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki <yohg...@ohgaki.net>написал:
>>
>>> 2012/4/8 Ángel González <keis...@gmail.com>:
>>> > On 07/04/12 22:48, Yasuo Ohgaki wrote:
>>> >> Hi,
>>> >>
>>> >> The only valid reason for removing <?php from PHP script would be
>>> >> security.
>>> >>
>>> >> Since the null byte detection for fopen, remote/local script inclusion
>>> >> became much harder than before. However, it's still possible and very
>>> >> easy compare to other languages. Script execution is critical security
>>> >> problem and it's worth to make it better.
>>> >>
>>> >> If there is a switch that turns off PHP's template engine nature, PHP
>>> >> could be more secure than now.
>>> >>
>>> >> php.ini
>>> >> template_mode = on ; INI_ALL On by default
>>> >>
>>> >> php -t foo.php # template mode by default
>>> >> php -T foo.php # template mode off
>>> >>
>>> >> People has option to make their code a little secure than now
>>> >> or stick with current behavior.
>>> >>
>>> >> Regards,
>>> > How does it help security?
>>> > If any, requiring '<?php' before executable code makes easier to filter
>>> > out malicious files on apps with uploads in case there's a local
>>> > inclusion vulnerability somewhere.
>>> >
>>>
>>> Attackers may inject PHP script almost anything/anywhere since
>>> PHP code may be embed anywhere in a file.
>>>
>>> For example, malicious PHP script may be in GIF something like
>>>
>>> gif89a ...any data.. <?php exec('rm -rf /') ?>
>>>
>>> and all attacker have to do is include/require the data somehow.
>>> Attacker cannot do that this for other languages, since they are
>>> not a embedded language. I know case that attackers may inject
>>> malicious perl/ruby script in data files, but PHP is too easy
>>> compare to these languages.
>>>
>>> Regards,
>>>
>>> --
>>> Yasuo Ohgaki
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>> Improperly configured WEB server is not the reason to change the most basic
>> part of the language that will break every damn application out there.
>
> This is not an configuration issue, but a security vulnerability that
> can simply closed by disabling embed mode.
>
> As I mentioned already, injecting malformed PHP scripts into files
> is too easy compare to other languages. This could be improved
> by simple modification and we can maintain compatibility with it.
>
> I don't see anything wrong here.
>
> Yet another PHP script injection example.
> There are many applications that store user inputs in $_SESSION.
> Attacker can inject PHP script into $_SESSION, then locally include
> it. This is easy since attacker knew their session ID and path to
> session file is can be guessed easily. All attacker has to do is
> finding a vulnerable include()/require() to attack.
>
> Regards,
>
> --
> Yasuo Ohgaki
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
