¿Puede haber una manera de explotar PHP include_once () cuando se filtra la entrada?

Question

¿Puede haber una manera de explotar PHP include_once () cuando se filtra la entrada?

#1 de duskwuff (5 votos)
#2 de OscarAkaElvis (2 votos)
#3 de Conor Mancone (2 votos)

6

Supongamos que existe este código para incluir otros archivos php de la entrada del usuario (sí, sé que es una mala elección):

$input = addslashes($_GET["input"]);

if (strpos($input, '../') === false) {
    include_once('/path/to/php/files/'.$input);
} else { echo('Invalid parameter!'); }

Este código agrega barras inclinadas a comillas simples y dobles, y luego verifica ../ en la cadena y, si no lo encuentra, incluye el archivo.

Suponiendo que el pirata informático haya escrito algún código para incluir en otra carpeta, y el pirata informático necesita acceder a ese archivo con ?input=../../folder/extcode , ¿puede haber una vulnerabilidad aquí?

php rfi lfi

pregunta Moonsik Park 04.11.2018 - 09:55

fuente

3 respuestas

Lea otras preguntas en las etiquetas php rfi lfi

¿Cómo determinar y controlar el alcance de los datos que pasan a través de la conexión VPN? Vector de inicialización con bloque de cifrado

score 5 · Answer 1

5

Este código es vulnerable a LFI cuando se ejecuta en sistemas Windows, porque esos sistemas aceptarán una ruta que contenga un recorrido de directorio que use barras diagonales inversas (como \..\..\ ).

respondido por el duskwuff 05.11.2018 - 02:19

fuente

score 2 · Answer 2

Lo que intentas bloquear es un LFI, pero creo que aún eres vulnerable. Este tipo de escenarios generalmente son potencialmente vulnerables a LFI y RFI.

Parece que su código no es vulnerable a RFI debido al prefijo de ruta local. (Enlace a LFI y RFI: enlace ).

Solo para aclarar, en el RFI el atacante intentará incluir un archivo remoto con una carga útil como http://evilsite/evil.php y, como puede ver, no contiene "../". Para estar protegido de esto, debe configurar en su php.ini el allow_url_include y asegurarse de que esté apagado. De lo contrario, podría ser hackeado usando RFI dependiendo de la entrada. Por lo tanto, es una buena práctica activar esto si no es necesario.

Hablando de LFI, creo que su código no es seguro. Ok, estás bloqueando cadenas como '../' pero tal vez el atacante podría codificarlo de alguna manera para evitar tu protección. Como @ game0ver dijo en un comentario, el atacante podría usar base64 o url-encoding y tal vez más. ¡Ten cuidado!

Entonces, resumiendo. Usted es NO vulnerable a RFI pero, SÍ , probablemente sea vulnerable a LFI .

score 2 · Answer 3

RFI y LFI

Lamentablemente, esto no parece ser explotable directamente. Como se comentó en otros comentarios, RFI no es posible debido al prefijo, y LFI no es posible en Linux porque (creo) no hay forma de escapar del strpos a través de la codificación. PHP descodificaría automáticamente cualquier cadena URL codificada antes de colocarla en la variable super $_GET , y cualquier codificación que no activara la búsqueda strpos tampoco se registraría como una barra diagonal para los fines de la llamada de inclusión (en por lo menos, no pude encontrar ningún vector de ataque exitoso). Sin embargo, tenga presente la respuesta de duskwuff: LFI es posible aquí en windows.

Ataques alternativos

Sin embargo, eso no significa que no pueda ayudar. En particular, las inclusiones abiertas como esta son el tipo de vulnerabilidad que te permite hacer que una vulnerabilidad más pequeña sea mucho más grande. El pensamiento inmediato que viene a la mente es verificar si este sitio web tiene una función de carga de imágenes en algún lugar. Si es así, y sabe dónde se guardan las imágenes, puede intentar incrustar PHP válido en los datos EXIF de una imagen jpg que luego carga al servidor. Normalmente, dicho código no es explotable, porque de todos modos no tiene que ejecutar su PHP en el servidor. Pero, con una inclusión abierta como esta, puede cargar su archivo y luego usar esta debilidad para ejecutarlo (ya que el archivo cargado probablemente existirá dentro de /path/to/php/files , la falta de una vulnerabilidad de LFI totalmente calificada no importará). Desde allí puedes hacer lo que quieras.

Utilizar una entrada de usuario para crear una ruta de inclusión es casi una siempre una mala idea, y rara vez es necesario. Incluso si no hay una debilidad inmediata, eso no significa que no pueda ayudarte a la hora de explotar otras.

Mejor seguridad

Creo que vale la pena tomarse un minuto para explicar cómo algo como esto debería ser asegurado. Es difícil dar una solución exacta sin más contexto, pero generalmente algo como esto se puede dividir en un proceso de dos pasos más seguro:

Use realpath para permitir que el sistema resuelva todos los intentos de recorrido de directorios y obtenga una ruta absoluta definitiva
Asegúrese de que la ruta absoluta final se encuentre en un directorio seguro para que pueda incluir archivos de, o una lista blanca explícita en contra de una lista de inclusión de seguridad

Nunca desea permitir que el usuario incluya un archivo arbitrario. Averigüe exactamente qué archivo se incluirá como resultado de sus aportaciones del usuario, y filtre eso a través de una lista blanca. Esa es la única manera de hacer esto de manera segura.