Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59530
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: <9F1068CD-5D48-4587-8310-41C3C4CFECAC@punkave.com>
References: <CAORXhGLk8=bJ2TEo0OCzQCacjtGG=ZWYNuXf8Uu8oMNEm2WQ1A@mail.gmail.com>
 <CAGa2bXYP0kNA5PyvmdjoHZO91t8AojG9FjUe4nbCHhGjn2=MPg@mail.gmail.com>
 <CAH-PCH5UroCct9T6yuXuKNwTPstx8kAvdEbozMsWiEezjwO1JA@mail.gmail.com> <9F1068CD-5D48-4587-8310-41C3C4CFECAC@punkave.com>
Date: Tue, 10 Apr 2012 04:01:30 +0900
Message-ID: <CAGa2bXZFx=JW6eNLPdG+yQ0U1QGppbRzJ3wnpYZA4aAoXSGVjQ@mail.gmail.com>
To: Tom Boutell <tom@punkave.com>
Cc: Ferenc Kovacs <tyra3l@gmail.com>, PHP Internals <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)

Hi,

2012/4/9 Tom Boutell <tom@punkave.com>:
> I agree, there should be no limiting of unrelated language features to
> half-protect people who can't plan where uploads go.


You misunderstood the problem.

File upload does not matter.
Mandatory embed feature makes PHP vulnerable.
See my script injection example in RFC.

https://wiki.php.net/rfc/nophptags

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net


>
> Sent from my iPhone
>
> On Apr 9, 2012, at 6:11 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
>
> 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=A0malicious=A0user 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 whic=
h
> is a vulnerability in itself)
> For preventing the uploaded files from be executed directly, one should p=
ut
> 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=A0don't see how would the removal of the open tags prevent
> the=A0malicious=A0user from sending valid php code without opening tag.
> I know that in your example you mentioned valid image files containing ph=
p
> code with opening tag (in the image meta information), but that assumes t=
hat
> 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 fil=
es
> 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.
>
> --
> Ferenc Kov=E1cs
> @Tyr43l - http://tyrael.hu