OWASP: A08 2025 - Software or Data Integrity Failures

¿Qué es Software or Data Integrity Failures?

Software or Data Integrity Failures agrupa situaciones donde una aplicación confía en software, código o datos sin comprobar adecuadamente que proceden del origen esperado y que no han sido modificados.

En OWASP Top 10 2025 esta categoría se centra especialmente en la ruptura de límites de confianza y en asumir que determinados artefactos son legítimos sin verificar su integridad. Se encuentra relacionada con la cadena de suministro, pero A08 se enfoca en controles de integridad más cercanos a la propia aplicación, mientras que A03 - Software Supply Chain Failures aborda la seguridad de la cadena de suministro de forma más amplia.

Desde una perspectiva de Red Team, el objetivo es identificar lugares donde un atacante pueda introducir o modificar datos, código o artefactos y conseguir que posteriormente sean tratados como confiables.

En este artículo analizamos las siguientes áreas:

Datos controlados por el cliente sin protección de integridad
Deserialización insegura
Modificación de atributos y Mass Assignment
Software y código cargado desde orígenes no confiables
Actualizaciones sin verificación de integridad
Integridad en CI/CD y artefactos
Rutas de búsqueda y carga de componentes

Datos controlados por el cliente sin protección de integridad

Una aplicación puede enviar información al cliente para recuperarla posteriormente y asumir que el contenido no ha sido modificado.

Algunos ejemplos habituales son:

Cookies.
Campos ocultos.
Parámetros codificados.
Estado serializado.
Datos almacenados en el navegador.
Objetos enviados entre distintas etapas de un proceso.
Tokens propietarios.

Por ejemplo:

Set-Cookie: preferences=eyJyb2xlIjoidXNlciIsInBsYW4iOiJiYXNpYyJ9

El contenido puede encontrarse simplemente codificado en Base64:

{
  "role": "user",
  "plan": "basic"
}

La codificación por sí sola no proporciona integridad.

Si el cliente puede modificar:

{
  "role": "admin",
  "plan": "premium"
}

y el servidor acepta posteriormente esos valores como legítimos, existe un fallo de confianza sobre datos controlados por el usuario.

Validación

Identifica estructuras que puedan decodificarse o interpretarse y modifica un único atributo inocuo.

Por ejemplo:

theme=light

por:

theme=dark

Si el servidor acepta el estado modificado, determina después si la misma estructura contiene valores que influyen en decisiones de seguridad.

Presta atención especialmente a:

role
admin
verified
permissions
tenant
user_id
price
plan
state
mfa

La vulnerabilidad no está en que el dato pueda leerse, sino en que pueda modificarse sin que el servidor detecte la alteración.

Cookies sin protección de integridad

Las cookies utilizadas exclusivamente para preferencias visuales normalmente no necesitan protección criptográfica.

Sin embargo, si una aplicación toma decisiones sensibles a partir de una cookie:

Cookie: role=user

debe existir algún mecanismo que impida que el cliente pueda modificar el valor arbitrariamente.

Una validación mínima consiste en modificar el valor y comprobar si el backend vuelve a calcularlo utilizando información confiable o acepta directamente el contenido enviado.

Deserialización insegura

La serialización permite representar objetos o estructuras de datos para almacenarlos o transferirlos.

El problema aparece cuando una aplicación recibe datos serializados desde un contexto no confiable y los deserializa asumiendo que representan un objeto legítimo.

Dependiendo de la tecnología utilizada, una deserialización insegura puede permitir:

Modificar propiedades internas.
Alterar el estado de la aplicación.
Saltar comprobaciones.
Crear tipos de objeto no previstos.
Invocar comportamientos durante la reconstrucción del objeto.
En algunos entornos, alcanzar ejecución de código.

Durante el reconocimiento busca:

Cookies de gran tamaño.
Parámetros codificados.
Objetos Base64.
Datos binarios.
Cabeceras propietarias.
Cuerpos de petición con formatos específicos del framework.

Algunas firmas pueden ayudar a identificar tecnologías concretas, pero una firma por sí sola no confirma que exista una vulnerabilidad.

Validación mediante modificación de estado

Antes de buscar primitivas peligrosas, determina si el objeto puede modificarse.

Por ejemplo, una estructura serializada puede representar:

UserState(
    username="sam",
    premium=false
)

Si es posible alterar el valor:

premium=true

y la aplicación acepta el objeto modificado, existe evidencia de que el cliente controla información cuya integridad debería estar protegida.

Deserialización con comportamiento peligroso

En algunos lenguajes y frameworks la reconstrucción de determinados tipos de objeto puede ejecutar métodos automáticamente.

El riesgo aumenta cuando:

El atacante controla el objeto serializado.
El servidor permite seleccionar o construir tipos arbitrarios.
Existen clases con comportamientos aprovechables durante la deserialización.

No es necesario alcanzar ejecución de código para determinar que una aplicación acepta objetos serializados sin controles de integridad.

Si resulta necesario demostrar mayor impacto, utiliza la mínima interacción posible.

Red Team OPSEC

Las cadenas de deserialización pueden ejecutar código inmediatamente durante el procesamiento del objeto.

Prioriza modificaciones inocuas del estado antes de utilizar cadenas con efectos sobre el sistema.

Si necesitas demostrar ejecución, utiliza únicamente una acción controlada y no destructiva.

Modificación de atributos y Mass Assignment

OWASP A08:2025 incluye entre sus debilidades destacadas la modificación inadecuadamente controlada de atributos de objetos determinados dinámicamente.

Este comportamiento suele aparecer cuando un framework asigna automáticamente campos recibidos del cliente sobre un objeto interno.

Por ejemplo, una API puede esperar:

{
  "name": "sam",
  "email": "sam@example.com"
}

pero el objeto interno también contiene:

role
is_admin
verified
account_status
tenant_id

Durante una prueba puedes añadir un atributo no expuesto por la interfaz:

{
  "name": "sam",
  "email": "sam@example.com",
  "is_admin": true
}

La presencia del campo en la respuesta no confirma que haya sido almacenado.

Validación

Después de enviar el atributo adicional comprueba si:

Persiste en una consulta posterior.
Cambia el comportamiento de la cuenta.
Modifica permisos.
Cambia el tenant.
Afecta al estado del objeto.
Se refleja únicamente sin ser procesado.

La vulnerabilidad se confirma cuando el servidor permite modificar un atributo que debería encontrarse fuera del control del cliente.

Este comportamiento puede terminar manifestándose como Broken Access Control o escalada de privilegios, pero desde A08 el problema se encuentra en que el sistema no preserva la integridad de las propiedades internas del objeto.

Red Team OPSEC

Utiliza cuentas y objetos controlados para probar atributos relacionados con permisos, estados o tenants.

Registra el valor original y evita modificar recursos reales cuando el cambio pueda afectar a otros usuarios.

Software y código cargado desde orígenes no confiables

Una aplicación puede incorporar funcionalidades procedentes de dominios o infraestructuras externas:

<script src="https://cdn.example.com/library.js"></script>

o cargar:

Plugins.
Módulos.
Scripts.
Widgets.
Recursos de terceros.
Componentes descargados dinámicamente.

El riesgo aparece cuando el origen externo puede modificar el código que posteriormente ejecutará la aplicación y no existe un mecanismo que permita detectar esa modificación.

Recursos JavaScript externos

Durante una evaluación identifica scripts cargados desde dominios distintos al objetivo.

Por ejemplo:

<script src="https://third-party.example/widget.js"></script>

Determina:

Quién controla ese dominio.
Si se utiliza HTTPS.
Si existe Subresource Integrity cuando resulta aplicable.
Qué privilegios obtiene el código al ejecutarse dentro de la aplicación.
Qué ocurriría si el proveedor externo fuese comprometido.

Un JavaScript de terceros que se ejecuta en el origen de la aplicación puede acceder a datos disponibles para cualquier otro script de esa página.

Subresource Integrity

Cuando se utilizan recursos estáticos externos puede aparecer:

<script
  src="https://cdn.example.com/app.js"
  integrity="sha384-..."
  crossorigin="anonymous">
</script>

El atributo integrity permite al navegador comprobar que el contenido descargado coincide con el hash esperado.

La ausencia de SRI no constituye automáticamente una vulnerabilidad.

Debe evaluarse si el recurso procede de un contexto cuya alteración representaría una ruptura relevante del límite de confianza.

Dominios externos dentro del mismo ámbito de cookies

Presta especial atención cuando una organización delega subdominios a proveedores externos.

Por ejemplo:

support.target.com -> infraestructura de un tercero

Si las cookies de autenticación están configuradas para Domain=.target.com pueden terminar enviándose también al subdominio controlado por el proveedor.

OWASP incluye un escenario de este tipo para mostrar cómo una relación de confianza con un servicio externo puede afectar a la integridad y seguridad del entorno principal.

Durante la validación utiliza únicamente dominios y cuentas controladas y comprueba el alcance real de las cookies antes de asumir impacto.

Actualizaciones sin verificación de integridad

Muchas aplicaciones, dispositivos y agentes descargan actualizaciones automáticamente.

El diseño debe verificar que una actualización:

Procede del origen esperado.
No ha sido modificada.
Se encuentra autorizada para ese producto o componente.

El uso exclusivo de HTTPS protege la conexión durante el transporte, pero no sustituye una verificación de autenticidad del artefacto cuando el modelo de amenazas requiere comprobar quién publicó la actualización.

Busca funcionalidades como:

Check for updates
Auto update
Download latest version
Update agent
Firmware upgrade
Plugin update

Validación

Si el proceso puede observarse de forma legítima, identifica:

Desde dónde se descarga el artefacto.
Si existe una firma.
Si se verifica antes de instalarlo.
Si únicamente se utiliza un checksum proporcionado desde el mismo origen.
Si el proceso acepta cualquier archivo con una estructura válida.

Un hash descargado desde el mismo servidor que proporciona el archivo permite detectar errores accidentales, pero si un atacante controla ambos recursos puede modificar el archivo y el hash simultáneamente.

Firmware y agentes

Este problema resulta especialmente relevante en:

Routers.
Appliances.
Agentes instalados en endpoints.
Aplicaciones de escritorio.
Dispositivos IoT.
Plugins.
Software con mecanismos de actualización propios.

No es necesario instalar una actualización maliciosa sobre un sistema real.

La validación puede limitarse a demostrar que el mecanismo no verifica ninguna firma o que acepta un artefacto de prueba cuya integridad no puede autenticarse.

Red Team OPSEC

Evita sustituir o instalar artefactos reales únicamente para demostrar que un mecanismo de actualización carece de verificación.

Prioriza análisis del flujo, configuraciones y recursos de laboratorio o prueba.

Integridad en CI/CD y artefactos

OWASP incluye los pipelines CI/CD inseguros dentro de esta categoría cuando no existen controles que garanticen la integridad del código y los artefactos que atraviesan el proceso de build y despliegue.

En Red Team, esta superficie puede ser especialmente relevante después de obtener acceso inicial a:

Repositorios.
Servidores de integración.
Runners.
Sistemas de build.
Registros de artefactos.
Plataformas de despliegue.

El objetivo es determinar si un acceso limitado puede convertirse en modificación del software desplegado.

Presta atención a límites como:

Repositorio -> Build
Build -> Artefacto
Artefacto -> Registry
Registry -> Deploy
CI/CD -> Producción

Controles de integridad

Comprueba conceptualmente si:

Los artefactos se firman.
La firma se verifica durante el despliegue.
Existe separación entre quien modifica código y quien despliega.
Los runners pueden modificar repositorios o artefactos fuera de su ámbito.
El pipeline descarga código desde ubicaciones no confiables.
Los artefactos pueden sustituirse después del proceso de build.
Las configuraciones de pipeline requieren revisión.

La ausencia de firma no implica automáticamente una vulnerabilidad.

Debe existir una ruta realista mediante la cual un actor menos confiable pueda modificar el artefacto sin que el sistema detecte la alteración.

Artefactos después del build

Una propiedad importante es que el artefacto que se despliega sea el mismo que fue construido y validado.

Si un paquete puede modificarse en el registro después de superar las comprobaciones:

Build -> Scan -> Upload -> [MODIFICACIÓN] -> Deploy

los controles anteriores pueden quedar anulados.

Desde Red Team resulta suficiente demostrar, mediante un artefacto de prueba o permisos observados, que existe esa posibilidad.

Red Team OPSEC

No introduzcas código en pipelines o despliegues de producción salvo que esta actividad esté expresamente contemplada en el alcance.

Cuando los permisos o un entorno de prueba demuestren que un artefacto puede sustituirse, evita modificar componentes reales.

Rutas de búsqueda y carga de componentes

OWASP A08 también incluye debilidades relacionadas con rutas de búsqueda no confiables o controlables.

Algunos programas buscan librerías, ejecutables o módulos en varias ubicaciones hasta encontrar una coincidencia.

Conceptualmente:

Directorio actual
Directorio de la aplicación
PATH
Directorios del sistema

Si un atacante puede escribir en una ubicación que se consulta antes que la legítima, puede conseguir que el proceso cargue su componente en lugar del esperado.

Este comportamiento puede aparecer en:

Ejecutables invocados sin ruta absoluta.
Librerías dinámicas.
Plugins.
Módulos.
Scripts auxiliares.
Tareas de build.
Jobs de CI/CD.

Validación

Identifica qué componente intenta cargar el proceso y qué rutas se consultan.

Después determina si alguna de esas ubicaciones es escribible desde un contexto con menos privilegios.

Por ejemplo:

Aplicación privilegiada
        |
        +--> ejecuta "helper"
                  |
                  +--> PATH contiene directorio escribible

La existencia de un directorio escribible en PATH no confirma por sí sola una vulnerabilidad.

Debe demostrarse que un proceso relevante utiliza esa ruta para resolver un componente y que el atacante puede colocar un archivo con el nombre esperado.

Red Team OPSEC

No sustituyas librerías o ejecutables legítimos en sistemas de producción.

Cuando sea posible valida la ruta de resolución, permisos y orden de búsqueda sin introducir un componente ejecutable.

Diferenciar A08 de Software Supply Chain Failures

A03 y A08 pueden parecer similares.

Una separación útil desde Red Team es:

A03 - Software Supply Chain Failures: Riesgo introducido a través de proveedores, dependencias, procesos de desarrollo y cadena de suministro.
A08 - Software or Data Integrity Failures: El sistema recibe código, artefactos o datos y confía en ellos sin verificar suficientemente su integridad.

Por ejemplo:

A03: Dependencia maliciosa publicada en un repositorio
A08: Aplicación descarga un paquete y no verifica su firma

En una cadena de ataque ambas categorías pueden aparecer simultáneamente.

La clasificación final debe centrarse en la causa raíz del hallazgo que se está documentando.