¿X-Content-Type-Type realmente evita los ataques de sniffing de contenido?

Fondo. X-Content-Type-Options: es un encabezado diseñado para defiende contra ataques MIME de detección de contenido . Los ataques de rastreo de contenido MIME son un riesgo cuando permite que los usuarios carguen contenido (por ejemplo, imágenes, documentos, otros archivos) a su sitio web, donde otros usuarios pueden descargarlos.

Como dice @Rook, esto no tiene nada que ver con las escuchas / capturas de la red.

¿Qué ataques no previene? Como X-Content-Type-Options: solo es compatible con algunos navegadores, no protege los ataques contra usuarios que usan otros navegadores. En particular, se supone en IE, Chrome y Firefox 50 . Consulte también ¿Cuáles son los riesgos de seguridad de permitir que los usuarios carguen contenido en mi sitio? para otros ataques que no hace ' t evitar, por ejemplo, cargar malware o contenido desagradable, cargar contenido que explote una vulnerabilidad en el navegador del usuario, etc.

¿Qué tipo de contenido debe devolverse? Debe devolver el tipo de contenido apropiado para ese archivo. No debe permitir que los usuarios carguen contenido que no sea de confianza con tipos de contenido peligrosos. Para obtener más detalles, consulte las respuestas a las siguientes preguntas:

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

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

3. Protección de inhalación MIME

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

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

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

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

Este tema ha sido ampliamente discutido y documentado en otras partes de este sitio, por lo que no intentaré repetir todos los consejos útiles que se encuentran allí.

Actualización: acabo de enterarme de que la configuración de los encabezados Content-Type y X-Content-Type-Options no es suficiente para la seguridad. Al parecer, Flash ignora el encabezado Content-Type , que podría permitir la carga de un archivo SWF malicioso, que puede hacer todo lo que pueda Lo harías con un XSS. (Suspiro, Flash estúpido). Desafortunadamente, no hay una cantidad de tipos de contenido de archivo en la lista blanca que pueda detener este ataque. En consecuencia, parece que la única solución segura es alojar el contenido subido por el usuario en un dominio separado.

Aquí hay una respuesta de Michal Zalewski recibida por correo electrónico:

  

La respuesta corta es que funciona en MSIE, y solo en algunos   casos. No te protegerá contra (mucho menos celoso) el olfateo   la mayoría de los otros navegadores; pero lo más importante, no desalentará los complementos   de hacer cosas como el riesgo crossdomain.xml descrito anteriormente; y   no necesariamente evitará las cargas de sub-recursos con tipos MIME no coincidentes   (es decir, cargando una imagen como aplicación / x-shockwave-flash a través de < embed >).

  

¿Qué ataques de rastreo X-Content-Type-Options: nosniff no impide?

Exploración por herramientas que no conocen X-Content-Type-Options : algunos navegadores y complementos que pueden obtener recursos de la red. (Por ejemplo, históricamente Java GIFAR, Flash loadPolicyFile ...)

  

¿Qué tipo de contenido debe devolverse al usuario en lugar de text / plain?

No hay una buena respuesta a eso, por lo que si necesita alojar archivos de texto que no sean de confianza, debería tomar la mitigación habitual de alojarlos en un nombre de host separado (y, idealmente, en una dirección IP).

Alternativa: codifique en HTML, agregue <pre> y sirva como text/html .