Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59494
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.216.170 as permitted sender)
References: <CAORXhGLk8=bJ2TEo0OCzQCacjtGG=ZWYNuXf8Uu8oMNEm2WQ1A@mail.gmail.com> <CAGa2bXYP0kNA5PyvmdjoHZO91t8AojG9FjUe4nbCHhGjn2=MPg@mail.gmail.com> <CAH-PCH5UroCct9T6yuXuKNwTPstx8kAvdEbozMsWiEezjwO1JA@mail.gmail.com>
In-Reply-To: <CAH-PCH5UroCct9T6yuXuKNwTPstx8kAvdEbozMsWiEezjwO1JA@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
	boundary=Apple-Mail-4E50C445-2749-4246-8ECB-DF57D6E875B7
Message-ID: <9F1068CD-5D48-4587-8310-41C3C4CFECAC@punkave.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>,
 PHP Internals <internals@lists.php.net>
Date: Mon, 9 Apr 2012 06:46:47 -0400
To: Ferenc Kovacs <tyra3l@gmail.com>
Subject: Re: [PHP-DEV] PHP class files without <?php at the top
From: tom@punkave.com (Tom Boutell)

--Apple-Mail-4E50C445-2749-4246-8ECB-DF57D6E875B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I agree, there should be no limiting of unrelated language features to half-=
protect people who can't plan where uploads go.

Sent from my iPhone

On Apr 9, 2012, at 6:11 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:

>=20
> On Sat, Apr 7, 2012 at 10:48 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi,
>=20
> The only valid reason for removing <?php from PHP script would be
> security.
>=20
>=20
> 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 reque=
st 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 i=
s a vulnerability in itself)
> For preventing the uploaded files from be executed directly, one should pu=
t the uploaded files to a separate directory and disable the php execution f=
or that directory via the web server config (php_flag engine 0)
>=20
> I don't see how would the removal of the open tags prevent the malicious u=
ser 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 tha=
t the code properly checks that the uploaded file is a valid image (or any o=
ther file format which can be injected with arbitrary php code). If that che=
ck 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 file=
s to the given directory.
> - turn off the php engine for that directory
> - properly handle your file inclusions so you don't have LFI/RFI vulnerabi=
lities.
>=20
> --=20
> Ferenc Kov=C3=A1cs
> @Tyr43l - http://tyrael.hu

--Apple-Mail-4E50C445-2749-4246-8ECB-DF57D6E875B7--