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

Advertencia. Los pasos que describe no son suficientes para estar seguros, si esos archivos están disponibles desde sus servidores.

Explicación. Debido a que los navegadores detectan el contenido en una variedad de circunstancias para adivinar el tipo MIME apropiado, hay una variedad de ataques sutiles de secuencias de comandos entre sitios que siguen siendo posibles. La categoría general a veces se conoce como contenido-sniffing XSS .

Vea el siguiente trabajo de investigación:

• Adam Barth, Juan Caballero y Dawn Song. Detección segura de contenido para navegadores web o Cómo evitar que los documentos se revisen a sí mismos . Seguridad IEEE & Privacidad 2009.

Las siguientes publicaciones y mensajes de blog también analizan esta amenaza:

• Andreas Gohr, Chris Smith. MSIE facilita las secuencias de comandos entre sitios . Febrero de 2007.

• Jessica Hope, rotwang. Vulnerabilidad XSS de carga de SMF . Diciembre de 2006.

• Robert McMillan. Una foto que puede robar su cuenta de Facebook . Julio de 2008.

Defensas. Le recomiendo que adopte las siguientes defensas y mitigaciones:

1. Aloje el contenido en un dominio separado, que se usa solo para alojar contenido subido por el usuario. Esto lo protegerá, por lo que los ataques XSS de rastreo de contenido solo pueden atacar el contenido de otros usuarios y no pueden atacar su sitio. (Por ejemplo, Wikipedia y Facebook usan esta defensa).

2. Asegúrese de establecer un encabezado Content-Type: correcto en cada respuesta que sirva contenido subido por el usuario. Verifique el tipo de contenido para asegurarse de que sea una de las varias opciones en una lista blanca de tipos de contenido seguro. Evite enviar un tipo MIME no válido (por ejemplo, */* , unknown/unknown , application/unknown ) y evite las respuestas que carezcan de un encabezado Content-Type: ; están sujetos al rastreo del tipo de contenido del navegador y, por lo tanto, están en alto riesgo de ataque. Evite los tipos MIME que causan que IE7 haga un rastreo de tipo de contenido (consulte el artículo de Barth y otros para obtener una lista, en la Tabla 4).

3. Cuando sirva contenido proporcionado por el usuario, nunca sirva uno con un tipo MIME inseguro que pueda desencadenar la ejecución del código activo. Por ejemplo, evite todo lo siguiente: text/html , application/x-shockwave-flash , ya que pueden contener código privilegiado. Desafortunadamente, no creo que sea seguro servir contenido Flash suministrado por el usuario desde su sitio.

4. Cuando sirva contenido proporcionado por el usuario, incluya un encabezado X-Content-Type-Options: nosniff junto con el encabezado Content-Type: , para deshabilitar el rastreo del tipo de contenido en algunas versiones de IE.

5. Para el contenido que no espera que se pueda mostrar en el navegador, márquelo para que el navegador lo maneje como una descarga de archivos: por ejemplo, agregue un encabezado Content-Disposition: attachment .

(Si esto suena molesto, seguro que tienes razón. Culpa a la gente de Apache por incluir una configuración por defecto que rompió los estándares web, durante muchos años, e ignoró las súplicas de hacer algo al respecto. Desafortunadamente, ahora es demasiado tarde: estamos atrapados con una gran base de navegadores desplegados que hacen cosas peligrosas.)

Probablemente no sea seguro. Hay varios ataques que engañan al sniffer del tipo de contenido para creer que un archivo es el tipo de contenido incorrecto. Aquí hay un ejemplo particularmente infame:

enlace

La sugerencia del póster anterior es buena para proteger su servidor de scripts maliciosos: mueva los archivos cargados fuera de la raíz web y escriba un script para enviarlos al usuario. Desea evitar que su servidor web o su tiempo de ejecución ejecuten los archivos cargados de un usuario. No especificó un idioma, pero hay un ejemplo de PHP aquí:

enlace

Otro aspecto que se pasa por alto en "seguridad de archivos" es mantener los archivos seguros para sus usuarios. Si está permitiendo que los usuarios descarguen archivos que han sido cargados por otros usuarios, entonces los usuarios malintencionados pueden usar su sitio para propagar malware. En este caso, es probable que desee poner en cuarentena los archivos cargados hasta que pueda escanearlos con AV.

Creo que eso es adecuado. Sin embargo, todavía nunca coloco los archivos cargados en un directorio al que se puede acceder directamente a través del servidor web: los usuarios acceden a los archivos a través de un script de descarga. De esta manera, incluso si alguien logra cargar algo ejecutable, no se ejecutará.

Por cierto, tenga mucho cuidado al llamar "archivo", si el nombre de archivo que proporcionó el usuario es un argumento, asegúrese de evitarlo correctamente antes de usarlo en system ().