Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59730
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <4F8539E0.1090701@sugarcrm.com>
References: <CAGa2bXZ6G=Cphjrde3u1Mq3AAw-4yJk3s28vNe+Aybt2nGTumg@mail.gmail.com>
 <CAGa2bXZh4uMeUH_BSCFmfNgxS-SZC0svA9BPcSROjwmbfrtFyQ@mail.gmail.com>
 <CAGa2bXbhi4zdgd9Udo6KsoycDwg_Ke0Xe5h3_-fVDMvn_VfAjQ@mail.gmail.com>
 <A633CF2D7C7BED41B41F1E64F25507B806A5CDD6C2@MAILR001.mail.lan>
 <CAGa2bXZKfQ+HqOucwOnBH7gV84hpdxZb5qNY3t3ThF_zMKSGHw@mail.gmail.com>
 <4F850D06.10701@sugarcrm.com> <CAGa2bXZWrRh8RdMtKK_2_U_XmByC-O6hGRPrJyW5KwvE0CAK-w@mail.gmail.com>
 <4F8515AF.8060706@sugarcrm.com> <CAGa2bXZWudQeRm5h2eENGmgQDPfOqEmijB9-vPAvfKXLCfDiLw@mail.gmail.com>
 <4F851FE4.7000706@sugarcrm.com> <CAGa2bXbXdNcfHX_dM2EVVz_2JtS4cc+8pxneSLAd382TuQUg-w@mail.gmail.com>
 <4F8539E0.1090701@sugarcrm.com>
Date: Wed, 11 Apr 2012 19:17:17 +0900
Message-ID: <CAGa2bXYp-SnMS196PzxhWpiATJLNFB9VNYgLOtY-OxOxL4OncQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi,

2012/4/11 Stas Malyshev <smalyshev@sugarcrm.com>:
> Hi!
>
>> template_mode=on is not a actual security measure, but a
>> switch for language mode. template_mode=on has side
>> effect that makes PHP as safe as other scripting languages
>> or even better!
>
> PHP is as safe as other scripting languages right now. And you are using
> security talk to promote this proposal, including in this very email. If
> you don't see it as security feature, please do not talk about it as a
> security feature.

It is just like saying "Java is more secure than C"
C is danger than Java by its nature due to memory management.

PHP is danger than others by its mandatory embedded scripting.
Not like others, PHP exposes whatever files with permission with

include $_GET['var'];

I agree it's not a security feature, but language nature. However,
it is not reasonable that not to emphasise one of the most
important benefit, isn't it?


>
>> Therefore, it should not be misunderstood as perfect LFI
>> countermeasure even if I stressed on security meanings.
>> I'm stressing security because this actually helps PHP being
>> much safer than now.
>
> I don't see how it is "much safer". Exactly the same problem exists. Not
> only it is not "perfect" countermeasure, it's not countermeasure at all,
> judging from your description. It's like saying "I have SQL injection
> protection, but only if word "please" is not part of the SQL injection".
> It's not a real protection then.

There are only few perfect solutions for security. Neither
null byte protection nor allow_url_include are not a perfect
solutions.
(allow_url_include may be improved. Or is it already?)

>
>> PHP could be stronger against LFI compare to scripting languages
>> as I described in previous mail.
>
> PHP is as strong as any other language right now - if you include
> user-supplied code, you lost, don't do it - no problem.

This argument will be true for most of security countermeasures.
Anyway, non mandatory scripting could be think as a security
countermeasure, but it's side effect.

>
>> With this RFC, infamous reputation of LFI can be removed from PHP!
>
> I see no "infamous reputation" except the wrong one you are creating
> right now. include with user-supplied argument is a security hole, it
> has nothing to do with vulnerability in PHP.

Once again, it's the same for null byte protection.
I really like the null byte protection. I think it's brilliant.

I don't know about your country, but I know many developers/users
who think PHP is dangerous because of easy LFI.

According to basic risk manage textbook, risk is a formula that consists
by "Damage when indent happened" and "The probability that a incident happens".

Damage of LFI:  extreme (code execution/massive information disclosure)
Probability of LFI: common

This fact makes me to impossible to ignore the risk.
Since other people is discussing for having script only files,
considering to remove the known risk is reasonable act, I suppose.

I've spent a lot of time to describe how PHP users could be
protected from real life risk in the RFC. I hope you are not
against basic risk management principle. You don't have to
think of this RFC as security countermeasure, but the effect
of the RFC adoption should be considered.

I argue this RFC with respect to security, since security is the
primary motivation of this RFC to me. Applications like
Wordpress and other countless PHP apps are at the great risk,
since there are many developers including novice.

Why we shouldn't consider security benefits of the RFC?

Regards,


P.S.
You might have missed SQL injection and LFI.
(See bottom part of Introduction)
https://wiki.php.net/rfc/nophptags?&#introduction
SQL injections and LFI is common PHP app vulnerability.

I've updated a lot, please read at least this section also.
https://wiki.php.net/rfc/nophptags?&#why_this_is_better_than_now

--
Yasuo Ohgaki
yohgaki@ohgaki.net