Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59451
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <4F80C739.2060404@gmail.com>
References: <CAORXhGLk8=bJ2TEo0OCzQCacjtGG=ZWYNuXf8Uu8oMNEm2WQ1A@mail.gmail.com>
 <CAGa2bXYP0kNA5PyvmdjoHZO91t8AojG9FjUe4nbCHhGjn2=MPg@mail.gmail.com> <4F80C739.2060404@gmail.com>
Date: Sun, 8 Apr 2012 14:16:58 +0900
Message-ID: <CAGa2bXZSgV3bRPGMt6Esw16v3ErVMLVQy1fb8cZxdc=OokpXKg@mail.gmail.com>
To: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= <keisial@gmail.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP class files without <?php at the top
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

2012/4/8 =C1ngel Gonz=E1lez <keisial@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 =3D on =A0 ; INI_ALL On by default
>>
>> php -t foo.php =A0 # template mode by default
>> php -T foo.php =A0# 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