|
|
 |
Je�eli PHP zostanie skonfigurowany z w��czon� obs�ug�
"URL fopen wrapper", b�dzie mo�na u�ywa� adres�w HTTP i FTP
w wi�kszo�ci funkcji, kt�re jako parametr przyjmuj� nazw� pliku,
w��czaj�c w to instrukcje require() i
include(). Obs�uga "URL fopen wrapper"
jest w��czona domy�lnie, chyba, �e dodasz opcj�
--disable-url-fopen-wrapper do ./configure
(w wersjach do 4.0.3) lub ustawisz allow_url_fopen
na off w pliku php.ini (w nowszych wersjach).
Mo�esz wykorzysta� t� w�asno�� aby otworzy� plik na zdalnym serwrze,
przetworzy� jego zawarto�� i u�y� wynik�w w zapytaniu do bazy danych,
lub po prostu wy�wietli� plik dostosowuj�c jego wygl�d do swojej strony.
Przyk�ad 20-1. Pobieranie tytu�u zdalnej strony <?php
$file = fopen ("http://www.example.com/", "r");
if (!$file) {
echo "<p>Nie mo�na otworzy� zdalnego pliku.\n";
exit;
}
while (!feof ($file)) {
$line = fgets ($file, 1024);
/* Zadzia�a tylko wtedy, gdy tytu� i jego znaczniki s� w tej samej linii */
if (eregi ("<title>(.*)</title>", $line, $out)) {
$title = $out[1];
break;
}
}
fclose($file);
?> |
|
Mo�esz r�wnie� zapisywa� pliki na serwerach FTP, je�li po��czysz si�
jako u�ytkownik z odpowiednimi prawami dostepu i je�li plik wcze�niej
nie istnia�. Aby po��czy� si� jako u�ytkownik inny ni� 'anonymous',
musisz przes�a� nazw� u�ytkonika (i najprawdopodobniej has�o) w URLu,
np. 'ftp://uzytkownik:[email protected]/sciezka/do/pliku'. Mo�esz
u�y� tej samej sk�adni przy dost�pie do plik�w przez HTTP, je�li
wymagana jest autoryzacja.
Przyk�ad 20-2. Zapisywanie danych na zdalnym serwerze. <?php
$file = fopen ("ftp://ftp.example.com/incoming/outputfile", "w");
if (!$file) {
echo "<p>Nie mo�na otworzy� zdalnego pliku do zapisu.\n";
exit;
}
/* Tutaj zapisujemy dane. */
fputs ($file, $_SERVER['HTTP_USER_AGENT'] . "\n");
fclose ($file);
?> |
|
Notatka:
By� mo�e powy�szy przyk�ad nasun�� ci pomys�, by u�y� tej metody
do zdalnego zapisywania log�w, ale, jak wspomniano wy�ej, mo�esz
tworzy� jedynie nowe pliki. Aby zrealizowa� zdalne logowanie powiniene�
przyjrze� si� funkcji syslog().
User Contributed Notes
Korzystanie ze zdalnych plik�w |
  |
25-Apr-2000 08:21 |
|
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.
|
|
php!at!sturmgewehr.de
25-Feb-2002 01:42 |
|
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.
|
|
26-Feb-2002 11:24 |
|
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!
|
|
04-Apr-2002 02:21 |
|
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
|
|
18-Apr-2002 11:15 |
|
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.
|
|
02-May-2002 03:08 |
|
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.
|
|
06-May-2002 08:22 |
|
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
|
|
05-Jul-2002 02:19 |
|
It seems that it isn't possible to replace the standard browser signature
sent in an fopen(') call with another
value, i.e. the current value of $HTTP_USER_AGENT
|
|
|
|
| |
PUT method support