Validar, almacenar y servir archivos subidos por usuarios

Objetivo

Permitir que los usuarios suban documentos o imágenes sin darles una manera de ejecutar código en el servidor, plantar scripts que se ejecuten en el navegador de otros usuarios, o llenar el disco.

Requisitos previos

Una lista de los tipos de archivo que la función realmente necesita; una ubicación de almacenamiento desde la que el servidor web no ejecute nada; un presupuesto de tamaño por archivo y por usuario.

Pasos

1. Exigir autenticación para las subidas y limitar su tasa por usuario.
2. Validar la extensión, tras decodificar el nombre de archivo, contra una lista blanca que contenga únicamente los tipos requeridos; la hoja de referencia de OWASP (citada) menciona las extensiones dobles (.jpg.php) y los bytes nulos (.php%00.jpg) como formas de eludir filtros ingenuos, y califica las listas negras de débiles por sí solas.
3. Comprobar el contenido: la hoja de referencia indica que no se puede confiar en el Content-Type que envía el cliente; verificar la firma del archivo (magic bytes) frente al tipo esperado y, para imágenes, recodificar mediante una biblioteca de imágenes para destruir cualquier carga útil incrustada. Rechazar los archivos comprimidos salvo que la función trate justamente de archivos comprimidos, y en ese caso extraer con comprobaciones de ruta y un límite de tamaño tras la descompresión.
4. Descartar el nombre de archivo del usuario para el almacenamiento; guardar bajo un identificador aleatorio (un UUID) y conservar el nombre original solo como metadato, con longitud limitada y caracteres restringidos, únicamente para mostrarlo.
5. Aplicar el límite de tamaño tanto en el servidor web como en la aplicación; contar el tamaño descomprimido donde se procesen archivos.
6. Almacenar fuera de la raíz web, o en un host separado, con permisos de sistema de archivos de mínimo privilegio y sin bit de ejecución; la hoja de referencia clasifica un host distinto como primera opción, y fuera de la raíz web como segunda.
7. Servir a través de un manejador de la aplicación que asocie el identificador al archivo, compruebe la autorización, fije el Content-Type a partir de su propio registro (nunca a partir del archivo), X-Content-Type-Options: nosniff, y Content-Disposition: attachment; filename="..." (MDN, citado), salvo que se requiera visualización en línea para un tipo conocido como inerte.
8. Cuando se necesite visualización en línea (imágenes, PDF), servir desde un origen separado con una Content Security Policy restrictiva, de modo que un archivo que resulte ser HTML o SVG con script no pueda actuar sobre las cookies del origen principal.
9. Analizar con un antivirus o un servicio de reputación por hash si los archivos se redistribuyen, y ofrecer a los usuarios una forma de reportar contenido.

Resultado esperado

Un archivo .php, .html o políglota subido se almacena como un blob opaco bajo un nombre aleatorio, nunca se ejecuta, y se entrega como descarga o desde un origen aislado.

Límites y base de verificación

Sigue las fuentes citadas; no se afirma ninguna medición. Las comprobaciones de firma son eludibles por sí solas y constituyen una capa entre varias. SVG y PDF pueden portar script y necesitan el tratamiento de origen separado o la conversión. Guardar los archivos en la base de datos es posible, pero traslada allí el problema de carga y de copias de seguridad.

El nombre de archivo de descarga proviene del tipo validado

El nombre de archivo original es un metadato, y su extensión no debe llegar sin cambios al encabezado Content-Disposition: la extensión de ese encabezado decide qué hace el sistema operativo del destinatario con el archivo, y un nombre como report.pdf.exe o invoice.html almacenado en el momento de la subida se ejecuta o se renderiza localmente tras la descarga, donde nosniff ya no se aplica. Construir el nombre servido a partir del propio registro: conservar el nombre base del usuario solo si pasa una lista blanca de caracteres y un límite de longitud, añadir la extensión canónica del tipo validado, y codificar el encabezado según RFC 6266 (filename*=UTF-8''... para caracteres no ASCII, con comillas y caracteres de control eliminados). Probar con una subida cuyo nombre original lleve una extensión doble y confirmar que la descarga llega bajo el nombre elegido.