Re: allow_url_include and php:/data:

From: Date: Mon, 06 Nov 2006 08:55:05 +0000
Subject: Re: allow_url_include and php:/data:
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-26380@lists.php.net to get a copy of this message
I develop solely on and for our Windows network. I regularly use includes on 2 different servers via \\ rather than a mapped drive. I can see that adding \\ to the list of restrictions would be an issue for me. But also, it is a trivial ini update to remove the problem. And it DOES make PHP more secure. So, +1 to add \\ to the list of restrictions. Not so sure it would be as easy for shared host ISPs on Windows to fix this though. On 05/11/06, Peter Brodersen <penguin@php.net> wrote:
Hi, At first I didn't think there would be an easy solution as it isn't possible to distinguish between requests to a "local" SMB server and an "outside" server. Both are network requests. But on the other hand, requesting a file specific via network protocols in PHP such as SMB or HTTP or FTP really shouldn't be any different. One is asking PHP to perform the network operation to fetch a foreign resource. The key is that administrators would be able to map the needed SMB servers as local devices (just as one would mount a NFS share or for that sake make an FTP mount) thorugh the operating/file system. In that case requesting e.g. Z:\file.txt though a device on a SMB server share (or a NFS share or a FTP share or ...) would be perfectly fine. In that case it would be the operating/file system that is performing the network operation (based on central server administration) and not some random PHP code (possibly based on user input). Of course, those rare cases where one would actually need to fetch files through arbitrary external hosts through PHP one could just turn on allow_url_include. On Sun, 5 Nov 2006 08:13:18 -0800, in php.internals kingwez@gmail.com ("Wez Furlong") wrote: 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
-- - Peter Brodersen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&amp;r=213474731 "Standing on the shoulders of some very clever giants!"

« previous php.internals (#26380) next »