Luku 20. Using remote files

As long as support for the "URL fopen wrapper" is enabled when you configure PHP (which it is unless you explicitly pass the --disable-url-fopen-wrapper flag to configure (for versions up to 4.0.3) or set allow_url_fopen to off in php.ini (for newer versions)), you can use HTTP and FTP URLs with most functions that take a filename as a parameter, including the require() and include() statements.

Huomaa: You can't use remote files in include() and require() statements on Windows.

For example, you can use this to open a file on a remote web server, parse the output for the data you want, and then use that data in a database query, or simply to output it in a style matching the rest of your website.

Esimerkki 20-1. Getting the title of a remote page

<?php
$file = fopen ("http://www.example.com/", "r");
if (!$file) {
    echo "<p>Unable to open remote file.\n";
    exit;
}
while (!feof ($file)) {
    $line = fgets ($file, 1024);
    /* This only works if the title and its tags are on one line */
    if (eregi ("<title>(.*)</title>", $line, $out)) {
        $title = $out[1];
        break;
    }
}
fclose($file);
?>

You can also write to files on an FTP as long you connect as a user with the correct access rights, and the file doesn't exist already. To connect as a user other than 'anonymous', you need to specify the username (and possibly password) within the URL, such as 'ftp://user:[email protected]/path/to/file'. (You can use the same sort of syntax to access files via HTTP when they require Basic authentication.)

Esimerkki 20-2. Storing data on a remote server

<?php
$file = fopen ("ftp://ftp.example.com/incoming/outputfile", "w");
if (!$file) {
    echo "<p>Unable to open remote file for writing.\n";
    exit;
}
/* Write the data here. */
fputs ($file, $HTTP_SERVER_VARS['HTTP_USER_AGENT'] . "\n");
fclose ($file);
?>

Huomaa: You might get the idea from the example above to use this technique to write to a remote log, but as mentioned above, you can only write to a new file using the URL fopen() wrappers. To do distributed logging like that, you should take a look at syslog().

To use images and links in an included or required web page on a remote server, the calls in the remote files probably must use a fully qualified URL (). Don't know how universal this is, but it's been the case with several servers so far, and no exceptions found. Since the URLs on the remote page are probably using relative addressing, some added coordination is probably called for in most collaboration projects, where one site is serving content to be required or included on other sites.

Be careful when you use something like index.php?showpage=news.php and include() that $showpage file. If a malicious user would call your script as index.php?showpage= it would include that script and run it in *your* script's scope. That means it can read all files and variables your webserver has access to! Use file_exists() (which only works on local files) or check for 'tp:' in the filename prior to inclusion.

Greg: I had your problem, too, and I simply solved it by defining a <base href> tag in the script's HTML header. This points all relative links and image sources of the included page to the defined URL. E.g. you run your script on yourhost.com and you include a site from php.net then you would define <base href="> Of course you have to make your own references in the script global!

The easiest solution to this security risk is, in my oppinion, to add a host string in front of the url specified in the url adress. example: <html> <head><title>php.net</title></head> <body> <?php include("); ?> </body> </html> yup =) It's impossible to include() an page from another server. Regards, Christer Frostmo Norway www.frostmo.com

It's important to understand that remote files included/required into your script are NOT run on your server (as previous posts have suggested). Think about it this way: When I do this: <?php include('); ?> ..I'm actually asking PHP to make a separate HTTP request (just as your Web browser would) to www.example.com. So, point your browser to that location. Do you see any PHP code? No. You will only see HTML/text content. (On the off chance that .php wasn't associated with the PHP module/binary, the code would only be displayed. Thus, you would have to TRY to make a dangerous include scenario -- such as eval()'ing a remoted included file specified by the user.) Therefore, although this code may be vulnerable to an "untrustworthy information" attack (where the information displayed by your Web site isn't actually information you endorse, even though the information is ultimately transferred from your Web server), you are NOT vulnerable to malicious access to your Web server resources, even if visitors can specify any remote server/file that they please.

In my experience, I cannot agree with Toby. Scripts can indeed be run through remotely included files. All that needs to be done is put the PHP script into an HTML or other file that is not parsed by the remote server. This theoretically enables a malicious scripter to attack using a series of steps. For example, a simple .htm file with the content <?php echo phpinfo(); ?> will give quite a bit of information about the local system and possibly will give enough information to wreak havoc in the server's file system. If you would like to try this out, create an 'includetest.php' in a protected directory on your server with the content <?php include $inc; ?> Pass the file to be included as 'includetest.php?inc= The page is on one of my less used servers and can be accessed with any browser to show that it is simply the phpinfo() command I described above. I have tested this on 3 servers, all running PHP < 4.2.0, and unless this was fixed in the latest release, it still works.

You must be VERY careful if you allow a variable to control the URL of an include()ed file. A previous poster suggested: include("); This, however, won't work in all cases. For example, set the variable to "@www.evil-site.dom/evil-code.phps" Your carefully constructed pre-URL is now sent merely as a username to the attacker's web site. Stripping out "@" and ":" would be a good idea, and THEN you'd probably be safe. - Peter Jerde Minneapolis, Minnesota, USA


	downloads \| documentation \| faq \| getting help \| \| php.net sites \| links

search for in the