Una función de carga de archivos segura depende de varios controles aplicados conjuntamente, y la OWASP File Upload Cheat Sheet los enumera. Este artículo repasa esa lista, señala los puntos que es fácil pasar por alto y la convierte en pruebas que puede ejecutar contra cada endpoint de carga.
Frente a qué se defiende
La hoja de referencia agrupa las amenazas bajo el concepto de "archivos maliciosos". La primera es un ataque contra el software que gestiona el archivo. Un atacante entrega un archivo que explota una vulnerabilidad en el parser o en el módulo de procesamiento, y la hoja de referencia cita como ejemplos el exploit ImageTrick y XXE.
La segunda es el phishing. La hoja de referencia utiliza como ejemplo un formulario de empleo, lo que significa que la carga se convierte en un medio para poner un archivo hostil ante las personas que lo abren.
La tercera es la disponibilidad. Las ZIP bombs, las XML bombs (el ataque billion laughs) y, sencillamente, los archivos enormes pueden llenar el almacenamiento del servidor y dañar su disponibilidad.
Valide antes de aceptar
La hoja de referencia establece una secuencia: aplicar validación de entrada antes de validar la extensión. A continuación se trabaja a partir de una lista de permitidos (allowlist).
- Enumere las extensiones permitidas. Admita únicamente las seguras que requiera la función de negocio. Un formulario de foto de perfil no tiene motivo para aceptar nada más que unos pocos tipos de imagen.
- Valide el tipo de archivo. No confíe en el
Content-Typedeclarado, porque puede falsificarse. Valide el tipo de archivo y su firma antes de aceptar la carga. - Fije un límite de longitud del nombre de archivo y restrinja los caracteres permitidos si es posible.
- Fije un límite de tamaño de archivo.
Si un archivo no supera cualquiera de estas comprobaciones, rechácelo.
Cuide el nombre y la ubicación
La hoja de referencia indica que se cambie el nombre de archivo proporcionado por el usuario por uno generado por la aplicación. Hágalo en todas las cargas, sea cual sea el tipo de archivo.
El lugar donde se almacena el archivo importa tanto como el archivo en sí. Almacene las cargas en un servidor distinto si le es posible. Si no lo es, guárdelas fuera del webroot.
Cuando los archivos deban ser accesibles públicamente, utilice un handler dentro de la aplicación que asocie un identificador con un archivo (someid con file.ext) en lugar de exponer la ruta de almacenamiento.
Hay otros dos puntos de la lista que se olvidan con facilidad:
- Solo los usuarios autorizados deben poder cargar archivos.
- Proteja la carga frente a ataques CSRF.
Analice y procese lo que conserva
La validación comprueba que un archivo tiene el aspecto correcto. La hoja de referencia añade un paso más: pasar el archivo por un motor antivirus o un sandbox, si hay uno disponible, para validar que no contiene datos maliciosos.
Para los tipos de documento aplicables, como PDF y DOCX, considere CDR (Content Disarm & Reconstruct) como un paso de procesamiento adicional.
La hoja de referencia señala también que todas las bibliotecas utilizadas deben estar configuradas de forma segura y mantenerse actualizadas. Dado que las vulnerabilidades de los parsers son una de las amenazas citadas, este es el punto que conviene asignar a una persona concreta con una fecha de revisión.
Pruebe cada endpoint
La hoja de referencia enumera controles, no casos de prueba. Cada fila de la tabla siguiente es una derivación propia a partir de su lista de comprobación, y la tercera columna indica de qué punto procede. Ejecute las pruebas contra todos los endpoints de carga, incluidas las herramientas de administración y los añadidos para un único cliente.
| Prueba | Cómo es un resultado satisfactorio | Base |
|---|---|---|
| Cargar un archivo de script renombrado con una extensión permitida | Rechazado tras la validación del tipo de archivo | Derivada: validar el tipo de archivo |
Enviar un archivo no permitido con un Content-Type permitido | Rechazado igualmente | Derivada: no confiar en la cabecera Content-Type |
| Enviar un nombre de archivo muy largo | Rechazado, o sustituido por un nombre generado | Derivada: límite de longitud del nombre, nombres generados |
| Cargar un archivo que supera el límite de tamaño | Denegado | Derivada: límite de tamaño de archivo |
| Solicitar el archivo almacenado adivinando su ruta | No accesible salvo a través del handler | Derivada: ubicación de almacenamiento, handler de mapeo |
| Cargar sin sesión, o sin token CSRF | Denegado | Derivada: usuarios autorizados, protección CSRF |
| Cargar una ZIP bomb o una XML bomb en un entorno de pruebas | El servicio sigue disponible | Derivada: amenaza a la disponibilidad |
Como referencia más amplia, la OWASP Web Security Testing Guide se describe a sí misma como el recurso de pruebas de ciberseguridad por excelencia para desarrolladores de aplicaciones web y profesionales de la seguridad. El OWASP Application Security Verification Standard ofrece requisitos numerados con los que verificar. Si cita alguno en un ticket o informe, incluya la versión, por ejemplo v5.0.0-1.2.5, porque los identificadores pueden cambiar entre versiones del estándar.
Por dónde empezar
- Haga una lista de todos los endpoints que aceptan un archivo, incluidas las herramientas de administración, las funciones de importación y los plugins antiguos.
- Para cada uno, defina las extensiones permitidas, el tamaño máximo de archivo y la longitud máxima del nombre, y aplique la validación de entrada antes de la comprobación de la extensión.
- Sustituya los nombres de archivo proporcionados por el usuario por nombres generados. Traslade el almacenamiento a un servidor distinto o fuera del webroot, y sirva los archivos públicos mediante un handler que asocie ID con nombres de archivo.
- Añada validación del tipo y la firma del archivo, un paso de antivirus o sandbox y CDR para los tipos de documento que acepte. Compruebe que las bibliotecas de parsing están actualizadas y configuradas de forma segura.
- Convierta la tabla de pruebas en comprobaciones automatizadas y ejecútelas antes de cada versión. Si desea una revisión externa del resultado, nuestro servicio de pruebas de penetración puede probar los endpoints, y nuestro apoyo al desarrollo de software seguro puede ayudarle si la función aún está en fase de diseño. La guía de OWASP sobre carga de archivos sirve como lista de comprobación para la revisión en cualquiera de los dos casos.
