14. Subida de archivos, deserialización insegura y ejecución remota

14.1 Introducción

Muchas aplicaciones modernas permiten subir archivos, importar documentos, restaurar configuraciones, cargar imágenes, procesar adjuntos, aceptar plantillas o intercambiar objetos complejos entre componentes. Estas funcionalidades son normales y a menudo necesarias, pero aumentan mucho la superficie de ataque porque obligan al servidor a tratar con contenido que no es simple texto.

El riesgo no está solo en almacenar ese contenido, sino en procesarlo, interpretarlo, moverlo entre servicios o dejarlo accesible desde ubicaciones críticas. Si el sistema asume que el archivo o el objeto recibido es benigno, puede terminar ejecutando lógica inesperada, exponiendo datos o incluso habilitando control del servidor.

En este tema veremos tres áreas muy relacionadas: subida de archivos insegura, deserialización insegura aplicada en escenarios concretos y ejecución remota como consecuencia posible de un procesamiento mal diseñado.

14.2 Por qué la subida de archivos es tan riesgosa

Un archivo no es solo un bloque de bytes. Puede contener formatos complejos, metadatos, contenido ejecutable, estructuras especialmente diseñadas para explotar parsers o material que, al ser almacenado o publicado de cierta forma, cambia por completo su impacto.

La aplicación que permite uploads debe responder varias preguntas difíciles:

• ¿Qué tipos de archivo son realmente necesarios?
• ¿Cómo verificar su tipo real?
• ¿Dónde se almacenarán y con qué permisos?
• ¿Se procesarán, convertirán o visualizarán?
• ¿Pueden quedar accesibles desde la web?
• ¿Pueden sobrescribir o afectar otros recursos?

14.3 Riesgos típicos en subida de archivos

• Subir contenido ejecutable en lugar de un simple documento.
• Bypassear validaciones basadas solo en extensión o nombre.
• Publicar archivos subidos en rutas servidas directamente por el servidor web.
• Procesar formatos peligrosos con librerías vulnerables.
• Provocar sobrecarga, consumo de disco o descompresión maliciosa.
• Usar el upload como vía de persistencia o pivoting.

14.4 Validar extensión no es suficiente

Uno de los errores más comunes consiste en controlar solo la extensión del archivo o el tipo declarado por el cliente. Eso es insuficiente porque el atacante puede renombrar el archivo, manipular metadatos o construir formatos ambiguos que pasen filtros superficiales.

Una validación robusta debe considerar:

• Tipo permitido según necesidad real del negocio.
• Contenido o firma del archivo cuando corresponda.
• Tamaño máximo razonable.
• Ubicación y permisos de almacenamiento.
• Procesamiento posterior que se le aplicará.

14.5 Almacenamiento inseguro de archivos

Aun si el archivo fue aceptado legítimamente, la forma en que se almacena puede volverlo peligroso. Si se guarda en una ruta accesible por el servidor web con interpretación activa, o si se mezcla con contenido operativo del sistema, el riesgo se amplifica.

Problemas frecuentes:

• Archivos subidos dentro del mismo árbol público sin aislamiento.
• Permisos excesivos de lectura o ejecución.
• Nombres de archivo controlables que permiten colisiones o sobreescritura.
• Ausencia de renombrado seguro y control del path final.

14.6 Procesamiento de archivos y parsers complejos

Muchas aplicaciones no solo almacenan archivos: los procesan. Generan miniaturas, extraen texto, convierten formatos, escanean contenido, analizan metadatos o invocan utilidades externas. Cada una de esas etapas introduce nuevas superficies de riesgo.

El atacante puede aprovechar:

• Parsers vulnerables.
• Conversores externos inseguros.
• Procesamiento con privilegios excesivos.
• Archivos especialmente construidos para romper herramientas de análisis.

14.7 Deserialización insegura en la práctica

Ya vimos el concepto general de deserialización insegura en el tema 10. Aquí nos interesa observar su dimensión práctica: muchas aplicaciones aceptan o intercambian objetos serializados a través de cookies, sesiones persistidas, cachés, colas, importaciones o integraciones. Si un atacante puede controlar esos datos y la aplicación los reconstruye sin suficiente validación, el sistema puede entrar en estados no previstos o ejecutar lógica peligrosa.

La deserialización es especialmente delicada porque no solo transporta datos, sino estructuras con semántica interna y potencial interacción con clases o componentes existentes.

14.8 Qué puede causar una deserialización insegura

• Alteración del estado esperado de la aplicación.
• Manipulación de objetos internos o de su comportamiento.
• Ejecución de cadenas complejas a través de librerías disponibles.
• Persistencia de datos maliciosos en componentes de infraestructura.
• En ciertos contextos, ejecución remota de código.

Esto explica por qué la deserialización insegura suele considerarse de alto riesgo incluso cuando el punto de entrada parece discreto.

14.9 Qué entendemos por ejecución remota

Hablamos de ejecución remota cuando el atacante logra que el servidor ejecute instrucciones, código o comportamientos arbitrarios o no previstos a partir de una entrada controlada. No siempre se llega allí por una única vulnerabilidad; a veces es el resultado de encadenar varias debilidades.

La ejecución remota puede originarse, por ejemplo, a partir de:

• Command Injection.
• Procesamiento inseguro de archivos.
• Deserialización peligrosa.
• Frameworks o componentes vulnerables.
• Uploads que terminan siendo interpretados como contenido activo.

14.10 Por qué RCE es tan crítica

La ejecución remota suele ser una de las consecuencias más severas en seguridad web porque permite pasar del plano lógico de la aplicación al control técnico del entorno donde corre.

Su impacto puede incluir:

• Lectura y modificación de archivos del servidor.
• Acceso a secretos, configuraciones y credenciales locales.
• Pivoting hacia otros servicios internos.
• Persistencia y control del proceso o del host.
• Exfiltración de datos o sabotaje operativo.

14.11 Cómo un upload puede terminar en ejecución

Un archivo subido por el usuario puede transformarse en ejecución o compromiso si la arquitectura le permite al servidor interpretarlo de forma activa o lo entrega a componentes inseguros.

Escenarios conceptuales:

• El archivo se publica en una ruta donde puede ser ejecutado o interpretado.
• El sistema usa herramientas del sistema para procesarlo sin aislamiento.
• El parser que lo consume tiene una vulnerabilidad explotable.
• El archivo se reutiliza luego como plantilla, script o configuración.

14.12 Zip bombs, archivos gigantes y abuso de recursos

No todos los ataques sobre uploads buscan ejecución. A veces el objetivo es afectar disponibilidad o recursos. Archivos comprimidos maliciosos, estructuras especialmente diseñadas o cargas masivas pueden consumir CPU, memoria, almacenamiento o tiempo de procesamiento.

Esto convierte la carga de archivos también en una superficie relevante para denegación de servicio y abuso operativo.

14.13 Nombres de archivo, paths y sobrescritura

Un archivo no solo tiene contenido; también tiene nombre, ruta lógica, metadatos y contexto de almacenamiento. Si la aplicación permite manipular demasiado esos aspectos, el atacante puede intentar:

• Sobrescribir recursos existentes.
• Escapar directorios esperados.
• Colisionar con archivos legítimos.
• Forzar extensiones o ubicaciones problemáticas.

La gestión segura del nombre y del destino final del archivo es tan importante como la validación del contenido.

14.14 Señales que justifican revisión profunda

• La aplicación permite subir archivos de muchos tipos sin justificación clara.
• Las validaciones dependen solo del nombre o del MIME declarado.
• Los archivos quedan accesibles directamente desde rutas públicas.
• Se invocan herramientas externas o parsers complejos durante el procesamiento.
• Se intercambian objetos serializados en cookies, cachés o integraciones sin validación fuerte.
• No existe aislamiento entre contenido subido y entorno operativo.

14.15 Buenas prácticas para uploads seguros

La defensa frente a subida de archivos insegura exige varias capas combinadas.

• Permitir solo tipos estrictamente necesarios para el negocio.
• Validar contenido y formato de manera coherente con el caso de uso.
• Renombrar archivos de forma segura y controlar ubicación final.
• Almacenarlos fuera del árbol público o con política de publicación controlada.
• Aislar el procesamiento cuando implique herramientas complejas.
• Limitar tamaño, cantidad y frecuencia de carga.

14.16 Buenas prácticas frente a deserialización insegura

La prevención pasa por reducir al mínimo la necesidad de reconstruir objetos complejos provenientes de fuentes no confiables.

• Evitar deserializar datos no confiables cuando exista otra alternativa.
• Validar estructura, tipo y contexto antes de reconstruir objetos.
• No confiar en cookies, sesiones o blobs complejos solo porque vienen de un canal habitual.
• Usar formatos y diseños que minimicen comportamiento implícito.
• Limitar el alcance del proceso que manipula estos datos.

14.17 Buenas prácticas para reducir impacto de RCE

Aunque el objetivo principal es evitar llegar a ejecución remota, también conviene diseñar el entorno para contener impacto si algo falla.

• Ejecutar procesos con mínimo privilegio.
• Separar componentes de procesamiento de archivos del núcleo del negocio.
• Aislar contenedores o servicios con funciones de alto riesgo.
• Limitar acceso a secretos, red interna y recursos sensibles.
• Monitorear actividad anómala asociada a archivos y parsing.

14.18 Errores frecuentes en la remediación

• Bloquear solo ciertas extensiones peligrosas y considerar resuelto el problema.
• Confiar en el tipo MIME declarado por el cliente.
• Corregir almacenamiento pero no revisar procesamiento posterior.
• Reducir riesgo en un endpoint y olvidar otros uploads equivalentes.
• No revisar qué ocurre con backups, miniaturas, conversiones o cacheo del archivo.
• Tratar deserialización insegura como un problema exclusivamente teórico.

14.19 Relación con otras vulnerabilidades

Estas áreas se conectan con varias categorías previas del curso.

• Con Injection, si el procesamiento del archivo termina invocando comandos o parsers inseguros.
• Con Software and Data Integrity Failures, si se reconstruyen objetos o artefactos sin confianza suficiente.
• Con Vulnerable Components, si librerías de parsing o transformación tienen fallas conocidas.
• Con Security Misconfiguration, si el entorno permite ejecución o publicación insegura de archivos subidos.

Esto muestra que un upload inseguro rara vez es un problema aislado; suele ser una puerta de entrada hacia debilidades más profundas.

14.20 Qué debes recordar de este tema

• Un archivo subido no es solo contenido: puede activar parsers, conversiones y flujos de alto riesgo.
• Validar extensión o MIME no alcanza para considerar seguro un upload.
• La ubicación y forma de almacenamiento del archivo es parte crítica de la defensa.
• La deserialización insegura permite reconstruir estructuras complejas desde datos no confiables.
• La ejecución remota suele ser una consecuencia severa de múltiples debilidades combinadas.
• La defensa debe incluir aislamiento, mínimo privilegio y control estricto del procesamiento.
• Hay que revisar el ciclo completo: recepción, análisis, almacenamiento, uso y publicación.

14.21 Conclusión

La subida de archivos, la deserialización y la ejecución remota muestran una verdad incómoda de la seguridad web: mientras más compleja es la entrada aceptada por la aplicación, mayor es la probabilidad de que el sistema termine haciendo algo que nunca quiso hacer. El riesgo no está solo en recibir datos, sino en cómo esos datos son interpretados, transformados y conectados con el entorno técnico.

En el próximo tema estudiaremos APIs inseguras, validación de entradas y exposición de datos, donde veremos cómo el diseño de endpoints y respuestas puede ampliar o reducir drásticamente la superficie de ataque moderna.