I agree, which is why the rfc does not call for a php.ini option.
Sent from my iPhone
On Apr 9, 2012, at 3:20 AM, Arvids Godjuks <arvids.godj...@gmail.com> wrote:
> And you get same issues that existed with magic quotes, register variables,
> safe mode and other optional stuff that was required to run application when
> set specificaly and it would break if something set differently. PHP just got
> rid of it and you want to introduce a new optional feature that will change
> how PHP behaves.
>
> 09.04.2012 9:03 пользователь "Yasuo Ohgaki" <yohg...@ohgaki.net> написал:
> Hi,
>
> 2012/4/9 Tom Boutell <t...@punkave.com>:
> > Vulnerabilities in include/require should be fixed there, IMHO, not by
> > limiting the feature set of the language.
>
> I'm not insisting to remove embed feature, but give a option
> for programmers/administrators for better security.
>
> If one is comfortable with current behavior, they can keep
> using embed feature by default. Others who care security
> may disable embed feature by optional php.ini setting or CLI
> option.
>
> Half of Morihoshi's RFC was joke, but it's a serious proposal
> for people who persist better security. IMHO.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>
> >
> > On Sun, Apr 8, 2012 at 5:34 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> >> Hi,
> >>
> >> 2012/4/9 Arvids Godjuks <arvids.godj...@gmail.com>:
> >>> 8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki
> >>> <yohg...@ohgaki.net>написал:
> >>>
> >>>> 2012/4/8 Ángel González <keis...@gmail.com>:
> >>>> > On 07/04/12 22:48, Yasuo Ohgaki wrote:
> >>>> >> Hi,
> >>>> >>
> >>>> >> The only valid reason for removing <?php from PHP script would be
> >>>> >> security.
> >>>> >>
> >>>> >> Since the null byte detection for fopen, remote/local script inclusion
> >>>> >> became much harder than before. However, it's still possible and very
> >>>> >> easy compare to other languages. Script execution is critical security
> >>>> >> problem and it's worth to make it better.
> >>>> >>
> >>>> >> If there is a switch that turns off PHP's template engine nature, PHP
> >>>> >> could be more secure than now.
> >>>> >>
> >>>> >> php.ini
> >>>> >> template_mode = on ; INI_ALL On by default
> >>>> >>
> >>>> >> php -t foo.php # template mode by default
> >>>> >> php -T foo.php # template mode off
> >>>> >>
> >>>> >> People has option to make their code a little secure than now
> >>>> >> or stick with current behavior.
> >>>> >>
> >>>> >> Regards,
> >>>> > How does it help security?
> >>>> > If any, requiring '<?php' before executable code makes easier to filter
> >>>> > out malicious files on apps with uploads in case there's a local
> >>>> > inclusion vulnerability somewhere.
> >>>> >
> >>>>
> >>>> Attackers may inject PHP script almost anything/anywhere since
> >>>> PHP code may be embed anywhere in a file.
> >>>>
> >>>> For example, malicious PHP script may be in GIF something like
> >>>>
> >>>> gif89a ...any data.. <?php exec('rm -rf /') ?>
> >>>>
> >>>> and all attacker have to do is include/require the data somehow.
> >>>> Attacker cannot do that this for other languages, since they are
> >>>> not a embedded language. I know case that attackers may inject
> >>>> malicious perl/ruby script in data files, but PHP is too easy
> >>>> compare to these languages.
> >>>>
> >>>> Regards,
> >>>>
> >>>> --
> >>>> Yasuo Ohgaki
> >>>>
> >>>> --
> >>>> PHP Internals - PHP Runtime Development Mailing List
> >>>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>>
> >>>>
> >>> Improperly configured WEB server is not the reason to change the most
> >>> basic
> >>> part of the language that will break every damn application out there.
> >>
> >> This is not an configuration issue, but a security vulnerability that
> >> can simply closed by disabling embed mode.
> >>
> >> As I mentioned already, injecting malformed PHP scripts into files
> >> is too easy compare to other languages. This could be improved
> >> by simple modification and we can maintain compatibility with it.
> >>
> >> I don't see anything wrong here.
> >>
> >> Yet another PHP script injection example.
> >> There are many applications that store user inputs in $_SESSION.
> >> Attacker can inject PHP script into $_SESSION, then locally include
> >> it. This is easy since attacker knew their session ID and path to
> >> session file is can be guessed easily. All attacker has to do is
> >> finding a vulnerable include()/require() to attack.
> >>
> >> Regards,
> >>
> >> --
> >> Yasuo Ohgaki
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
> >
> >
> > --
> > Tom Boutell
> > P'unk Avenue
> > 215 755 1330
> > punkave.com
> > window.punkave.com
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
