Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59491
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXYP0kNA5PyvmdjoHZO91t8AojG9FjUe4nbCHhGjn2=MPg@mail.gmail.com>
References: <CAORXhGLk8=bJ2TEo0OCzQCacjtGG=ZWYNuXf8Uu8oMNEm2WQ1A@mail.gmail.com>
	<CAGa2bXYP0kNA5PyvmdjoHZO91t8AojG9FjUe4nbCHhGjn2=MPg@mail.gmail.com>
Date: Mon, 9 Apr 2012 12:11:03 +0200
Message-ID: <CAH-PCH5UroCct9T6yuXuKNwTPstx8kAvdEbozMsWiEezjwO1JA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Tom Boutell <tom@punkave.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b15af43476f6d04bd3c398d
Subject: Re: [PHP-DEV] PHP class files without <?php at the top
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b15af43476f6d04bd3c398d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 7, 2012 at 10:48 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi,
>
> The only valid reason for removing <?php from PHP script would be
> security.
>
>
I disagree here.
What you are talking about here is
https://www.owasp.org/index.php/Unrestricted_File_Upload
So a malicious user can upload a file containing php code and fire a
request which will execute it.
Executing it can happen directly (you request the uploaded file via http),
or indirectly (you can trick some other script to include it aka LFI which
is a vulnerability in itself)
For preventing the uploaded files from be executed directly, one should put
the uploaded files to a separate directory and disable the php execution
for that directory via the web server config (php_flag engine 0)

I don't see how would the removal of the open tags prevent
the malicious user from sending valid php code without opening tag.
I know that in your example you mentioned valid image files containing php
code with opening tag (in the image meta information), but that assumes
that the code properly checks that the uploaded file is a valid image (or
any other file format which can be injected with arbitrary php code). If
that check doesn't happen or not entirely safe, one could inject php code
even if we remove the opening tags.
So imo the correct defense against these kind of attacks is:
- properly handle the file upload paths, so the users can only upload files
to the given directory.
- turn off the php engine for that directory
- properly handle your file inclusions so you don't have LFI/RFI
vulnerabilities.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b15af43476f6d04bd3c398d--