security - telefono - ¿Qué problemas de seguridad aparecen cuando los usuarios pueden cargar sus propios archivos?
security sat (6)
Me preguntaba qué problemas de seguridad aparecen cuando el usuario final de un sitio web puede subir archivos al servidor.
Por ejemplo, si mi sitio web permite a los usuarios subir una imagen de perfil, y un usuario carga algo dañino en su lugar, ¿qué podría pasar? ¿Qué tipo de seguridad debo configurar para prevenir ataques como este? Estoy hablando de imágenes, pero ¿qué pasa con el caso en que un usuario puede subir algo a un tipo de aplicación de archivo-bóveda?
Es más una pregunta general que una pregunta sobre una situación específica, entonces, ¿cuáles son las mejores prácticas en esa situación? ¿Qué haces usualmente?
Supongo: escriba la validación en la carga, diferentes permisos para los archivos cargados ... ¿qué más?
EDITAR : Para aclarar el contexto, estoy pensando en una aplicación web donde un usuario puede cargar cualquier tipo de archivo y luego mostrarlo en el navegador. El archivo se almacenaría en el servidor. Los usuarios son quienes usan el sitio web, por lo que no hay confianza involucrada.
Estoy buscando respuestas generales que puedan aplicarse a diferentes lenguajes / marcos y entornos de producción.
Con más contexto, sería más fácil saber dónde se encuentran las vulberabilities.
Si los datos pueden almacenarse en una base de datos (parece que no lo será), entonces debe protegerse contra los ataques de inyección SQL .
Si los datos pueden mostrarse en un navegador (suena como debería ser), entonces es posible que deba protegerse contra los ataques de inyección de HTML / CSS .
Si está utilizando lenguajes de scripting (por ejemplo, PHP) en el servidor, entonces puede necesitar protegerse contra ataques de inyección contra esos idiomas específicos. Con el código de servidor compilado (o una implementación de scripting pobre), existe la posibilidad de ataques de desbordamiento de búfer.
No pase por alto la seguridad de los datos del usuario: ¿Pueden sus usuarios confiar en usted para evitar que sus datos se vean comprometidos?
EDITAR : si realmente quieres cubrir todas las bases, considera los riesgos de los agujeros de seguridad JPEG y WMF . Estos podrían explotarse si un usuario malintencionado puede cargar los archivos de un sistema y luego ver los archivos, o persuadir a otro usuario para que los vea, desde otro sistema.
Para más información, hay un gran artículo de Acunetix sobre por qué los formularios de carga de archivos son una amenaza importante para la seguridad
Su primera línea de defensa será limitar el tamaño de los archivos cargados, y eliminar cualquier transferencia que sea mayor que esa cantidad.
La validación de la extensión de archivo es probablemente una buena segunda línea de defensa. La validación de tipo se puede realizar más adelante ... siempre que no confíe en el tipo mime (proporcionado por el usuario) para dicha validación.
¿Por qué validar la extensión de archivo? Porque eso es lo que la mayoría de los servidores web usan para identificar qué archivos son ejecutables. Si sus ejecutables no están bloqueados en un directorio específico (y lo más probable es que no lo estén), los archivos con ciertas extensiones se ejecutarán en cualquier lugar bajo la raíz del documento.
La verificación de la extensión de archivos se realiza mejor con una lista blanca de los tipos de archivos que desea aceptar.
Una vez que valida la extensión del archivo, puede verificar que dicho archivo sea del tipo que dice su extensión, ya sea verificando los bytes mágicos o usando el comando de archivo de Unix.
Estoy seguro de que hay otras preocupaciones que eché de menos, pero espero que esto ayude.
Suponiendo que se trata únicamente de imágenes, una cosa que puede hacer es usar una biblioteca de imágenes para generar imágenes en miniatura / tamaños de imagen consistentes y tirar el original cuando haya terminado. Entonces efectivamente tiene un único punto de vulnerabilidad: su biblioteca de imágenes. Suponiendo que lo mantengas actualizado, deberías estar bien.
Los usuarios no podrán cargar archivos zip o realmente ningún archivo que no sea de imagen, ya que la biblioteca de imágenes se eliminará si intenta cambiar el tamaño de los datos que no son de imagen, y usted solo puede capturar la excepción. Sin embargo, es probable que desee hacer una comprobación preliminar de la extensión del nombre de archivo. No tiene sentido enviar un archivo a través de la biblioteca de imágenes si el nombre del archivo es "foo.zip".
En cuanto a los permisos, bueno ... no configure el bit de ejecución. Pero, de manera realista, los permisos no lo ayudarán a protegerse mucho contra la entrada de usuarios maliciosos.
Si su entorno de programación lo permite, querrá ejecutar algunas de estas comprobaciones mientras la carga está en progreso. Un cliente HTTP malicioso puede enviar potencialmente un archivo con un tamaño infinito. IE, simplemente nunca deja de transmitir bytes aleatorios, lo que resulta en un ataque de denegación de servicio. O tal vez solo carguen un video como su foto de perfil. La mayoría de los formatos de archivo de imagen también tienen un encabezado al principio. Si un cliente comienza a enviar un archivo que no coincide con ningún encabezado de imagen conocido, puede cancelar la transferencia. Pero eso está comenzando a moverse en el reino de la exageración. A menos que seas Facebook, ese tipo de cosas probablemente sea innecesario.
Editar
Si permite que los usuarios carguen secuencias de comandos y ejecutables, debe asegurarse de que todo lo cargado a través de ese formulario nunca se sirva como otra cosa que no sea application/octet-stream . No intente mezclar el tipo de Content-Type cuando se trate de cargas potencialmente peligrosas. Si va a decirles a los usuarios que tienen que preocuparse por su propia seguridad (eso es lo que hacen cuando aceptan scripts o ejecutables), todo debe ser servido como application/octet-stream para que el navegador no intente hazlo. También debería configurar el encabezado Content-Disposition . Probablemente también sea prudente involucrar un escáner de virus en la tubería si quieres tratar con ejecutables. ClamAV es programable y de código abierto, por ejemplo.
Tamaño del contenido Restricción de ciertos tipos de archivos (.jpeg, .png, etc., los tipos de archivos listados en blanco solo deben permitirse) alteración de archivos (por ejemplo: un sitio compatible con idiomas extranjeros, se permite cierta codificación. El hacker puede aprovechar esto y agrega cualquier script / código malicioso codificado y se agrega al archivo original e intenta cargarlo)
la validación del tamaño también sería útil, no querría que alguien cargue intencionalmente una imagen falsa de 100 gb por pura molestia, ahora lo haría :)
Además, es posible que desee considerar algo para evitar que las personas usen su ancho de banda solo por una manera fácil de alojar imágenes (en lo principal me preocuparía el alojamiento de material ilegal). La mayoría de las personas usaría imageshack para el alojamiento de imágenes temporales de todos modos.