¿Riesgos de seguridad de hospedar imágenes proporcionadas por el usuario?

Una imagen podría seguir siendo una imagen válida y seguir conteniendo material malicioso, como comentarios incrustados u otros vectores de ataque (indefinidos). Uno, aunque antiguo, fue el ejemplo de vulnerabilidad de GDI JPEG en Windows desde 2004.

Creo que su principal preocupación es garantizar que su mecanismo de aceptación de imágenes sea simple y estricto. Querrá vigilar los errores de permisos de archivos, el agotamiento de recursos (quedarse sin espacio, atar recursos de red, etc.) y los ataques de ruta (por ejemplo, sobrescribir archivos).

Además, asegúrese de que todas las comprobaciones de manejo de cadenas estén definidas de manera estricta y precisa. Hubo una pregunta reciente en sec.SE sobre el ataque al código de carga de ASP que usó un mecanismo de búsqueda de cadenas menos estricto . / p>

Finalmente, busque en este sitio el término "subir". Algunos buenos ejemplos que pueden darle una imagen clara (¡no es un juego de palabras!) De todos los desafíos que puede enfrentar:

• ¿Qué pasos se deben tomar para validar las imágenes cargadas por el usuario dentro de una aplicación?
• ¿Cuáles son los riesgos de seguridad de permitir que los usuarios suban contenido a mi sitio?

Estoy de acuerdo en que es difícil protegerse contra un ataque cuando estás invitando a posibles atacantes con una forma de cargar archivos en tu servidor. El mejor consejo que puedo dar es utilizar múltiples enfoques para asegurar el contenido cargado.

Asegúrese de que el nombre de archivo que se envía esté limpio. Por ejemplo, no desea que alguien envíe '/../../index.html' como nombre de archivo y sobrescriba su página de índice.

Los nombres de archivo también deben verificarse para un tipo y extensión de mimo válidos (.jpg, .gif), sin embargo, también vale la pena investigar si su idioma de elección tiene alguna vulnerabilidad potencial cuando se trata de nombres de archivo, por ejemplo, cuando se trata de PHP a veces es posible pasar un byte nulo que puede pasar por alto las restricciones de extensión.

Al elegir un nombre de archivo personalizado para el contenido cargado, puede mitigar el riesgo de nombres de archivos maliciosos. Entonces, si acepta un tipo mime de 'imagen / jpeg', escríbalo en un archivo con un nombre de archivo de '[RANDOMSTRING] .jpg'.

Como comentó woliveirajr, verificar los bytes mágicos también puede ser una buena idea, sin embargo, no hay nada que impida que alguien cargue un script php backdoor que contenga algunos bytes mágicos, y luego continúe con el código <% php.

Una vez que esté satisfecho de haber asegurado su script de carga, verifique si su servidor web tiene una opción de configuración para deshabilitar la ejecución de scripts en su directorio de destino (como permisos de ejecución IIS ). Esto significaría que incluso si alguien puede omitir su lista blanca de carga, les resultará difícil tener un script para ejecutar en su servidor.

También tenga en cuenta los ataques que no están directamente relacionados con la ejecución del código en su servidor. He visto innumerables veces que las cargas de archivos están protegidas contra la ejecución del lado del servidor, sin embargo, la carga de un nombre de archivo de "..." da como resultado un ataque XSS.

Esta no es de ninguna manera una lista extensa, pero espero que te dé algunas ideas de las diferentes áreas en las que deberías protegerte.

Esto ya está completamente cubierto en las respuestas a las siguientes preguntas en este sitio:

• ¿Cómo puedo protegerme de las vulnerabilidades de las imágenes?

• ¿Es seguro almacenar y reproducir los tipos de mimos proporcionados por el usuario?

• ¿Utiliza la combinación de extensión de archivo y tipo MIME (como resultado del archivo -i -b) para determinar los archivos no seguros?

• ¿Cómo debo presentar documentos no confiables / no saneados (PDF, DOC, XLS) a los usuarios finales a través de la web?

• ¿Es seguro servir cualquier archivo cargado por el usuario solo con los tipos de contenido MIME incluidos en la lista blanca?

• ¿Las Opciones de tipo de contenido X realmente previenen los ataques de rastreo de contenido?

• ¿Cuáles son los riesgos de seguridad de permitir que los usuarios carguen contenido en mi sitio?

• ¿Qué pasos se deben tomar para validar las imágenes subidas por el usuario dentro de una aplicación?

• ¿Por qué debería restringir el tipo de contenido de los archivos que se suben a mi sitio?

• Cómo defenderse frente a la inclusión de archivos remotos de imágenes, por ejemplo. RFI utilizando un archivo .gif (Apache / PHP)?

• ¿Es posible inyectar HTML en la imagen para provocar XSS?

Échales un vistazo: ¡encontrarás gran cantidad de información excelente allí!

Carga de seguridad:

1. Código de seguridad:

   • Debes verificar la extensión usando la lista blanca (.jpg, .png, .doc ...). No utilice la lista negra (.php, .aspx ...)
   • No confíe en el tipo mime, que es enviado por el usuario.
   • Evite los nombres de archivos maliciosos cambiando el nombre a un nuevo nombre aleatorio, por ejemplo: Nuevo nombre de archivo = prefijo_MD5 (nombre de archivo). Extensión
   • Cambiar el tamaño de todas las imágenes.

2. Servidor de configuración:

   • Deshabilite la ejecución de scripts en su directorio de destino
   • Establezca su directorio de carga fuera del directorio del sitio web, por ejemplo: Ruta raíz del sitio web: / home / user / public_html / subir directorio: / home / user / upload_dir / Por lo tanto, el pirata informático no puede acceder directamente al archivo cargado malintencionado.