Tema 13
No todos los riesgos web aparecen por inyecciones o sesiones. Algunas vulnerabilidades surgen cuando la aplicación acepta archivos complejos, reconstruye objetos desde datos externos o permite abusar de procesos de negocio que, técnicamente, parecen válidos. Estas fallas suelen ser menos evidentes y, por eso mismo, muy peligrosas.
Hay vulnerabilidades que no se explican del todo con categorías clásicas como SQL Injection o XSS. Algunas aparecen cuando la aplicación confía en estructuras complejas que recibe del usuario, cuando acepta archivos sin procesarlos de forma segura o cuando permite ejecutar un flujo de negocio sin considerar cómo podría abusarse.
Estas áreas son especialmente delicadas porque muchas veces la aplicación “hace lo que se le pidió”, pero el problema es precisamente que esa petición nunca debería haber sido aceptada en ese contexto.
En este tema veremos tres bloques relacionados: subida de archivos, deserialización y lógica de negocio.
Permitir que los usuarios suban archivos parece una función simple y útil: comprobantes, imágenes, documentos, planillas, PDFs, currículums, reportes o anexos. Pero un archivo no es solo un contenido inofensivo. Puede ser enorme, malformado, ejecutable, ambiguo o diseñado específicamente para activar fallas al ser procesado.
La subida de archivos es delicada porque introduce un objeto complejo controlado por el usuario dentro del sistema. Eso puede afectar almacenamiento, procesamiento, interpretación y exposición posterior del archivo.
Confiar solo en la extensión del archivo es insuficiente. Un atacante puede renombrar un archivo peligroso para que parezca una imagen, un PDF o un documento. También puede manipular el tipo de contenido reportado en la solicitud.
Por eso una validación razonable suele incluir varias capas:
No basta con aceptar o rechazar el archivo. También importa dónde y cómo se almacena. Un error frecuente es guardar archivos subidos en rutas directamente accesibles desde el servidor web, con su nombre original y sin control adicional.
Buenas prácticas comunes incluyen:
Muchas aplicaciones no solo guardan archivos; también los procesan: generan miniaturas, extraen texto, convierten formatos, leen metadatos o los analizan automáticamente. Cada una de esas operaciones introduce riesgo adicional si las herramientas o bibliotecas usadas no están bien elegidas o aisladas.
El archivo subido puede convertirse entonces en entrada para otros componentes internos, ampliando la superficie de ataque.
Un archivo puede contener más información de la que parece a simple vista: autor, ubicación, herramienta de edición, historial, comentarios o datos internos. Si la aplicación publica o reutiliza esos archivos sin tratamiento adecuado, puede exponer información innecesaria.
La seguridad de archivos no consiste solo en evitar ejecución de contenido peligroso, sino también en revisar qué información secundaria viaja con ellos.
Serializar es convertir una estructura de datos u objeto a un formato transportable o almacenable. Deserializar es reconstruirlo. Este proceso es útil y común en aplicaciones, APIs, colas, sesiones, cachés o integraciones.
El problema aparece cuando la aplicación deserializa datos provenientes de una fuente no confiable o insuficientemente validada. En ese caso, puede reconstruir estructuras peligrosas, inesperadas o manipuladas por el atacante.
La deserialización insegura es peligrosa porque transforma datos externos en estructuras internas con significado para la aplicación o para bibliotecas del entorno. Si esa reconstrucción activa lógica no prevista, el impacto puede incluir corrupción de estado, acceso indebido, abuso del flujo o incluso ejecución más grave según la tecnología involucrada.
El problema central no es el formato en sí, sino el acto de confiar en que un objeto reconstruido desde el exterior puede tratarse como si fuera legítimo.
Algunas defensas útiles son:
En seguridad, cuanto menos “inteligencia” se reconstruya automáticamente desde el cliente, menor será el riesgo.
Las fallas de lógica de negocio aparecen cuando el sistema permite acciones técnicamente válidas, pero incompatibles con la intención real del proceso. A diferencia de una inyección o un XSS, aquí muchas veces no hay caracteres especiales ni payloads extraños. El atacante usa la funcionalidad normal del sistema, pero de una forma no prevista.
Por eso estas fallas son especialmente difíciles de detectar con validaciones genéricas o herramientas automáticas.
En todos estos casos, el sistema puede estar respondiendo “correctamente” desde la perspectiva técnica, pero incorrectamente desde la lógica de negocio.
Muchas fallas de lógica aparecen cuando la aplicación delega demasiado en el frontend. Si el cliente calcula descuentos, estados, totales o restricciones y el backend solo los acepta, el atacante puede manipular esos valores.
La regla de seguridad sigue siendo la misma: las decisiones importantes deben recalcularse o verificarse del lado servidor.
Una aplicación segura no solo valida datos individuales. También valida el estado del proceso. Si una acción solo tiene sentido después de otra, o si un recurso cambia de comportamiento según su estado, el backend debe comprobarlo explícitamente.
Ejemplos:
Las pruebas clásicas de validación suelen preguntar si un campo tiene el formato correcto. Las pruebas de lógica de negocio deben ir más allá:
Este tipo de análisis suele requerir entender realmente el dominio del sistema.
Imaginemos una plataforma donde el usuario sube comprobantes de pago, el sistema los procesa automáticamente y luego habilita beneficios según el estado del pedido. Si el archivo subido no se valida bien, el procesador puede quedar expuesto. Si además el estado del pedido puede manipularse mediante un flujo indirecto o valores enviados por el cliente, el atacante podría activar beneficios sin cumplir realmente las condiciones del negocio.
Este ejemplo muestra cómo archivo, procesamiento y lógica funcional pueden combinarse en una misma cadena de riesgo.
Una estrategia madura suele combinar:
La seguridad en aplicaciones web no se limita a filtrar cadenas o proteger sesiones. También exige analizar cómo se reciben objetos complejos, cómo se procesan estructuras externas y cómo podría abusarse de la lógica del negocio sin necesidad de una “exploit” clásica. Este tipo de fallas suele pasar desapercibido justamente porque parece uso normal del sistema.
En el próximo tema veremos seguridad en APIs web: REST, JSON, JWT, CORS y rate limiting.