Oliver Block wrote: > Hello Greg, > > I would first ask the following question: > > Why should the user be prevented to include remote site code? > > #1: hoster and users are equal > ------------------------------------------------ > > The hoster - as the "person" providing for the php infrastructure - is trying > to prevent the user (and his own system) - as his partner - from injected > code by malicous others. > > #2 hoster distrusts the user > --------------------------------------------- > > By unknown reasons, the hoster thinks that the user is limited in his > capabilities and therefore wants to prevent his system from the user. > --- > > Functions like fsockopen are adding useful features to php. Communication > between different systems can be useful. Therefore it should not be disabled, > if it cannot be abused easily by 3rd parties. > I would consider the possibility to inject malicous code by using a query > string, as beeing easily achieved. > > In my opinion, your proposal does satisfy #1 not #2. I see no sense though in > declaring a local stream as remote. But that's only a question of naming. > Wietse Venema called it tainted, as far as I remember. > > I do agree with your assumption that remote code is not malicous in general. > But it is susceptible for changes by 3rd parties. There it might be useful to > add a feature to sign remote code.
?? My assumption is *not* that remote code is not malicious. In fact, anyone developing under this assumption is asking to be attacked. I must have been unclear. My assumption was that the goal of allow_url_include=0 is to prevent *unintentional* inclusion of remote code, as this is a serious source of security vulnerabilities. The problem is that a URL is not inherently remote. file://blah.php is for instance obviously a local file. What is really annoying is that userspace streams are considered to be remote arbitrarily. Let's think about this for a second: if a user is too inexperienced to know they should never use include with arbitrary user input, what are the chances they will even *know* it is possible to write a user stream wrapper to simulate http:// or other remote protocols, let alone know how to do it? Stanislav's suggestion of auto-disabling allow_url_fopen in a userspace stream if allow_url_include=1 should prevent the last unintentional hole. However, it would also be nice if a userspace stream could register itself as being remote, as this would add another layer of security. Streams such as http://pear.php.net/HTTP_WebDAV_Client could then tell PHP not to use them if allow_url_include=0, removing another attack vector possibility. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
