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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
("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 <[EMAIL PROTECTED]> 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
>> > [EMAIL PROTECTED] (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&r=213474731
"Standing on the shoulders of some very clever giants!"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
