¿Puede haber alguna vulnerabilidad en el código que representa imágenes en PHP?

Podría haber alguna vulnerabilidad en cualquier lugar, pero no hay evidencia de una aquí. Esto es lo que sucede:

• su navegador envía una solicitud de una página a un servidor
• el servidor envía una página HTML que contiene una referencia para una imagen ()
• el navegador analiza la página HTML (finalmente comienza a mostrarla) y ve que necesita solicitar una imagen en la URL original_page_URL/rendering-image.php
• el navegador envía una nueva solicitud a esa URL, probablemente diciendo que quiere una imagen
• el servidor devuelve los datos de la imagen y declara en los encabezados HTTP el tipo de imagen
• el navegador espera una imagen, lee la respuesta, encuentra el tipo de imagen, obtiene sus datos y los muestra

El problema cuando escribes directamente la URL en tu navegador, es que los navegadores a menudo usan la parte de la extensión para adivinar el tipo de respuesta, y aquí adivina erróneamente que php debería devolver el texto. Pero otras cosas podrían suceder aquí:

• como el navegador no tiene idea de qué es rendering-image.php , podría declarar que desea datos de texto / html
• el servidor obedece y declara que también envía texto, pero sigue enviando los datos de la imagen

Debes usar una herramienta como wireshark para obtener los encabezados de la solicitud y la respuesta para saber exactamente qué ha ocurrido.

Podría existir una vulnerabilidad si desea atacar al servidor que alberga rendering-image.php . Por lo general, esto consiste en encontrar una vulnerabilidad en ImageMagick o GD y explotarla. Esas son las dos bibliotecas de procesamiento de imágenes más comunes para PHP.

También podrían atacar el script en sí. Hubo un ataque bastante grande hace unos años con la participación de timthumb.php . TimThumb es una gota en el script que hace la manipulación de imágenes. Muchos desarrolladores web, incluidos muchos desarrolladores de temas de WordPress, utilizaron esto. La vulnerabilidad permitió la ejecución remota de comandos contra el servidor web.

Por qué esto no es motivo de preocupación para un ataque del lado del cliente es cómo se usa en el marcado HTML.

Si el desarrollador web codificó lo siguiente, un atacante podría explotar el script para devolver información y modificar el marcado para enviarlo al cliente:

<img src="<?php include('processing-image.php') ?>">

Que podría ser explotado para devolver lo siguiente:

echo "\"><script>alert('attack poc');<script/><\"";

Y esto se representaría como:

<img src=""><script>alert('attack poc');<script/><"">

Sin embargo, el marcado es en realidad:

<img src="processing-image.php">

Por lo tanto, la información se tratará como datos de imagen e intentará renderizarla en lugar de cambiar el contenido de la página. Dicho esto, podrían ser capaces de malformar la imagen donde podrían atacar el motor de renderizado del navegador. Pero es algo muy poco probable y difícil de atacar.

Ciertamente, podría haber vulnerabilidades en el código de procesamiento de imágenes. Por ejemplo, recientemente hubo algunas vulnerabilidades graves en ImageMagick , una popular biblioteca de procesamiento de imágenes. Una de esas vulnerabilidades podría llevar a la ejecución remota de código (RCE), que es tan mala como severa.

En lugar de inyectar código PHP en los datos sin procesar de la imagen, intente inyectar algo de Javascript para que en lugar de

    ÿØÿà JFIFHHÿápExifMM*;nÒ‡iæ<?php 
    $n3=2+2; echo $n3;?>¢£–hàŒÉ4‰/VvÀ‰®sQñ•¬ ­Œfå¿ç¡;#Sø...

sale como

    ÿØÿà JFIFHHÿápExifMM*;nÒ‡iæ"><script>prompt('password please') 
    </script>¢£–hàŒÉ4‰/VvÀ‰®sQñ•¬ ­Œfå¿ç¡;#Sø...

Si se ejecuta Javascript, llamaría a eso una vulnerabilidad.