¿Qué problemas de seguridad aparecen cuando los usuarios pueden cargar sus propios archivos?

Question

Me preguntaba qué problemas de seguridad aparecen cuando el usuario final de un sitio web puede subir archivos al servidor.

Por ejemplo si mi sitio web permite a los usuarios cargar una imagen de perfil, y lo sube un usuario algo dañino en su lugar, lo que podría suceder? ¿Qué tipo de seguridad debo configurar para prevenir ataques como este? Estoy hablando de imágenes, pero ¿qué pasa con el caso en que un usuario puede subir algo a un tipo de aplicación de archivo-bóveda?

Es más una cuestión general que una pregunta sobre una situación específica, por lo que ¿cuáles son las mejores prácticas en esa situación? ¿Qué haces usualmente?

supongo: validación de tipo de carga, different permissions for uploaded files ... ¿qué más?

EDIT: Para aclarar el contexto, estoy pensando en una aplicación web donde un usuario puede cargar cualquier tipo de archivo y luego mostrarlo en el navegador. El archivo se almacenaría en el servidor. Los usuarios son quienes usan el sitio web, por lo que no hay confianza involucrada.

Estoy buscando respuestas generales que podrían aplicarse a diferentes idiomas/framework y entornos de producción.

Answer 1

Su primera línea de defensa será limitar el tamaño de los archivos cargados, y eliminar cualquier transferencia que sea mayor que esa cantidad.

La validación de la extensión de archivo es probablemente una buena segunda línea de defensa. La validación de tipo se puede realizar más adelante ... siempre que no confíe en el tipo mime (proporcionado por el usuario) para dicha validación.

¿Por qué validar la extensión de archivo? Porque eso es lo que la mayoría de los servidores web usan para identificar qué archivos son ejecutables. Si sus ejecutables no están bloqueados en un directorio específico (y lo más probable es que no lo estén), los archivos con ciertas extensiones se ejecutarán en cualquier lugar bajo la raíz del documento.

La verificación de la extensión de archivos se realiza mejor con una lista blanca de los tipos de archivos que desea aceptar.

Una vez que validar la extensión del archivo, a continuación, puede comprobar para verificar que dicho archivo es del tipo de extensión de sus reclamaciones, ya sea mediante la comprobación de bytes mágicos o utilizando el comando de archivo UNIX.

Estoy seguro de que hay otras preocupaciones que eché de menos, pero espero que esto ayude.

Answer 2

Suponiendo que usted está tratando con sólo imágenes, una cosa que puede hacer es utilizar una biblioteca de imágenes para generar imágenes en miniatura/tamaños de imagen consistente, y tirar el original distancia cuando haya terminado. Entonces efectivamente tiene un único punto de vulnerabilidad: su biblioteca de imágenes. Suponiendo que lo mantengas actualizado, deberías estar bien.

Los usuarios no podrán cargar archivos zip o realmente ningún archivo que no sea de imagen, porque la biblioteca de imágenes se eliminará si intenta cambiar el tamaño de los datos que no son de imagen, y solo se puede capturar la excepción. Sin embargo, es probable que desee hacer una comprobación preliminar de la extensión del nombre de archivo. No tiene sentido enviar un archivo a través de la biblioteca de imágenes si el nombre del archivo es "foo.zip".

En cuanto a los permisos, bueno ... no establezca el bit de ejecución. Pero, de manera realista, los permisos no lo ayudarán a protegerse mucho contra la entrada de usuarios maliciosos.

Si su entorno de programación lo permite, usted va a querer ejecutar algunos de estos controles, mientras que la carga está en curso.Un cliente HTTP malicioso puede enviar potencialmente un archivo con un tamaño infinito. IE, simplemente nunca deja de transmitir bytes aleatorios, lo que resulta en un ataque de denegación de servicio. O tal vez solo carguen un video como su foto de perfil. La mayoría de los formatos de archivo de imagen también tienen un encabezado al principio. Si un cliente comienza a enviar un archivo que no coincide con ningún encabezado de imagen conocido, puede cancelar la transferencia. Pero eso está comenzando a moverse en el reino de la exageración. A menos que seas Facebook, ese tipo de cosas probablemente sea innecesario.

Editar

Si permite a los usuarios cargar scripts y ejecutables, debe asegurarse de que nada subido a través de esa forma no se sirve de vuelta como otra cosa que application/octet-stream. No intente mezclar el Content-Type cuando se trate de cargas potencialmente peligrosas. Si le va a decir a los usuarios que tienen que preocuparse por su propia seguridad (eso es lo que hace cuando acepta scripts o ejecutables), todo debe ser servido como application/octet-stream para que el navegador no intente renderizarlo. Probablemente también deba establecer el encabezado Content-Disposition. Probablemente también sea prudente involucrar un escáner de virus en la tubería si quieres tratar con ejecutables. ClamAV es scriptable y de código abierto, por ejemplo.

Answer 3

Con más contexto, sería más fácil saber dónde se encuentran las vulberabilities.

Si los datos pueden almacenarse en una base de datos (parece que no lo será), entonces debe protegerse contra los ataques SQL Injection.

Si los datos pueden mostrarse en un navegador (parece que sería), entonces es posible que deba protegerse contra los ataques HTML/CSS Injection.

Si usa lenguajes de scripting (por ejemplo, PHP) en el servidor, es posible que deba protegerse contra los ataques de inyección contra esos idiomas específicos. Con el código de servidor compilado (o una implementación de scripting pobre), existe la posibilidad de ataques de desbordamiento de búfer.

No pase por alto la seguridad de los datos del usuario: ¿Pueden sus usuarios confiar en usted para evitar que sus datos se vean comprometidos?

EDITAR: Si realmente desea cubrir todas las bases, considerar los riesgos de JPEG y WMF agujeros de seguridad. Estos podrían explotarse si un usuario malintencionado puede cargar los archivos de un sistema y luego ver los archivos, o persuadir a otro usuario para que los vea, desde otro sistema.

Answer 4

validación tamaño sería útil también, no querría que alguien intencionalmente para cargar una imagen falsa de 100 GB simplemente por despecho ahora le :)

Además, es posible que desee considerar algo para evitar que la gente el uso de la ancho de banda solo para una manera fácil de alojar imágenes (me preocuparía principalmente el alojamiento de material ilegal). La mayoría de las personas usaría imageshack para el alojamiento de imágenes temporales de todos modos.

Answer 5

tamaño del contenido La restricción de ciertos tipos de archivos (.jpeg, .png etc., los tipos de archivo de la lista blanca sólo debe ser permitido) archivo de manipulación (por ejemplo: un sitio de soporte idiomas extranjeros, se permite cierta codificación.el hacker puede tomar ventaja de esto y añade cualquier script/código malicioso codifica y se anexa al archivo original y trata de cargar)

Answer 6

Para la lectura adicional, hay un gran artículo de Acunetix en Why File Upload Forms are a Major Security Threat