Re: [RFC] No PHP tags
| From: | Yasuo Ohgaki | Date: | Tue, 11 Feb 2014 18:11:03 +0000 |
| Subject: | Re: [RFC] No PHP tags | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-72462@lists.php.net to get a copy of this message | ||
Hi all,
Let me rephrase more accurately. Does anyone argue that following fact is
debatable?
Local script inclusion is *much grater security threat* than local script
expose.
"Local script expose" is the only drawback of this RFC.
Currently, insecure include()/require() allows script execution.
With this RFC, insecure include()/require() may allow script expose.
If users care to script expose, they can simply add "<?php" at the top of
script
as it is now if script contains security sensitive data.
(Correction: Script expose could not be obvious.)
We can make secure program with register_globals=On as well as embed
everything by default. The same argument applies here. IMHO.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
On Wed, Feb 12, 2014 at 2:42 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi all,
>
> Let me rephrase. Does anyone argue that the fact
>
> Local script inclusion is *much grater security threat* than local script
> expose.
>
> "Local script expose" is the only drawback of this RFC.
> Currently, insecure include()/require() allows script execution.
> With this RFC, insecure include()/require() may allow script expose.
>
> Latter is obvious error as it shows wrong behavior while script execution
> is
> not obvious at all. If user care to script expose, they can simply add
> "<?php"
> at the top of script as it is now.
>
> We can make secure program with register_globals=On as well as embed
> everything by default. The same argument applies here. IMHO.
>
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
>
> On Mon, Feb 10, 2014 at 4:35 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> Hi all,
>>
>> "Optional PHP tags by php.ini and CLI options" RFC has been discussed
>> very long time.
>>
>> https://wiki.php.net/rfc/nophptags
>>
>> I would like to know is there anyone who would like not to have
>> this. I think it's good counter measure for LFI, but you might have
>> different perspective.
>>
>> If it is possible, I would like to address as much as opinions possible
>> before voting.
>>
>> Are there anyone who think we should have this?
>> What is the reason?
>>
>> Thank you
>>
>> --
>> Yasuo Ohgaki
>> yohgaki@ohgaki.net
>>
>>
>