Tengo un buen conocimiento de cómo funcionan las inyecciones de SQL. Veo que Google inurl upload.php le dirá a uno sobre las rutas de carga en un sitio web. Mi pregunta es que si una persona encuentra un camino por el cual puede subir imágenes solo, ¿puede seguir realizando inyecciones de sql? Por favor guíe.
En realidad pueden ser maliciosos. Uno de los desafíos del CTF del 29C3 fue en realidad cargar una imagen y realizar SQLi con ella.
¿Cómo funcionó? Bueno, las imágenes tienen metadatos, después de que subiste la imagen, los metadatos se extrajeron y se colocaron en la base de datos. Entonces, el truco para obtener la bandera era incluir SQL en los metadatos. (La entrada no fue correctamente saneada).
Sí y no.
Las imágenes son solo datos y, como tales, no son diferentes de los campos de formulario, los parámetros GET o cualquier otro tipo de datos proporcionados por el usuario. Realmente no hay nada especial en ellos, excepto que la mayoría de los demás datos que recibirás son de texto, y que normalmente no contienen nada que "posiblemente se parezca a SQL". Sin embargo, este último es un supuesto falso, ya que la mayoría de los formatos de archivo de imagen se ocupan de los metadatos, lo que facilita enormemente la integración de SQL en ellos, e incluso si no lo hacen, la creación de un archivo de imagen que contiene SQL como parte de la corriente de datos binarios No debería ser demasiado difícil.
En pocas palabras: si tiene la parametrización de su consulta en orden (como debería ser), entonces tiene exactamente tanto que temer como con cualquier otro dato suministrado por el usuario: siempre que pase el blob de imagen como parámetro y las llamadas de parametrización de la API de la base de datos no son vulnerables, está bien. Sin embargo, si decide concatenar cosas en su consulta que se han extraído de un archivo cargado, tiene un problema exactamente del mismo tipo que si tuviera una vulnerabilidad de SQLi a través de un campo de formulario.
Otra cosa que debes tener en cuenta al subir archivos es ejecución remota de código . Si no vigila, un atacante puede cargar un archivo PHP, disfrazado de imagen, y engañar a su script para que lo guarde en un lugar donde pueda alcanzarlo y ejecutarlo a través de apache (o, peor aún, en un lugar donde es recogido por un proceso local del sistema, en el peor de los casos, uno que se ejecuta como root). La defensa aquí es verificar e incluir en la lista blanca el tipo MIME de un archivo, asegurarse de que su extensión coincida con el tipo MIME, desinfectar (o simplemente reemplazar por completo) el nombre del archivo y almacenarlo en algún lugar fuera de docroot.
Las cargas de imágenes no son directamente vulnerables a la inyección de SQL, siempre y cuando se verifique que la imagen es en realidad una imagen. Con esto, me refiero a no simplemente confiar en el nombre del archivo. Podría ser posible que alguien suba una "imagen" que no sea una imagen y que contenga scripts de inyección SQL. Si la imagen contiene comandos SQL, entonces la carga de una imagen puede ponerlo en riesgo de inyección SQL indirectamente .
Hay una gran cantidad de otros problemas potenciales relacionados con la carga de imágenes, incluida la prevención de que los usuarios carguen imágenes infectadas (varios tipos de imágenes pueden estar infectadas con malware) y, si el sitio web no está bien diseñado, es posible que puedan use la imagen obtenida de la carga de imágenes para descubrir cómo realizar un ataque de Directory Traversal. Pero estos son muy diferentes de la inyección SQL.
Ver: (Ataques relacionados)
y, por último, el siguiente paso menciona los pasos para garantizar que el elemento que se está cargando sea en realidad una imagen.
El archivo de imagen por sí mismo no realizará la inyección de SQL, pero el archivo de imagen no viene solo; incluye un archivo nombre . Las inyecciones de SQL son sobre el código del servidor que incluye descuidadamente cadenas de caracteres dentro de una solicitud a una base de datos SQL, donde la cadena incluida proviene del usuario remoto potencialmente hostil. El nombre del archivo es una cadena que ha sido elegida por el usuario remoto. Por lo tanto ...
"Otra cosa que debes tener en cuenta al subir archivos es a distancia Ejecución de código. Si no tienes cuidado, un atacante puede subir un PHP. archivo, disfrazado como una imagen, y engañar a su script para guardarlo en un ubicación donde se puede alcanzar y ejecutar a través de apache "
Sí, esto es muy común. Muchos "proveedores" de shell realmente lo recomendarán como un método de carga preferido / predeterminado en la descripción del shell.
Es mejor apostar por cambiar el nombre del archivo aquí (+1) y algunos administradores de contenido / archivo lo harán de inmediato (es decir, K2 para Jommla).
Lea otras preguntas en las etiquetas sql-injection