Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26343
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.182.191 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Lsz2xFwLMd0A/906Je5dFAEfN+wcGixW/V2/Ef5hum9KxZio3knzdqunWxf5NKyafO55tqlzhARkhV5+nkHOMP358v92AljrqEnHPkB3nAxfS2HHwp0hwdakGg9XKFHMh9IzaSCXyvFN25FWDNTSC8V+9H9aGfVDGtuvMpCuj9A=
Message-ID: <4e89b4260611050813x42dc16fq74fc6ee240a0038d@mail.gmail.com>
Date: Sun, 5 Nov 2006 08:13:18 -0800
To: "Ilia Alshanetsky" <ilia@prohost.org>
Cc: "Peter Brodersen" <penguin@php.net>, "Rasmus Lerdorf" <rasmus@lerdorf.com>, 
	internals@lists.php.net
In-Reply-To: <1EA6BEDC-ED17-4FE7-BDB1-B5E5C4FC4BFB@prohost.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <454C5E50.4030108@zend.com> <454CFAA1.10104@lerdorf.com>
	 <aqvpk2df25h8lc2s6326i8igoh20uj6q1v@4ax.com>
	 <1EA6BEDC-ED17-4FE7-BDB1-B5E5C4FC4BFB@prohost.org>
Subject: Re: [PHP-DEV] allow_url_include and php:/data:
From: kingwez@gmail.com ("Wez Furlong")

I think it's a fair assumption that a random host specified in that
way be treated as suspicious and lumped in under the
disable-includes-by-default category.

If someone discovers that it breaks their app, when they read the docs
for allow_url_include it should be made very clear what the
implications are and what should be done prior to turning it on.

So i have no problem with disallowing includes for paths beginning
with a double backslash on windows, when allow_url_include is
disabled.

--Wez.


On 11/5/06, Ilia Alshanetsky <ilia@prohost.org> wrote:
> I think it'd be wrong to consider networked file system as non-local.
> Mostly because many times there are no ways to identify them reliable
> and the fact this is a perfectly valid usage that if disallowed by
> default would break a large number of applications.
>
>
> On 4-Nov-06, at 4:12 PM, Peter Brodersen wrote:
>
> > On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals
> > rasmus@lerdorf.com (Rasmus Lerdorf) wrote:
> >
> >> Yeah, we probably should.  Had a chat with Wez about it too.  Here is
> >> the patch.  I think this catches the cases we are interested in:
> >>
> >>  http://lerdorf.com/php/is_url.diff
> >>
> >> If someone could doublecheck it against those attacks it would be
> >> helpful.
> >
> >
> > Would requests to a smbserver, e.g.
> > \\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It
> > seems like smbserver requests are regarded as part of the default
> > filesystem wrapper.
> >
> > --
> > - Peter Brodersen
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
> Ilia Alshanetsky
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>