¿Está bien que los navegadores (iOS) interpreten application / octet-stream como HTML + JS?

Navega tus respuestas
2

Esto se refiere a la prueba application/octet-stream aquí:
enlace

Las versiones de escritorio de Chrome, Firefox y Safari descargarán el archivo. Lo mismo para Chrome y Firefox en Android. Pero en iOS, los tres navegadores ejecutan / interpretan el archivo como si fuera HTML, incluido el Javascript que contiene.

Mi pregunta: ¿está bien?

Sé que las descargas deben usar Content-Disposition: attachment , y esta SO respuesta habla de no depender de Content-Type . Pero ... esto todavía parece mal.

Hubo CVE para tratar text/plain como HTML ( CVE-2010- 1420 , CVE-2013-5151 ). ¿Cómo está realmente mal, pero application/octet-stream está bien?

    
pregunta adam-p 16.03.2017 - 17:30
fuente

1 respuesta

0
  

Mi pregunta: ¿está bien?

Ignorar el tipo de contenido dado y adivinar qué podría ser es una mala idea. Esto puede dar como resultado, por ejemplo, eludir filtros externos (como firewalls o proxies) que dependen del tipo de contenido para el tipo de análisis que realizan. Y no sería la primera vez que algunas partes del navegador usen el Content-Type original para tomar sus decisiones, mientras que otras partes usan el Content-Type adivinado, lo que podría resultar en eludir las restricciones y filtros internos del navegador (como el filtro de protección XSS o similar). ).

Aparte de eso, tal comportamiento inesperado diferente de otros navegadores (y del estándar) es una pesadilla para los desarrolladores y también puede causar problemas de seguridad. Solo imagine que el sitio ofrece una forma de cargar varios archivos que luego se ofrecen para descargar como aplicación / octet-stream, con la esperanza de que esto resulte en una descarga. En su lugar, el navegador de iOS podría interpretar el archivo como HTML + JS, que esencialmente resulta en un XSS almacenado.

Se recomienda forzar la desactivación de tales conjeturas configurando X-Content-Type-Options=nosniff" en el encabezado HTTP.

    
respondido por el Steffen Ullrich 16.03.2017 - 17:48
fuente

Lea otras preguntas en las etiquetas

Desafíos de las implementaciones modernas del análisis de "viaje en el tiempo" en la red ¿Por qué un hash de una sola dirección no es suficiente para asegurar una contraseña solo? [duplicar]