2010-10-13 8 views
5

Tenemos una aplicación web interna que actúa como un repositorio en el que los usuarios pueden cargar archivos. Estos archivos pueden tener cualquier formato, incluidas las páginas HTML.¿Cómo se puede evitar XSS en las descargas de HTML?

Hemos probado que en IE8, si descarga un archivo HTML que contiene algún script que intenta acceder a sus cookies y, después de la descarga, elige la opción "Abrir", el script ejecuta y obtiene su información de cookies sin problemas en absoluto.

En realidad, esa secuencia de comandos podría usar el objeto XmlHttpRequest para llamar al servidor y realizar algunas operaciones maliciosas dentro de la sesión del usuario que descargó el archivo.

¿Hay alguna manera de evitar esto? Hemos probado que tanto Chrome como Firefox no permiten que esto suceda. ¿Cómo se puede evitar este comportamiento en cualquier navegador, incluido IE8?

+2

¿Qué significa "Abrir" en realidad? Mostrar la página en el navegador? Si es así, ¿cuál es la URL de la página cuando eso sucede? – bzlm

+0

@bzlm: Es como con cualquier archivo adjunto; si fuerza al navegador a solicitar la ventana de descarga (disposición del contenido), puede hacer clic en abrir, y se abre usando la url usada para cargarlo, que obviamente está en el mismo dominio que sus cookies, de ahí mi sugerencia de ejecutando (las descargas) en un dominio alternativo. –

+0

@bzlm está en el camino correcto: si abre un archivo HTML localmente, no podrá acceder a las cookies ni emitir solicitudes Ajax a un servidor remoto debido a la política de dominio único. Solo si se abre directamente en el servidor es posible. –

Respuesta

5

No permita la carga de contenido arbritary. Es exclusivamente una idea terrible.

Una posible "solución" podría ser alojar únicamente las cargas no confiables en un dominio que no tiene cookies y que el usuario no asocia ninguna confianza de ninguna manera. Esta sería una "solución", pero ciertamente no la ideal.

Algunas opciones más prácticas podrían ser un proceso basado en autorización, donde cada archivo pasa por una revisión automática y luego una confirmación manual de la fase de limpieza/análisis automático.

En general, es una muy mala idea permitir que el público en general haga esto.

+1

+1 para almacenar las cargas en un dominio diferente y la noción general de que esto es siempre peligroso –

+0

Consideraremos la opción de descargar archivos de un dominio diferente, y vigilaremos el sistema para ver si finalmente somos obligado a rechazar cualquier carga peligrosa. Muchas gracias por su ayuda. –

+0

[Lanzamientos de GitHub] (https://github.com/cirosantilli/test/releases/tag/3.0) permiten cualquier extensión y parecen usar la solución de dominio a través de S3. Dropbox también permite tipos de archivos arbitrarios. –

1

Si realmente necesita que los usuarios carguen archivos HTML, debe asegurarse de que los archivos HTML en este directorio se publiquen con texto tipo mime/plain en lugar de text/html o similar.

Esto evitará que los archivos abiertos ejecuten scripts en el navegador. Si está utilizando apache, consulte la directiva AddType.

+0

Esta es una buena sugerencia, y puede hacer el truco. Todavía me preocuparía publicar el contenido del mismo dominio, pero creo que esto debería hacerse independientemente. –

+0

Tenga cuidado con el rastreo de contenido. Debido a que Apache se envía con 'text/plain' de forma predeterminada para archivos desconocidos, los navegadores se ven obligados a tratar' text/plain' como una invitación a adivinar el tipo real. – Kornel

4

Esa es una muy mala idea desde el punto de vista de la seguridad. Aún así, si desea hacerlo, incluya el encabezado de respuesta HTTP Content-disposition: attachment Forzará que el navegador descargue el archivo en lugar de abrirlo. En Apache, se hace agregando Header set Content-disposition "attachment" al archivo .htaccess.

Tenga en cuenta que es una mala idea simplemente agregar Content-type: text/plain como se menciona en una de las respuestas, porque no funcionará para Internet Explorer. Cuando IE recibe un archivo con encabezado de texto/tipo de contenido simple, enciende su sniffer MIME que intenta definir el tipo de contenido real del archivo (porque algunos servidores envían todos los archivos con texto/sin formato). En caso de que se encuentre con el código HTML dentro de un archivo, forzará al navegador a servir el archivo como texto/html y lo renderizará.

+0

[Esta publicación del blog] (http://i8jesus.com/?p=64) dice que solo 'Content-Disposition' no es suficiente, pero no sé lo suficiente como para decir qué tan confiable es y si aún se aplica. –

Cuestiones relacionadas