¿Cómo puedo estar protegido contra las vulnerabilidades de las imágenes?

Tengo algunas sugerencias:

1. Use un dominio separado. Aloje las imágenes en un dominio separado que se usa solo para alojar las imágenes proporcionadas por el usuario.

   Esto asegurará que muchos ataques a nivel de navegador solo puedan tener efectos limitados. Por ejemplo, supongamos que el navegador del usuario es vulnerable a los ataques de rastreo de tipo de contenido, por lo que es posible cargar una imagen que algunos navegadores tratarán como HTML que contiene Javascript malicioso; esta defensa garantiza que el Javascript malintencionado solo puede manipular las imágenes de otros usuarios y no puede acceder a las cookies o el contenido de su sitio u otras cosas sensibles a la seguridad. Sin embargo, esto no se defiende contra ataques de inyección de código que explotan una vulnerabilidad (por ejemplo, una saturación del búfer, una doble liberación) y ejecutan código nativo.

2. Defiende contra el rastreo del tipo de contenido. Sigue a prácticas que he descrito en otra parte para defenderse de los ataques de rastreo de contenido. La más importante es establecer un encabezado correcto Content-Type: en las respuestas HTTP en las que sirve la imagen. También puede ser útil incluir un encabezado X-Content-Type-Options: nosniff , para evitar que algunas versiones de IE intenten rastrear el tipo de contenido.

3. Convierta a un formato fijo. Convierta la imagen de entrada en un mapa de bits (conservando solo los datos de mapas de bits y eliminando todas las anotaciones adicionales), luego convierta el mapa de bits al formato de salida deseado. Una forma razonable de hacer esto es convertir al formato PBM, luego convertirlo a PNG.

   Esta no es una forma confiable de detener los ataques, pero reduce parte de la superficie de ataque disponible para el atacante. Por ejemplo, evita que el atacante adjunte metadatos malintencionados que están diseñados para explotar alguna vulnerabilidad en el analizador de imágenes. Tampoco le da al atacante una opción de formatos de imagen. Para derrotar a esta defensa, el atacante debe encontrar una vulnerabilidad en el decodificador PNG, en el código que lee los datos de píxeles de la imagen. Evita que el atacante explote una vulnerabilidad en el decodificador para algún otro formato de imagen o en la parte del analizador PNG que lee metadatos. Por lo tanto, aunque es potencialmente útil para reducir el riesgo, no esperaría que esta defensa sola fuera suficiente.

4. Considere la aleatorización. Considere la posibilidad de insertar un poco de ruido aleatorio en la imagen. Por ejemplo, puede recorrer todos los píxeles, y para cada una de las tres intensidades (correspondientes a RGB) para ese píxel, elija al azar entre sumar 1, restar 1 o dejar solo ese valor de intensidad. Esto introduce un poco de ruido en la imagen, pero es de esperar que no sea suficiente para que los espectadores lo noten. Y, si tiene suerte, puede hacer que algunos ataques tengan menos probabilidades de éxito, porque el atacante no puede predecir completamente el resultado de la transformación. Esta defensa es altamente heurística y ciertamente no se garantiza que sea efectiva, pero es posible que ayude, si se usa junto con las otras defensas que he descrito, como una especie de estrategia de defensa en profundidad de cinturones y tirantes. . Pero, por favor, comprenda que esta defensa por sí sola probablemente no sea adecuada.

Dependiendo de lo preocupado que esté por estos riesgos y de la sensibilidad de su sitio, no necesita hacer los cuatro. Si no está preocupado por las vulnerabilidades de inyección de código en el navegador, puede hacer solo el 1 y el 2. Si desea una protección parcial contra las vulnerabilidades de inyección de código en el navegador, puede hacer solo el # 1, el # 2 y el # 3.

Una posible solución sería volver a escribir el archivo como un formato conocido simple antes de mostrar la imagen en el sitio. p.ej. alguien sube una imagen (posiblemente con un exploit), inmediatamente, el servidor lee la imagen de forma segura y escribe una nueva imagen. Si el programa / script que usaba para leer la imagen cargada solo leía datos de color, la nueva imagen solo puede contener datos de color.

Supongo que depende de la perspectiva? Desde el punto de vista del usuario final, protegerse contra las vulnerabilidades (especialmente la memoria / desbordamientos de búfer) de las imágenes o cualquier otra fuente (de nuevo, que explota las vulnerabilidades de desbordamiento del búfer) se beneficiaría al asegurarse de que las funciones de protección de memoria estén completamente habilitadas. En Windows, se utilizan mecanismos como DEP (basado en NX / XD) y ASLR, entre otros, para reducir la probabilidad de ejecución de código debido a una saturación del búfer. DEP se puede activar de forma predeterminada para todas las aplicaciones en lugar de solo inscribirse, por ejemplo,

Esto se suma a las sugerencias habituales de uso de antivirus, mantenimiento de parches de software y otras cosas obvias.

Si tienes la opción de proteger tus aplicaciones para limitar el daño (posterior a la explotación), también es una vía viable. Como mínimo, puede utilizar el principio de privilegio mínimo (por ejemplo, al no usar cuentas administrativas donde no sea necesario).

Espero que ayude.