Detección de contenido. Su propuesta no es suficiente: será vulnerable a los ataques de detección de contenido. He escrito en otra parte sobre estrategias para prevenir los ataques de rastreo de contenido . Hay una variedad de defensas. Aquí están los principales:
-
Incluya un encabezado Content-Type: en la respuesta. Asegúrese de que incluya un tipo MIME válido (evite los tipos MIME no válidos).
-
Incluya un encabezado X-Content-Type-Options: nosniff en la respuesta. Esto desactivará los algoritmos de rastreo de contenido de IE, en versiones recientes de IE.
-
Si no pretende que el contenido se vea en el navegador, puede ayudar a configurar Content-Disposition: attachment , para que el navegador lo trate como una descarga de archivos.
Incluso estos pasos no están garantizados para ser suficiente. Por ejemplo, si el usuario utiliza IE6, seguirá siendo vulnerable.
(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.)
Dominio separado. Una mejor defensa es alojar el contenido proporcionado por el usuario en un dominio separado, que se usa solo para el contenido subido por el usuario. De esa manera, un ataque exitoso de rastreo de contenido no puede atacar el contenido de su sitio. La carga de un usuario todavía puede atacar las cargas de otros usuarios, pero eso puede ser tolerable.
Verifique su lista blanca. Parece que asume que los archivos PDF y Word son inofensivos. Sin embargo, esos son dos formatos de archivo potentes y peligrosos. PDF es conocido por ser un vector. Los archivos PDF maliciosos abundan y pueden penetrar con éxito en muchos visores de PDF más antiguos. El riesgo de PDF es tan alto que Chrome toma precauciones especiales antes de permitirle descargar y ver un documento PDF en su visor de PDF. Word también es un formato de archivo poderoso y peligroso, que puede ser un host de ataques. Por esta razón, no consideraría que Word o PDF sean inofensivos.
Es posible que pueda redirigir a los usuarios a Google Docs, para ver el archivo Word / PDF en su navegador a través de Google Docs. Google convertirá el archivo Word / PDF a HTML y luego lo enviará al navegador del usuario. Esto puede o no ser aceptable en sus circunstancias.
Escanear archivos cargados en busca de virus. Le recomiendo que analice todo el contenido subido por usuarios en busca de virus, usando un escáner de virus o malware. Para archivos PDF, consulte también ¿Cómo escanear un PDF en busca de malware? . Es posible que desee escanear la carga inmediatamente cuando se carga. También puede considerar volver a escanear periódicamente los archivos antiguos (esto puede detectar un malware que no se detectó anteriormente, ya que las definiciones de antivirus / malware se actualizan).
Más información. Consulte también Lista de verificación de Mozilla para cargar archivos , en su seguro Codificación estándar. Es una lista bastante buena de buenas prácticas de seguridad.
Resumen. En resumen, la defensa más poderosa y efectiva que puede usar es colocar el contenido subido por el usuario en un dominio separado. Luego, como protección adicional, es posible que desee considerar las otras defensas enumeradas aquí.
Actualización: acabo de enterarme de un problema más con tu esquema. 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, estúpido Flash.) Desafortunadamente, ninguna cantidad de listas blancas puede detener este ataque. En consecuencia, parece que la única solución segura es alojar el contenido subido por el usuario en un dominio separado.