En este capítulo veremos el OWASP TOP 10 2025. Aprenderás a reconocer y comprender las principales vulnerabilidades de seguridad en aplicaciones web para el año 2025, según la prestigiosa organización OWASP. Explorarás cómo estas amenazas se clasifican, por qué representan un riesgo para los sistemas modernos y qué tendencias están marcando la evolución de la ciberseguridad.

Al finalizar, tendrás una visión clara de las causas raíz detrás de los fallos más críticos y entenderás cómo afectan al ciclo de vida del software, a la infraestructura y a la integridad de los datos.

OWASP TOP 10  2025

En la lista de los Diez Principales para 2025, se han incorporado dos categorías nuevas y una consolidada. Esta versión según OWASP está centrada en la causa raíz, más que en los síntomas, en la medida de lo posible. Dada la complejidad de la ingeniería y la seguridad del software, resulta prácticamente imposible crear diez categorías sin cierto grado de superposición.

 

 

A01:2025 Control de acceso roto

Manteniendo su posición número 1 en el Top Ten, el 100% de las aplicaciones analizadas presentaron algún tipo de control de acceso deficiente. Entre las CWE más destacadas se encuentran CWE-200: Exposición de información confidencial a un agente no autorizado , CWE-201: Exposición de información confidencial a través de datos enviados , CWE-918: Falsificación de solicitud del lado del servidor (SSRF) y CWE-352: Falsificación de solicitud entre sitios (CSRF) . Esta categoría presenta el mayor número de incidencias en los datos aportados y la segunda mayor cantidad de CVE relacionados.

Tabla de puntuación.

CWE mapeados	Tasa máxima de incidencia	Tasa de incidencia promedio	Cobertura máxima	Cobertura promedio	Exploit ponderado promedio	Impacto ponderado promedio	Total de ocurrencias	Total de CVEs
40	20,15%	3,74%	100.00%	42,93%	7.04	3.84	1.839.701	32.654

Descripción.

El control de acceso aplica políticas diseñadas para impedir que los usuarios realicen acciones fuera de sus permisos asignados. Cuando este control falla, puede provocar la divulgación, modificación o destrucción no autorizada de información, o la ejecución de funciones empresariales fuera de los límites establecidos. Entre las vulnerabilidades más comunes del control de acceso se encuentran:

• Violación del principio de mínimo privilegio o denegación por defecto: el acceso debería concederse únicamente a usuarios, roles o capacidades específicas, pero se otorga a cualquiera.
• Evasión de controles de acceso: mediante la manipulación de URLs, parámetros, estados internos de la aplicación o solicitudes de API.
• Referencias de objetos directos inseguras (IDOR): permitir acceder o modificar la cuenta de otro usuario proporcionando su identificador único.
• Controles ausentes en la API: falta de restricciones adecuadas para operaciones POST, PUT o DELETE.
• Elevación de privilegios: actuar como un usuario autenticado sin iniciar sesión o como administrador sin los permisos correspondientes.
• Manipulación de metadatos: alterar tokens JWT, cookies o campos ocultos para obtener privilegios o abusar del mecanismo de invalidación.
• Configuraciones incorrectas de CORS: permiten que orígenes no autorizados accedan a la API.
• Navegación forzada: acceder a páginas autenticadas o privilegiadas sin los permisos necesarios.

Cómo prevenir.

El control de acceso solo es efectivo cuando se implementa en código del lado del servidor confiable o en API sin servidor, donde el atacante no puede modificar la verificación de control de acceso ni los metadatos.

• Excepto para recursos públicos, denegar por defecto.
• Implemente mecanismos de control de acceso una sola vez y reutilícelos en toda la aplicación, lo que incluye minimizar el uso de recursos compartidos de origen cruzado (CORS).
• Los controles de acceso al modelo deben imponer la propiedad de los registros en lugar de permitir que los usuarios creen, lean, actualicen o eliminen cualquier registro.
• Los modelos de dominio deben imponer requisitos de límites de negocio de aplicaciones únicas.
• Deshabilite la lista de directorios del servidor web y asegúrese de que los metadatos de los archivos (por ejemplo, .git) y los archivos de respaldo no estén presentes en las raíces web.
• Registrar los fallos de control de acceso y alertar a los administradores cuando corresponda (por ejemplo, fallos repetidos).
• Implemente límites de velocidad en el acceso a API y controladores para minimizar el daño de las herramientas de ataque automatizadas.
• Los identificadores de sesión con estado deben invalidarse en el servidor tras cerrar la sesión. Los tokens JWT sin estado deben tener una vida útil corta para minimizar la ventana de oportunidad para un atacante. Para los JWT de larga duración, se recomienda encarecidamente seguir los estándares de OAuth para revocar el acceso.
• Utilice kits de herramientas o patrones bien establecidos que proporcionen controles de acceso simples y declarativos.

Los desarrolladores y el personal de control de calidad deben incluir control de acceso funcional en sus pruebas unitarias y de integración.

Ejemplos de escenarios de ataque.

Escenario n.° 1:

La aplicación utiliza datos no verificados en una llamada SQL que accede a la información de la cuenta:

pstmt.setString(1, request.getParameter(«acct»));
ResultSet results = pstmt.executeQuery( );

Un atacante puede simplemente modificar el parámetro «acct» del navegador para enviar cualquier número de cuenta. Si no se verifica correctamente, el atacante puede acceder a la cuenta de cualquier usuario.

https://example.com/app/accountInfo?acct=notmyacct

Escenario n.° 2

Un atacante simplemente fuerza a los navegadores a acceder a las URL objetivo. Se requieren derechos de administrador para acceder a la página de administración.

https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo

Si un usuario no autenticado puede acceder a cualquiera de las páginas, se trata de una falla. Si un usuario no administrador puede acceder a la página de administración, se trata de una falla.

Escenario n.° 3

Una aplicación establece todo su control de acceso en su frontend. Aunque el atacante no puede acceder a él https://example.com/app/admin_getappInfodebido al código JavaScript que se ejecuta en el navegador, puede simplemente ejecutar:

$ curl https://example.com/app/admin_getappInfo

desde la línea de comandos.

A01:2025 – Control de Acceso Vulnerado (Broken Access Control)

Cuando un usuario accede a datos o funciones que no debería poder ver o usar.

En 2025 sigue siendo el puesto #1 porque es la causa más frecuente y crítica de compromisos reales.

Incluye: IDOR, BOLA, Insecure Direct Object Reference, fuerza bruta de recursos, privilegios mal validados, bypass de controles de frontend, APIs malas, diseño inseguro de permisos, etc.

🧩 Ejemplos típicos (2025)

• Cambiar el ID de /api/v2/users/321 por otro y ver datos ajenos (IDOR clásico).
• Llamar endpoints ocultos de API (v1, v2, legacy) que no tienen autorización.
• Editar precios, saldos, claves o recursos enviando un PUT/POST modificado.
• Escalada vertical: un usuario básico accede a /admin/*.
• Escalada horizontal: un usuario accede a cosas de otros usuarios.
• Bypass de controles por frontend mal implementado.
• Roles mal definidos: oculto en UI pero permitido en backend.
• Token mal validado que permite “convertirse” en otro usuario.
• Servidores sin política “deny-by-default”.

🔍 Mini-guía de explotación (2025)

1. Enumerar rutas, IDs, tokens, parámetros “sospechosos”.
2. Probar secuencias numéricas: /api/v2/client/100, 101, 102…
3. Cambiar métodos HTTP: GET → POST, PUT → PATCH, DELETE.
4. Probar versiones antiguas de API: /v1/, /v2/, /mobile/.
5. Probar combinación de tokens (session + JWT + cookies).
6. Eliminar controles del lado cliente (JS, botones ocultos, HTML deshabilitado).
7. Saltar validaciones débiles (CORS permisivo, parámetros ignorados).
8. Validar filtraciones: responder diferente según usuario → diferencia de comportamiento.

🎯 Consecuencias

• Exposición de información sensible (PII, tarjetas, IBAN, transacciones).
• Robo de identidad y toma de cuentas (ATO).
• Modificación directa de datos.
• Escalada de privilegios total.
• Compromiso completo de APIs y microservicios.
• Fraude financiero.
• Acceso a funciones administrativas no destinadas a usuarios normales.
• Filtración de archivos internos u objetos de almacenamiento.
• Acceso transversal entre tenants (multi-tenant inseguro).

🛡 Defensas modernas (2025)

• Deny-by-default en TODA API y backend.
• Autorización por objeto (object-level authorization) en cada endpoint.
• Autorización por recurso y por acción (RBAC + ABAC).
• Validar siempre en backend, nunca confiar en frontend.
• ID no predecibles (UUID, Snowflake IDs, hashes).
• Separar autenticación de autorización (AuthN vs AuthZ).
• API Gateway con políticas por método y por path.
• Revisiones de diseño inseguro (Threat Modeling).
• Pruebas automatizadas de autorización por cada endpoint.
• Multi-tenant seguro: nunca mezclar datos entre usuarios/organizaciones.
• Límites estrictos de CORS (no wildcard).
• Logs de acceso a recursos sensibles.

📚 Subtipos/patrones modernos (2025)

Subtipo 2025	Definición	Ejemplo bancario	Pentesting (qué probar)	Ataque / PoC	Consecuencia	Defensa	Tips examen
IDOR / BOLA / OLaP	Cambiar ID y acceder a objetos ajenos	Ver cuenta X cambiando /1234 por /1235	Cambiar IDs numéricos, UUID, tokens	GET /account/0002 con token de 0001	Exposición de PII, fraude	Chequeo por objeto	“Si el usuario cambia un ID y accede, es IDOR/BOLA”
BAC en funciones (FLoA)	Acceso a funciones no permitidas	Usuario básico accede a /admin/payments	Probar rutas ocultas	GET /admin/…	Escalada vertical	RBAC/ABAC	Buscar palabras “admin”, “manage”, “config”
Mass Assignment	Backend asigna más campos de los esperados	Cambiar “role”: “user” → “admin”	Enviar JSON con campos ocultos	{“role”:”admin”}	Escalada total	DTOs estrictos	Si un campo oculto cambia rol → Mass Assignment
Forced Browsing	Acceder a rutas ocultas sin permiso	/exports/2024/data.csv	Enumerar /backup/, /old/	/secret/report.pdf	Filtración	Whitelist de rutas	Si la ruta existe sin rol → forced browsing
Métodos HTTP inseguros	Permitir DELETE/PUT sin control	DELETE /users/13	Cambiar método	DELETE /users/44	Borrado/modificación	Autorizar por método	Atención a “DELETE permitido”
Multi-tenant inseguro	Usuarios acceden a datos de otro tenant	Banco A ve datos de Banco B	Cambiar tenant_id	/tenant/2/cards	Exposición masiva	Aislamiento por tenant	“Si mezcla datos entre clientes → 0/10”
CORS inseguro	CORS abierto permite robar datos	Origin mal configurado	Probar con origin arbitrario	CORS con *	Robo de tokens, CSRF	Políticas estrictas	“Si CORS acepta todo → falso seguro”

🧪 Check-list rápida para pentesting A01:2025

• Probar IDOR en TODOS los endpoints que tengan IDs.
• Verificar vertical: /admin/*, /superuser/*.
• Verificar horizontal: recursos de otros usuarios.
• Cambiar método HTTP.
• Enumerar rutas ocultas, backups, endpoints viejos.
• Probar versiones v1/v2/mobile/internal/legacy.
• Probar parámetros ocultos: role, isAdmin, balance, price.
• Probar tokens mezclados (session + JWT).
• Revisar CORS y bypasses.
• Revisar multi-tenant.
• Revisar mass assignment.
• Revisar APIs GraphQL (schema abierto).

🧾 Resumen ejecutivo (1 párrafo para slides o curso)

A01:2025 Broken Access Control sigue siendo el riesgo más crítico del OWASP Top 10 porque ocurre cuando una aplicación no valida correctamente lo que un usuario puede ver o hacer. Esto permite acceder a datos de otros usuarios, editar información sensible, escalar privilegios y acceder a funciones administrativas. Incluye IDOR/BOLA, rutas ocultas accesibles, métodos HTTP inseguros, mass assignment, fallas multi-tenant y bypass de controles de frontend. La mitigación exige autorización estricta por objeto, políticas deny-by-default, RBAC/ABAC, validación siempre en backend, CORS seguro, aislamiento por tenant y pruebas automatizadas de permisos para cada endpoint. Es el problema más común y el más explotado en APIs modernas.

A02:2025 Configuración incorrecta de seguridad

A partir del puesto n.° 5 de la edición anterior, se detectó algún tipo de configuración incorrecta en el 100 % de las aplicaciones analizadas, con una tasa de incidencia promedio del 3 % y más de 719 000 casos de una Enumeración de Debilidades Comunes (CWE) en esta categoría de riesgo. Con la creciente adopción de software altamente configurable, no sorprende ver un ascenso en esta categoría. Entre las CWE más destacadas se incluyen la CWE-16 Configuración y la CWE-611 Restricción incorrecta de la referencia a entidades externas XML (XXE).

Se debe definir e implementar una configuración de seguridad para la aplicación, los marcos, el servidor de aplicaciones, el servidor web, el servidor de bases de datos y la plataforma. Si se configuran correctamente, un atacante puede tener acceso no autorizado a datos o funciones confidenciales.

A veces, estos fallos pueden comprometer por completo el sistema. Mantener el software actualizado también es una buena medida de seguridad.

Implicación

• Aprovechando esta vulnerabilidad, el atacante puede enumerar la tecnología subyacente y la información de la versión del servidor de aplicaciones, información de la base de datos y obtener información sobre la aplicación para montar algunos ataques más.

Objetos vulnerables

• URL
• Campos de formulario
• Campos de entrada

Tabla de puntuación.

CWE mapeados	Tasa máxima de incidencia	Tasa de incidencia promedio	Cobertura máxima	Cobertura promedio	Exploit ponderado promedio	Impacto ponderado promedio	Total de ocurrencias	Total de CVEs
16	27,70%	3.00%	100.00%	52,35%	7.96	3.97	719.084	1.375

Descripción.

Una mala configuración de seguridad ocurre cuando un sistema, una aplicación o un servicio en la nube se configura incorrectamente desde una perspectiva de seguridad, lo que crea vulnerabilidades.

La aplicación podría ser vulnerable si:

• Falta un refuerzo de seguridad adecuado en cualquier parte de la pila de aplicaciones o permisos configurados incorrectamente en los servicios en la nube.
• Se habilitan o instalan funciones innecesarias (por ejemplo, puertos, servicios, páginas, cuentas, marcos de prueba o privilegios innecesarios).
• Las cuentas predeterminadas y sus contraseñas siguen habilitadas y sin cambios.
• Falta de una configuración central para interceptar mensajes de error excesivos. La gestión de errores revela a los usuarios rastros de pila u otros mensajes de error excesivamente informativos.
• En el caso de los sistemas actualizados, las funciones de seguridad más recientes están deshabilitadas o no están configuradas de forma segura.
• Priorización excesiva de la compatibilidad con versiones anteriores que conduce a una configuración insegura.
• Las configuraciones de seguridad en los servidores de aplicaciones, los marcos de aplicaciones (por ejemplo, Struts, Spring, ASP.NET), las bibliotecas, las bases de datos, etc., no están establecidas en valores seguros.
• El servidor no envía encabezados o directivas de seguridad, o no están configurados con valores seguros.

Sin un proceso concertado y repetible de fortalecimiento de la configuración de seguridad de las aplicaciones, los sistemas corren un mayor riesgo.

Cómo prevenir.

Se deben implementar procesos de instalación seguros, que incluyan:

• Un proceso de refuerzo repetible que permite la implementación rápida y sencilla de otro entorno debidamente bloqueado. Los entornos de desarrollo, control de calidad y producción deben configurarse de forma idéntica, con credenciales diferentes en cada uno. Este proceso debe automatizarse para minimizar el esfuerzo necesario para configurar un nuevo entorno seguro.
• Una plataforma minimalista sin funciones, componentes, documentación ni ejemplos innecesarios. Elimine o no instale funciones y frameworks no utilizados.
• Una tarea para revisar y actualizar las configuraciones correspondientes a todas las notas de seguridad, actualizaciones y parches como parte del proceso de gestión de parches (véase A03:2025 – Fallos en la cadena de suministro de software). Revisar los permisos de almacenamiento en la nube (p. ej., permisos de buckets S3).
• Una arquitectura de aplicación segmentada proporciona una separación efectiva y segura entre componentes o inquilinos, con segmentación, contenedorización o grupos de seguridad en la nube (ACL).
• Envío de directivas de seguridad a los clientes, por ejemplo, encabezados de seguridad.
• Un proceso automatizado para verificar la efectividad de las configuraciones y ajustes en todos los entornos.
• Agregue de forma proactiva una configuración central para interceptar mensajes de error excesivos como respaldo.
• Si estas verificaciones no están automatizadas, deberán verificarse manualmente como mínimo una vez al año.
• Una arquitectura de aplicación sólida que proporciona una buena separación y seguridad entre los componentes.
• Cambiar nombres de usuario y contraseñas predeterminados.
• Deshabilite los listados de directorios e implemente controles de control de acceso.

Ejemplos de escenarios de ataque.

Escenario n.° 1: El servidor de aplicaciones incluye aplicaciones de muestra que no se eliminaron del servidor de producción. Estas aplicaciones presentan vulnerabilidades de seguridad conocidas que los atacantes utilizan para comprometer el servidor. Supongamos que una de estas aplicaciones es la consola de administración y que las cuentas predeterminadas no se han modificado. En ese caso, el atacante inicia sesión con la contraseña predeterminada y toma el control.

Escenario n.° 2: El listado de directorios no está deshabilitado en el servidor. Un atacante descubre que puede simplemente listar directorios. Encuentra y descarga las clases Java compiladas, las descompila y aplica ingeniería inversa para ver el código. A continuación, descubre una grave vulnerabilidad de control de acceso en la aplicación.

Escenario n.° 3: La configuración del servidor de aplicaciones permite que se devuelvan a los usuarios mensajes de error detallados, como seguimientos de pila. Esto podría exponer información confidencial o fallos subyacentes, como versiones de componentes vulnerables.

Escenario n.° 4: Un proveedor de servicios en la nube (CSP) tiene permisos de uso compartido abiertos a Internet por defecto. Esto permite acceder a datos confidenciales almacenados en la nube.

La consola de administración del servidor de aplicaciones se instala automáticamente y no se elimina. Las cuentas predeterminadas no se modifican. El atacante puede iniciar sesión con contraseñas predeterminadas y obtener acceso no autorizado.

La lista de directorios no está deshabilitada en su servidor. El atacante descubre y puede simplemente listar directorios para encontrar cualquier archivo.

A02:2025 – Configuración Incorrecta de Seguridad (Security Misconfiguration)

Se produce cuando la aplicación, el servidor, la API o los servicios de infraestructura están mal configurados, tienen valores por defecto, permisos inseguros, funciones innecesarias habilitadas, exposición no intencionada o falta de endurecimiento (hardening).

A02 es tan común porque los sistemas modernos están formados por docenas de componentes, y uno solo mal configurado rompe toda la cadena de seguridad.

Ejemplos típicos modernos (2025)

• Consolas administrativas expuestas (/admin, /actuator, /swagger, /console).
• Archivos sensibles expuestos por error: .env, .git/, backup.zip, /config.yaml.
• CORS mal configurado (Access-Control-Allow-Origin: *).
• Buckets S3 / blobs abiertos al público.
• Servidores cloud con puertos innecesarios abiertos.
• Permisos laxos en contenedores (root user).
• Instancias con patches faltantes.
• Debug mode o stack traces habilitados en producción.
• Policies IAM demasiado amplias (*:*).
• API Gateway sin restricción por método, origen, o rol.
• Valores default: credenciales por defecto, puertos por defecto, rutas por defecto.
• Inyección por encabezados gracias a proxies mal configurados.

Mini-guía de explotación (2025)

1. Enumerar rutas de administración (Swagger, Actuator, Adminer, phpMyAdmin).
2. Buscar archivos expuestos (/.env, /db.sql, /backup.tar.gz).
3. Revisar headers de seguridad (CSP, HSTS, XFO, CORP, COEP).
4. Probar CORS permisivo (cualquiera origen).
5. Examinar mensajería interna: stack traces, debug prints, variables de entorno.
6. Enumerar servicios abiertos: puertos 22, 3306, 27017, 6379, 5432, 8000/8080.
7. Probar endpoints de monitoreo: /metrics, /health, /info.
8. Buscar permisos IAM inseguros (AWS, GCP, Azure).
9. Probar reenvío de host/header injection en servicios mal configurados.
10. Revisar contenedores corriendo como root.

Consecuencias

• Exposición de información sensible (claves, tokens, contraseñas).
• Compromiso total de infraestructura (cloud takeover).
• Ejecución remota de código (RCE) por funciones activas o debug.
• Desvío del flujo de autorización/identidad mediante proxies inseguros.
• Filtración de configuraciones críticas (API keys, secrets).
• Persistencia de atacantes por falta de hardening.
• Acceso a paneles internos y funciones administrativas.
• Fugas de datos a través de buckets y contenedores abiertos.
• Ataques SSRF gracias a metadatos cloud expuestos.

Defensas modernas (2025)

• Deny-by-default en APIs, cloud, storage y servicios internos.
• Hardening automático por IaC (Infrastructure as Code) validado.
• Eliminar funciones innecesarias (debug, test, admin, verbose logs).
• Configurar correctamente CORS: sin wildcard, sin orígenes dinámicos.
• Headers de seguridad (CSP, COOP, CORP, HSTS, X-Frame-Options, etc.).
• Rotación de secrets + uso de Secret Managers, no archivos.
• Bases de datos no expuestas a Internet.
• Revisión de permisos IAM mínimos (least privilege).
• WAF / API Gateway con políticas estrictas por método.
• Escaneo automático de configuraciones (ScoutSuite, Prowler, kube-bench).
• Deshabilitar listados de directorio.
• Bloquear acceso a metadata de cloud (IMDSv2 en AWS).
• Contenedores como usuarios no privilegiados.
• Automatización CI/CD para verificar configuraciones antes de deploy.

📚 Subtipos/patrones modernos (2025)

(Mismo formato que tu tabla original)

Subtipo / patrón	Definición	Ejemplo bancario	Pentesting (qué probar)	Ataque / PoC	Consecuencia	Defensa	Tips examen
CORS inseguro	Orígenes permitidos sin restricción	Portal permite cualquier origin	Probar con dom. propio	JS roba tokens vía XHR	Robo de sesiones, CSRF avanzado	Lista blanca estricta	“*CORS abierto = grave*”
Debug / verbose	Modo debug o stack trace en prod	/error revela clases, routes	Forzar error 500/404	Stacktrace expone secretos	Info leakage, RCE	Desactivar en prod	Si hay stack trace → Misconfiguration
Archivos expuestos	.env, .git, backups accesibles	db_backup.sql accesible	Enumerar /, robots.txt, backups	Descargar secrets	Claves API filtradas	No exponer dirs	Palabras claves: .env, .git
Credenciales por defecto	Como “admin/admin”	Consola bancaria interna	Probar combos conocidos	Login exitoso	Control total	Password rotation	“Default creds siempre crítica”
Headers de seguridad faltantes	CSP, HSTS, COOP, etc.	No HSTS en login bancario	Revisar headers en respuesta	Inyección script	XSS, clickjacking	Añadir headers	Preguntan por “faltan headers”
Cloud bucket abierto	S3/GCS sin ACL estricta	Documentos de clientes accesibles	Navegar bucket directo	Descargar PDFs, CSV	Fuga masiva	ACL privada	“Bucket público = Misconfiguration”
Servicios innecesarios expuestos	Puertos abiertos extra	Redis/MongoDB expuestos	Escanear puertos	Acceso a DB sin auth	RCE/robo datos	Filtrado estricto	27017/6379 expuestos = fail
Permisos IAM amplios	*:* en políticas	Usuario interno puede borrar todo	Revisar políticas	Escalada cloud	Toma total de cuentas	Least privilege	Buscar «Action»:»*»
API Gateway permisivo	Métodos sin control	DELETE accesible sin permiso	Probar OPTIONS y métodos	Borra datos	Manipulación	Políticas por método	“DELETE sin Auth = grave”
Kubernetes inseguro	Dashboard abierto	K8s dashboard sin password	Probar /api/v1/*	Tomar pods	Acceso total cluster	RBAC K8s	Keywords: kubelet, etcd

Checklist rápida de pentesting A02:2025

• Revisar CORS.
• Enumerar archivos expuestos.
• Buscar debug mode / stack traces.
• Verificar headers de seguridad.
• Enumerar paneles administrativos expuestos.
• Revisar buckets cloud.
• Revisar permisos IAM y credenciales hardcodeadas.
• Verificar métodos HTTP innecesarios (TRACE, OPTIONS, PUT, DELETE).
• Revisar exposición de bases de datos.
• Revisar configuración de contenedores.
• Validar acceso a metadata cloud.
• Escanear puertos y servicios que no deberían estar.

Resumen ejecutivo para tu curso

A02:2025 Security Misconfiguration ocupa el segundo puesto del OWASP Top 10 porque la mayoría de las aplicaciones modernas dependen de múltiples componentes y un solo elemento mal configurado puede abrir la puerta a un compromiso completo. Incluye CORS permisivo, archivos sensibles expuestos, servicios innecesarios, credenciales por defecto, buckets abiertos, políticas IAM laxas, paneles administrativos visibles, debug activado y headers de seguridad faltantes. La mitigación requiere un enfoque de hardening continuo: deny-by-default, políticas estrictas en servidores, autenticación en cualquier interfaz administrativa, gestión segura de secrets, verificación automática de configuraciones mediante CI/CD e implementación de controles de seguridad en infraestructura como código. Es una de las categorías más fáciles de explotar y una de las principales causas de brechas reales.

 

 

A03:2025 Fallas en la cadena de suministro de software

Esto fue clasificado alto en la encuesta de la comunidad Top 10 con exactamente el 50% de los encuestados clasificándolo en el n.º 1. Desde que apareció inicialmente en el Top 10 de 2013 como «A9 – Uso de componentes con vulnerabilidades conocidas», el riesgo ha crecido en alcance para incluir todas las fallas de la cadena de suministro, no solo las que involucran vulnerabilidades conocidas.

A pesar de este mayor alcance, las fallas de la cadena de suministro siguen siendo un desafío para identificar con solo 11 vulnerabilidades y exposiciones comunes (CVE) que tienen las CWE relacionadas. Sin embargo, cuando se prueba e informa en los datos aportados, esta categoría tiene la tasa de incidencia promedio más alta en 5,19%.

Las CWE relevantes son CWE-477: Uso de función obsoleta, CWE-1104: Uso de componentes de terceros sin mantenimiento , CWE-1329: Dependencia de componente que no es actualizable y CWE-1395: Dependencia de componente de terceros vulnerable .

Tabla de puntuación.

CWE mapeados	Tasa máxima de incidencia	Tasa de incidencia promedio	Cobertura máxima	Cobertura promedio	Exploit ponderado promedio	Impacto ponderado promedio	Total de ocurrencias	Total de CVEs
5	8,81%	5,19%	65,42%	28,93%	8.17	5.23	215.248	11

Descripción.

Las fallas en la cadena de suministro de software son averías u otros problemas en el proceso de desarrollo, distribución o actualización de software. Suelen deberse a vulnerabilidades o cambios maliciosos en código, herramientas u otras dependencias de terceros de las que depende el sistema.

Es probable que usted sea vulnerable si:

• Si no realiza un seguimiento cuidadoso de las versiones de todos los componentes que utiliza (tanto del lado del cliente como del lado del servidor). Esto incluye los componentes que utiliza directamente, así como las dependencias anidadas (transitivas).
• Si el software es vulnerable, no tiene soporte o está desactualizado. Esto incluye el sistema operativo, el servidor web/de aplicaciones, el sistema de gestión de bases de datos (SGBD), las aplicaciones, las API y todos los componentes, los entornos de ejecución y las bibliotecas.
• Si no escanea periódicamente en busca de vulnerabilidades y no se suscribe a boletines de seguridad relacionados con los componentes que utiliza.
• Si no cuenta con un proceso de gestión de cambios o seguimiento de cambios dentro de su cadena de suministro, incluido el seguimiento de IDE, extensiones y actualizaciones de IDE, cambios en el repositorio de código de su organización, entornos sandbox, repositorios de imágenes y bibliotecas, la forma en que se crean y almacenan los artefactos, etc. Cada parte de su cadena de suministro debe estar documentada, especialmente los cambios.
• Si no ha endurecido cada parte de su cadena de suministro, con un enfoque especial en el control de acceso y la aplicación del mínimo privilegio.
• Si sus sistemas de cadena de suministro no tienen separación de funciones, ninguna persona debería poder escribir código y promoverlo hasta la producción sin la supervisión de otra persona.
• Si a los desarrolladores, profesionales de DevOps o de infraestructura se les permite descargar y usar componentes de fuentes no confiables para su uso en producción.
• Si no se reparan o actualizan la plataforma, los marcos y las dependencias subyacentes de forma oportuna y teniendo en cuenta los riesgos. Esto suele ocurrir en entornos donde la aplicación de parches es una tarea mensual o trimestral bajo control de cambios, lo que deja a las organizaciones expuestas a días o meses de exposición innecesaria antes de corregir las vulnerabilidades.
• Si los desarrolladores de software no prueban la compatibilidad de las bibliotecas actualizadas, mejoradas o parcheadas.
• Si no protege las configuraciones de cada parte de su sistema (consulte A02:2025-Configuración incorrecta de seguridad ).
• Si tiene una canalización CI/CD compleja que utiliza muchos componentes pero tiene una seguridad más débil que el resto de su aplicación.

 

Cómo prevenir.

Debería existir un proceso de gestión de parches para:

• Conozca la lista de materiales de software (SBOM) de todo su software y administre el diccionario SBOM de forma centralizada.
• Realice un seguimiento no sólo de sus propias dependencias, sino también de sus dependencias (transitivas), y así sucesivamente.
• Elimina dependencias no utilizadas, funciones, componentes, archivos y documentación innecesarios. Reduce la superficie de ataque.
• Inventariar continuamente las versiones de los componentes del lado del cliente y del lado del servidor (por ejemplo, marcos, bibliotecas) y sus dependencias utilizando herramientas como versiones, OWASP Dependency Check, retire.js, etc.
• Monitoree continuamente fuentes como Vulnerabilidades y Exposiciones Comunes (CVE) y la Base de Datos Nacional de Vulnerabilidades (NVD) para detectar vulnerabilidades en los componentes que utiliza. Utilice análisis de composición de software, la cadena de suministro de software o herramientas SBOM centradas en la seguridad para automatizar el proceso. Suscríbase para recibir alertas por correo electrónico sobre vulnerabilidades de seguridad relacionadas con los componentes que utiliza.
• Obtenga componentes únicamente de fuentes oficiales (confiables) a través de enlaces seguros. Prefiera los paquetes firmados para reducir la posibilidad de incluir un componente modificado y malicioso (consulte A08:2025 – Fallos de integridad de software y datos ).
• Elegir deliberadamente qué versión de una dependencia utilizar y actualizarla solo cuando sea necesario.
• Monitoree bibliotecas y componentes sin mantenimiento o que no generen parches de seguridad para versiones anteriores. Si no es posible aplicar parches, considere implementar un parche virtual para monitorear, detectar o protegerse contra el problema detectado.
• Actualice su CI/CD, IDE y cualquier otra herramienta de desarrollo periódicamente
• Trate los componentes en su canalización de CI/CD como parte de este proceso; fortalézcalos, monitoréelos y documente los cambios según corresponda.

Debe haber un proceso de gestión de cambios o un sistema de seguimiento para rastrear los cambios en:

•  Su configuración de CI/CD (todas las herramientas de compilación y canalización)
• Su repositorio de código
• Áreas de pruebas
• IDE de desarrollador
• Sus herramientas SBOM y artefactos creados
• Sus sistemas de registro y registros
• Integraciones de terceros, como SaaS
• Repositorio de artefactos
• Registro de contenedores

Fortalezca los siguientes sistemas, lo que incluye habilitar MFA y bloquear IAM:

• Su repositorio de código (que incluye no registrar secretos, proteger ramas, copias de seguridad)
• Estaciones de trabajo de desarrollador (parches regulares, MFA, monitoreo y más)
• Su servidor de compilación y CI/CD (separación de tareas, control de acceso, compilaciones firmadas, secretos de alcance ambiental, registros a prueba de manipulaciones, más)
• Sus artefactos (garantice la integridad a través de la providencia, la firma y el sellado de tiempo, promueva artefactos en lugar de reconstruir para cada entorno, asegúrese de que las compilaciones sean inmutables)
• La infraestructura como código se administra como todo el código, incluido el uso de PR y control de versiones

Toda organización debe garantizar un plan continuo para monitorear, clasificar y aplicar actualizaciones o cambios de configuración durante la vida útil de la aplicación o la cartera.

Ejemplos de escenarios de ataque.

Escenario n.° 1: Un proveedor de confianza se ve comprometido con malware, lo que pone en riesgo sus sistemas informáticos al actualizar. El ejemplo más conocido es probablemente el siguiente: El ataque a SolarWinds en 2019 que comprometió a unas 18.000 organizaciones.  https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack

Escenario n.° 2: Un proveedor confiable se ve comprometido de tal manera que se comporta de manera maliciosa solo bajo una condición específica. El robo de $1.5 mil millones de Bybit en 2025 fue causado por un ataque a la cadena de suministro en el software de billetera que solo se ejecutó cuando se usaba la billetera objetivo. https://thehackernews.com/2025/02/bybit-hack-traced-to-safewallet-supply.html

Escenario n.° 3: El ataque a la cadena de suministro de GlassWorm en 2025 contra el marketplace de VS Code hizo que actores maliciosos implementaran código invisible y autorreplicante en una extensión legítima del Marketplace de VS, así como en varias extensiones del Marketplace de OpenVSX, que se actualizaban automáticamente en los equipos de los desarrolladores. El gusano extrajo inmediatamente secretos locales de los equipos de los desarrolladores, intentó establecer un control total y, si era posible, vació sus monederos de criptomonedas. Este ataque a la cadena de suministro fue extremadamente avanzado, de rápida propagación y dañino, y al dirigirse a los equipos de los desarrolladores, demostró que ahora son los propios desarrolladores los principales objetivos de los ataques a la cadena de suministro.

Escenario n.° 4: Los componentes suelen ejecutarse con los mismos privilegios que la propia aplicación, por lo que las fallas en cualquier componente pueden tener consecuencias graves. Dichas fallas pueden ser accidentales (p. ej., un error de codificación) o intencionadas (p. ej., una puerta trasera en un componente). Algunos ejemplos de vulnerabilidades explotables de componentes descubiertas son:

• CVE-2017-5638, una vulnerabilidad de ejecución remota de código en Struts 2 que permite la ejecución de código arbitrario en el servidor, ha sido señalada como la causa de importantes infracciones.
• Si bien la Internet de las cosas (IoT) suele ser difícil o imposible de parchar, la importancia de hacerlo puede ser grande (por ejemplo, en el caso de los dispositivos biomédicos).

Existen herramientas automatizadas que ayudan a los atacantes a encontrar sistemas sin parches o mal configurados. Por ejemplo, el motor de búsqueda Shodan IoT puede ayudar a encontrar dispositivos que aún sufren la vulnerabilidad Heartbleed, parcheada en abril de 2014.

A03:2025 – Fallas en la Cadena de Suministro de Software (Software Supply Chain Failures)

La aplicación depende de librerías, paquetes, contenedores, servicios cloud, plugins, proveedores externos y componentes que, si están comprometidos, desactualizados, inseguros o manipulados, introducen vulnerabilidades aunque el código propio esté perfecto.

En 2025 sube porque los ataques a la cadena de suministro aumentan exponencialmente: contaminación de paquetes NPM, dependencias maliciosas, contenedores vulnerables, manipulación de pipelines y proveedores externos comprometidos.

🧩 Ejemplos típicos (2025)

• Instalar dependencias NPM/PyPI con malware oculto.
• Bibliotecas desactualizadas con CVEs críticos.
• Paquetes que cambian de dueño (“package hijacking”).
• Dependencias ocultas en transitive dependencies (árbol profundo).
• Imágenes Docker base con vulnerabilidades severas.
• Proveedores cloud que exponen tokens o credenciales.
• Scripts de build manipulados (CI/CD comprometido).
• Toolchains o compiladores adulterados.
• Dependencias con typosquatting: react-dom vs reactd0m.
• Inclusión de SDKs de terceros con tracking o backdoors.
• Falta de verificación de firma en paquetes o contenedores.
• Plugins o extensiones vulnerables en CMS o frameworks.

🔍 Mini-guía de explotación / Pentesting de cadena de suministro

1. Enumerar dependencias directas y transitivas (NPM, pip, composer, gradle, maven).
2. Buscar CVEs en cada una (automatizable con SCA).
3. Revisar dependencias sospechosas por nombre o poca reputación.
4. Validar firmas/Hashes en paquetes descargados.
5. Analizar imágenes de contenedores (Trivy, Grype).
6. Revisar scripts de build en CI/CD para identificar:
   • descarga de recursos externos
   • scripts bash sin control
   • tokens hardcodeados
7. Buscar inyección en pipelines (GitHub Actions mal configuradas, runners públicos).
8. Revisar proveedores externos (API keys, acceso SDK).
9. Probar que el servidor no descarga código en runtime sin verificación.
10. Analizar uso de componentes abandonados o sin mantenimiento.

🎯 Consecuencias

• Compromiso total aunque el código propio sea seguro.
• Robo de datos mediante dependencias maliciosas.
• Exfiltración mediante SDKs de terceros.
• Introducción de backdoors en tiempo de compilación.
• Ataques a la cadena CI/CD → push de código malicioso.
• Contaminación de contenedores → RCE indirecto.
• Suplantación de paquetes (typosquatting).
• Ataques supply-chain tipo SolarWinds, Log4Shell o event-stream.

🛡 Defensas modernas (2025)

• SBOM (Software Bill of Materials) obligatorio.
• SCA (Software Composition Analysis) automático en CI/CD.
• Verificación de firmas de paquetes (sigstore, cosign).
• Instalar dependencias desde repos privados o verificados.
• Bloquear instalación de paquetes desconocidos (npm audit, pip audit).
• Endurecer contenedores base y mantenerlos actualizados.
• Escaneo de imágenes en cada build.
• Revisar scripts de build (GitHub Actions/CI) para evitar ejecución arbitraria.
• Tokens de CI/CD con least privilege.
• Habilitar verifySource, integrity y checksum en package managers.
• Control de versiones + prohibir dependencias abandonadas.
• Validación automática de CVEs antes del deploy.

📚 Subtipos / patrones modernos (2025)

(en tu mismo formato tabular)

Subtipo / patrón	Definición	Ejemplo bancario	Pentesting (qué probar)	Ataque / PoC	Consecuencia	Defensa	Tips examen
Paquete desactualizado con CVEs	Librerías vulnerables	Usan Log4J viejo	Revisar versionado	Exploit RCE	Toma total	SCA + update	“CVE = fallo supply chain”
Paquete malicioso (NPM/PyPI)	Dependencias infectadas	SDK fraudulento	Revisar origen/reputación	Inst. maliciosa	Robo datos	Firma + SBOM	Typosquatting = red flag
Typosquatting	Nombre similar	jqueery	Comparar nombres	Descargar paquete falso	Backdoor	Mgr privados	Siempre sospechar errores ortográficos
Dependencias transitivas inseguras	CVEs en árbol profundo	libC vulnerable	Enumerar árbol	RCE indirecto	Compromiso total	SCA automático	“Transitive dependencies” aparece siempre
Contenedores inseguros	Imágenes base vulnerables	Docker base sin patch	Escanear (Trivy)	Exploit dentro del contenedor	RCE / lateral	Imágenes mínimas	“Alpine, distroless = mejor”
Compromiso del pipeline CI/CD	Scripts manipulados	GitHub Actions sin control	Revisar permisos	Ejecutar código en pipeline	Backdoor	Hardening CI/CD	Buscar pull_request mal configurado
Firmas no verificadas	Falta verificación	pip sin –require-hashes	Chequear firma	Inyección	Dependencias adulteradas	Sigstore/cosign	“Verificación de firmas = obligatorio”
SDKs de terceros inseguros	Tracking o exfiltración	APIs fintech externas	Revisar tráfico	Interceptar API	Exfiltración	Validación SDK	Preguntas sobre SDK → supply chain
Repos externos no confiables	Mirrors inseguros	Instalar desde repos no oficiales	Revisar origen	Paquetes adulterados	Malware	Repos oficiales	Nunca instalar de URL desconocidas
Build scripts vulnerables	Ejecutan código inseguro	Bash de build baja script remoto	Leer pipeline	Inyección	Control total	IaC seguro	Palabras clave: “script remoto”

🧪 Checklist rápida de pentesting A03:2025

• Obtener SBOM o generarlo (Syft, CycloneDX).
• Escanear dependencias con SCA.
• Revisar archivos: package.json, requirements.txt, pom.xml, go.mod.
• Revisar logs del pipeline y GitHub Actions.
• Validar si paquetes se descargan en runtime.
• Escanear contenedores (Trivy, Grype).
• Buscar typosquatting y dependencias desconocidas.
• Verificar si hay paquetes sin mantenimiento.
• Revisar firma digital de paquetes o contenedores.
• Revisar integridad de repos externos.
• Analizar SDKs de terceros (llamadas, endpoints, exfiltración).

🧾 Resumen ejecutivo (para curso o slide)

A03:2025 Fallas en la Cadena de Suministro de Software refleja un riesgo creciente: la mayoría de las aplicaciones modernas dependen de cientos de componentes externos y un solo eslabón débil puede comprometer toda la aplicación. Incluye el uso de dependencias vulnerables, paquetes maliciosos, typosquatting, imágenes de contenedores inseguras, scripts de CI/CD manipulados, SDKs inseguros y falta de verificación de firmas o integridad. La mitigación requiere SBOM, análisis de composición (SCA), verificación de firmas, hardening de pipelines, contenedores mínimos y control estricto de dependencias directas y transitivas. Es un riesgo crítico porque compromete aplicaciones aún cuando el código propio no tiene fallos.

A04:2025 Fallos criptográficos

En este capítulo, A04:2025 Fallos criptográficos – Cryptographic Failures, aprenderás a identificar, comprender y prevenir uno de los riesgos más críticos en la seguridad moderna: los fallos criptográficos. Estos errores no solo implican algoritmos débiles, claves mal gestionadas o datos sin cifrar: representan la línea que separa la confidencialidad de tus usuarios y un desastre absoluto.

A lo largo del contenido verás cómo se rompen los sistemas criptográficos, desde configuraciones TLS inseguras hasta almacenamiento de contraseñas con hashes débiles. Estudiarás ataques reales, vulnerabilidades comunes según CWE, técnicas de explotación utilizadas por atacantes y las mejores prácticas actuales —incluyendo TLS moderno, gestión de claves, uso de bóvedas de secretos, y preparación para la criptografía post-cuántica.

Este capítulo te permitirá comprender no solo la teoría, sino el pensamiento práctico que debe tener un profesional de seguridad, aprendiendo a anticipar fallos, detectarlos y corregirlos antes de que se conviertan en una filtración de datos.

Cuando hablamos de fallos criptográficos, no estamos hablando solo de algoritmos rotos o de que alguien dejó MD5 en un sistema viejo. Estamos hablando de una categoría entera de negligencia, de errores de diseño, de malas decisiones de arquitectura que convierten cualquier aplicación en un objetivo fácil. Y no importa si usás HTTPS o AES-256. Si no entendés cómo, cuándo y por qué usar criptografía, igual vas a quedar expuesto.

Este riesgo —A04:2025— cayó en el ranking, pero no porque se haya vuelto menos importante, sino porque otras categorías subieron por el contexto. Pero los fallos criptográficos siguen ahí, escondidos en cada login mal hecho, en cada base de datos con hashes débiles, en cada token generado con poca entropía, y en cada conexión que usa TLS 1.0 porque “todavía anda”.

La mayoría de las vulnerabilidades de este tipo se agrupan bajo CWE como el uso de algoritmos rotos (CWE-327), entropía insuficiente (CWE-331), generadores de números aleatorios predecibles (CWE-1241, CWE-338), y almacenamiento criptográfico inseguro. ¿El patrón común? Gente usando herramientas potentes sin saber cómo funcionan. Es como si te dieran una Glock y no supieras sacarle el seguro: tarde o temprano, te disparás solo.

Las apps siguen almacenando datos sensibles sin cifrar: contraseñas, tarjetas, historiales médicos, PII, lo que se te ocurra. Y no estoy hablando de sistemas de hace 15 años: estoy hablando de plataformas modernas, donde los desarrolladores siguen metiendo SHA-1 en producción, o donde las contraseñas se guardan como bcrypt(md5(pass)), creyendo que eso es seguro. Hay bases de datos enteras expuestas, rutas que devuelven dumps enteros, y servidores que descifran todo automáticamente sin ningún control. Ni MAC, ni separación de claves, ni nada.

Bajando dos posiciones hasta el n.º 4, esta debilidad se centra en fallos relacionados con la falta de criptografía, criptografía insuficientemente robusta, fuga de claves criptográficas y errores relacionados. Tres de las Enumeraciones de Debilidades Comunes (CWE) más comunes en este riesgo implicaban el uso de un generador de números pseudoaleatorios débil: CWE-327 Uso de un algoritmo criptográfico defectuoso o arriesgado, CWE-331: Entropía insuficiente , CWE-1241: Uso de un algoritmo predecible en un generador de números aleatorios y CWE-338 Uso de un generador de números pseudoaleatorios criptográficamente débil (PRNG) .

El almacenamiento criptográfico inseguro es una vulnerabilidad común que existe cuando los datos confidenciales no se almacenan de forma segura.

Las credenciales de usuario, la información del perfil, los detalles de salud, la información de la tarjeta de crédito, etc. se consideran información confidencial en un sitio web.

Estos datos se almacenarán en la base de datos de la aplicación. Si estos datos se almacenan de forma incorrecta, es decir, sin utilizar cifrado o hash*, serán vulnerables a los atacantes.

(*El hash es la transformación de los caracteres de una cadena en cadenas más cortas de longitud fija o en una clave. Para descifrar la cadena, debe estar disponible el algoritmo utilizado para formar la clave)

Implicación

• Al utilizar esta vulnerabilidad, un atacante puede robar y modificar dichos datos débilmente protegidos para llevar a cabo robos de identidad, fraudes con tarjetas de crédito u otros delitos.

Objetos vulnerables

• Base de datos de la aplicación.

Tabla de puntuación.

CWE mapeados	Tasa máxima de incidencia	Tasa de incidencia promedio	Cobertura máxima	Cobertura promedio	Exploit ponderado promedio	Impacto ponderado promedio	Total de ocurrencias	Total de CVEs
32	13,77%	3,80%	100.00%	47,74%	7.23	3.90	1.665.348	2.185

Descripción.

En general, todos los datos en tránsito deben cifrarse en la capa de transporte ( capa 4 del sistema OSI). Los obstáculos anteriores, como el rendimiento de la CPU y la gestión de claves privadas y certificados, ahora se superan mediante CPU con instrucciones diseñadas para acelerar el cifrado (p. ej., compatibilidad con AES ). La gestión de claves privadas y certificados se simplifica gracias a servicios como LetsEncrypt.org , donde los principales proveedores de servicios en la nube ofrecen servicios de gestión de certificados aún más integrados para sus plataformas específicas.

Además de proteger la capa de transporte, es importante determinar qué datos necesitan cifrado en reposo y cuáles necesitan cifrado adicional en tránsito (en la capa de aplicación , capa 7 del sistema OSI). Por ejemplo, las contraseñas, los números de tarjetas de crédito, los historiales médicos, la información personal y los secretos comerciales requieren protección adicional, especialmente si dichos datos están sujetos a leyes de privacidad, como el Reglamento General de Protección de Datos (RGPD) de la UE o regulaciones como el

Estándar de Seguridad de Datos PCI (PCI DSS). Para todos estos datos:

• ¿Se utilizan algoritmos o protocolos criptográficos antiguos o débiles de forma predeterminada o en códigos más antiguos?
• ¿Se utilizan claves criptográficas predeterminadas, se generan claves criptográficas débiles, se reutilizan las claves o falta una gestión y rotación de claves adecuadas?
• ¿Se registran las claves criptográficas en los repositorios de código fuente?
• ¿No se aplica el cifrado? Por ejemplo, ¿faltan directivas de seguridad o encabezados de encabezados HTTP (navegador)?
• ¿El certificado de servidor recibido y la cadena de confianza están correctamente validados?
• ¿Se ignoran, reutilizan o no se generan los vectores de inicialización con la seguridad suficiente para el modo criptográfico? ¿Se utiliza un modo inseguro como ECB? ¿Se utiliza cifrado cuando el cifrado autenticado es más adecuado?
• ¿Se están utilizando contraseñas como claves criptográficas en ausencia de una función de derivación de claves basada en contraseñas?
• ¿Se utiliza la aleatoriedad con fines criptográficos que no fueron diseñados para cumplir con los requisitos criptográficos? Incluso si se elige la función correcta, ¿debe el desarrollador generarla? Y, de no ser así, ¿ha sobrescrito el desarrollador la potente funcionalidad de generación de semillas integrada con una semilla que carece de suficiente entropía/imprevisibilidad?
• ¿Se utilizan funciones hash obsoletas como MD5 o SHA1, o se utilizan funciones hash no criptográficas cuando se necesitan funciones hash criptográficas?
• ¿Se utilizan métodos de relleno criptográfico obsoletos, como PKCS número 1 v1.5?
• ¿Son explotables los mensajes de error criptográficos o la información del canal lateral, por ejemplo, en forma de ataques de oráculo de relleno?
• ¿Se puede degradar o eludir el algoritmo criptográfico?

Consulte las referencias ASVS: Criptografía (V11), Comunicación segura (V12) y Protección de datos (V14).

Recomendaciones

1. Asegúrese de utilizar algoritmos estándar sólidos y adecuados. No cree sus propios algoritmos criptográficos. Utilice únicamente algoritmos públicos aprobados, como AES, criptografía de clave pública RSA y SHA-256, etc.
2. Asegúrese de que las copias de seguridad externas estén cifradas, pero que las claves se administren y respalden por separado.

Cómo prevenir.

Haga lo siguiente, como mínimo, y consulte las referencias:

• Clasifique y etiquete los datos procesados, almacenados o transmitidos por una aplicación. Identifique qué datos son sensibles según las leyes de privacidad, los requisitos regulatorios o las necesidades del negocio.
• Almacene sus claves más confidenciales en un HSM basado en hardware o en la nube.
• Utilice implementaciones confiables de algoritmos criptográficos siempre que sea posible.
• No almacene datos confidenciales innecesariamente. Deséchelos lo antes posible o utilice tokenización o incluso truncamiento conforme a PCI DSS. Los datos que no se conservan no pueden ser robados.
• Asegúrese de cifrar todos los datos confidenciales en reposo.
• Asegúrese de que existan algoritmos, protocolos y claves estándar sólidos y actualizados; utilice una gestión de claves adecuada.
• Cifre todos los datos en tránsito con protocolos seguros como TLS con cifrados de confidencialidad directa (FS), priorización de cifrado por parte del servidor y parámetros seguros. Aplique el cifrado mediante directivas como la Seguridad de Transporte Estricta HTTP (HSTS).
• Desactive el almacenamiento en caché de las respuestas que contienen datos confidenciales. Esto incluye el almacenamiento en caché en su CDN, servidor web y cualquier aplicación (p. ej., Redis).
• Aplicar los controles de seguridad necesarios según la clasificación de los datos.
• No utilice protocolos no cifrados como FTP y SMTP.
• Almacene contraseñas utilizando funciones de hash adaptativas y con sal robustas con un factor de trabajo (factor de retardo), como Argon2, scrypt, bcrypt (sistemas antiguos) o PBKDF2-HMAC-SHA-256. Para sistemas antiguos que utilizan bcrypt, consulte la Hoja de referencia de OWASP: Almacenamiento de contraseñas.
• Los vectores de inicialización deben seleccionarse de forma adecuada para el modo de operación. Esto podría implicar el uso de un CSPRNG (generador de números pseudoaleatorios criptográficamente seguro). Para los modos que requieren un nonce, el vector de inicialización (IV) no necesita un CSPRNG. En ningún caso, el IV debe utilizarse dos veces para una clave fija.
• Utilice siempre cifrado autenticado en lugar de sólo cifrado.
• Las claves deben generarse criptográficamente de forma aleatoria y almacenarse en memoria como matrices de bytes. Si se utiliza una contraseña, esta debe convertirse en una clave mediante una función adecuada de derivación de claves de base de contraseñas.
• Asegúrese de que la aleatoriedad criptográfica se utilice cuando corresponda y de que no se haya generado de forma predecible ni con baja entropía. La mayoría de las API modernas no requieren que el desarrollador genere el CSPRNG para garantizar su seguridad.
• Evite funciones criptográficas obsoletas, métodos de construcción de bloques y esquemas de relleno, como MD5, SHA1, modo de encadenamiento de bloques de cifrado (CBC), PKCS número 1 v1.5.
• Asegúrese de que las configuraciones y ajustes cumplan con los requisitos de seguridad haciendo que sean revisados ​​por especialistas en seguridad, herramientas diseñadas para este propósito o ambos.
• Considere prepararse para la criptografía post cuántica (PQC), consulte las referencias (ENISA, NIST)

Ejemplos de escenarios de ataque.

Escenario n.° 1 : Un sitio web no utiliza ni aplica TLS en todas sus páginas o admite un cifrado débil. Un atacante monitorea el tráfico de red (p. ej., en una red inalámbrica insegura), degrada las conexiones de HTTPS a HTTP, intercepta las solicitudes y roba la cookie de sesión del usuario. Posteriormente, el atacante reproduce esta cookie y secuestra la sesión del usuario (autenticado), accediendo o modificando sus datos privados. En lugar de lo anterior, podría alterar todos los datos transmitidos, por ejemplo, el destinatario de una transferencia de dinero.

Escenario n.° 2 : La base de datos de contraseñas utiliza hashes simples o sin sal para almacenar las contraseñas de todos. Una falla en la carga de archivos permite a un atacante recuperar la base de datos de contraseñas. Todos los hashes sin sal pueden exponerse mediante una tabla arcoíris de hashes precalculados. Los hashes generados por funciones hash simples o rápidas pueden ser descifrados por GPU, incluso si están con sal.

Ejemplos

En una de las aplicaciones bancarias, la base de datos de contraseñas utiliza hashes sin sal * para almacenar las contraseñas de todos. Una falla de inyección SQL permite al atacante recuperar el archivo de contraseñas. Todos los hashes sin sal se pueden extraer por fuerza bruta en poco tiempo, mientras que las contraseñas con sal tardarían miles de años.

(*Hashes sin sal: la sal es un dato aleatorio que se agrega a los datos originales. La sal se agrega a la contraseña antes de aplicar el hash)

A04:2025 – Fallos Criptográficos (Cryptographic Failures)

Antes llamado “Sensitive Data Exposure”.

En 2025 baja al puesto #4, pero sigue siendo una de las categorías con mayor impacto real, especialmente por fugas de claves, algoritmos débiles, entropía insuficiente y errores en TLS o almacenamiento.

Abarca todo error donde la criptografía se usa mal, no se usa, se configura incorrectamente o se implementa de forma insegura.

🧩 Ejemplos típicos modernos (2025)

• Uso de algoritmos débiles: MD5, SHA1, DES, RC4, RSA < 2048.
• Tokens JWT sin firma, con alg=none, o usando HS256 con claves débiles.
• Insuficiente entropía en generadores de tokens o reset links.
• Claves criptográficas en código fuente o .env.
• TLS mal configurado: TLS 1.0/1.1, curvas inseguras, cipher suites débiles.
• Falta de encriptación en reposo en bases de datos o buckets.
• Contraseñas almacenadas con hashing débil (MD5, SHA1, bcrypt con cost bajo).
• Reutilización de IV o nonces incorrectos.
• PRNG no criptográfico (Math.random, pseudo-randoms de librerías).
• Exposición de claves privadas en repos públicos.
• Envío de datos sensibles sin TLS (o downgrades permitidos).
• Certificados caducados o autofirmados sin validación estricta.

🔍 Mini-guía de explotación (pentesting 2025)

1. Enumerar algoritmos usados en hashing, cifrado y TLS.
2. Probar fuerza bruta sobre hashes débiles (MD5, SHA1).
3. Revisar configuraciones TLS: versiones, cipher suites, curva elíptica.
4. Inspeccionar JWTs con jwt.io → verificar firma, algoritmo y kid.
5. Buscar claves expuestas en:
   • repositorios
   • archivos .env
   • frontends o móviles
   • responses de API
6. Evaluar entropía de tokens de sesión o reset de contraseña.
7. Analizar storage para verificar cifrado en reposo.
8. Intentar downgrade TLS si soporta versiones viejas.
9. Intentar manipular nonces, IV o padding.
10. Verificar uso de PRNG inseguro (Math.random, Random() sin seed seguro).

🎯 Consecuencias

• Robo de cuentas.
• Toma de sesión mediante predicción de tokens.
• Lectura de datos cifrados por implementación insegura.
• Suplantación de usuario mediante JWT inválidos o falsificados.
• Intercepción MITM por TLS débil o downgrade.
• Compromiso de API keys o claves privadas → hack total.
• Exposición masiva de PII, tarjetas, credenciales.
• Firmas digitales falsificadas por claves insuficientes.

🛡 Defensas modernas (2025)

• TLS 1.2+ obligatorio, preferible TLS 1.3.
• Cifrado fuerte:
  • AES-256-GCM
  • RSA >= 3072 bits
  • ECDSA/ECDH con curvas modernas (secp256r1, X25519)
• Hashing de contraseñas:
  • Argon2id (ideal)
  • bcrypt con cost alto (>= 12)
  • PBKDF2 con suficientes iteraciones
• Encriptación en reposo en DB, S3, logs y backups.
• Validación estricta de certificados (no permitir autofirmados).
• JWT con RS256/ES256, nunca HS256 con clave débil.
• Rotación automática de claves (cada 60–90 días).
• PRNG criptográfico (CSPRNG): /dev/urandom, crypto.randomBytes.
• No exponer claves: usar vaults (AWS KMS, GCP KMS, Hashicorp Vault).
• Evitar cifrado casero (“homebrew crypto”).
• Revisiones y pruebas automáticas de criptografía en CI/CD.

📚 Subtipos / patrones modernos (2025)

(siguiendo tu mismo formato tabular)

Subtipo / patrón	Definición	Ejemplo bancario	Pentesting (qué probar)	Ataque / PoC	Consecuencia	Defensa	Tips examen
Algoritmos débiles	Criptografía obsoleta	SHA1 en firma de token	Verificar algoritmos	Colisión MD5/SHA1	Falsificación	AES-GCM/ECDSA	“MD5/SHA1 = inseguro”
Hashing débil	Contraseñas mal protegidas	MD5 con salt fijo	Revisar almacenamiento	Cracking rápido	Robo de cuentas	Argon2/bcrypt	Buscar “hash débil”
JWT inseguro	alg=none, HS256 débil	Token sin firma	Decodificar y verificar firma	Forjar token admin	Escalada total	RS256/ES256	“alg=none” = crítico
Entropía insuficiente	Tokens predecibles	Reset links cortos	Medir entropía	Predecir token	Robo cuenta	CSPRNG	Si tokens cortos = fallo
Claves expuestas	Secretos en código/db	API keys en .env público	Buscar en repos	Usar clave expuesta	Compromiso APIs	KMS/Vault	“API key pública”
TLS débil	Versiones viejas, malos ciphers	TLS 1.0 activo	Inspección SSL	MITM/downgrade	Intercepción	TLS1.3	“TLS viejo = vulnerabilidad”
Falta de cifrado en reposo	Datos plaintext	DB de tarjetas sin cifrar	Revisar storage	Acceso directo a DB	Fuga masiva	AES256 en reposo	Preguntas sobre “at rest”
PRNG no seguro	Random no criptográfico	Math.random()	Revisar código	Predecir tokens	Toma sesión	crypto RNG	“Random malo = inseguro”
IV/Nonce incorrecto	Reutilización de IV	GCM con IV repetido	Revisar implementación	Decrifrado	Acceso datos	GCM con IV aleatorio	Keywords: «nonce reuse»
Certificados inválidos	Autofirmados o vencidos	Cert caducado en banca	Revisar chain	MITM	Robo tráfico	Validación estricta	“Cert autofirmado” red flag

🧪 Checklist rápida de pentesting A04:2025

• Revisar configuración de TLS.
• Decodificar JWTs y verificar firma/algoritmo.
• Buscar claves privadas en repositorios.
• Revisar hashing de contraseñas.
• Analizar entropía de tokens.
• Verificar cifrado en reposo en DB/storage.
• Buscar uso de MD5/SHA1/RC4.
• Revisar PRNG (si es criptográfico o no).
• Revisar certificados y fechas de expiración.
• Revisar IV/nonce usage.
• Auditar configuración de KMS o secreto.

 Resumen ejecutivo para cursos

A04:2025 Fallos Criptográficos se centra en la protección de datos mediante el uso adecuado de algoritmos, claves, protocolos y mecanismos criptográficos. Incluye algoritmos débiles, falta de entropía, tokens mal firmados, claves expuestas, TLS inseguro, certificados inválidos, hashing insuficiente y ausencia de cifrado en reposo. Las consecuencias son severas: robo de cuentas, fugas masivas, intercepción MITM, falsificación de tokens y compromisos completos. La mitigación requiere cifrado fuerte, TLS moderno, gestión segura de claves, hashing seguro de contraseñas, CSPRNG para generación de tokens y verificación de firmas y configuraciones criptográficas como parte del pipeline automatizado. Es una de las categorías con mayor impacto real y uno de los pilares del AppSec.

A05:2025 Inyección

La inyección baja dos puestos, del 3.º al 5.º, en la clasificación, manteniendo su posición respecto a A04:2025-Fallos criptográficos y A06:2025-Diseño inseguro. La inyección es una de las categorías más analizadas, con el 100 % de las aplicaciones analizadas para detectar algún tipo de inyección. Obtuvo el mayor número de CVE de todas las categorías, con 37 CWE en esta categoría. La inyección incluye secuencias de comandos entre sitios (alta frecuencia/bajo impacto) con más de 30 000 CVE e inyección SQL (baja frecuencia/alto impacto) con más de 14 000 CVE. La enorme cantidad de CVE notificados para CWE-79 Neutralización incorrecta de la entrada durante la generación de páginas web («Cross-site Scripting») reduce el impacto medio ponderado de esta categoría.

Tabla de puntuación.

CWE mapeados	Tasa máxima de incidencia	Tasa de incidencia promedio	Cobertura máxima	Cobertura promedio	Exploit ponderado promedio	Impacto ponderado promedio	Total de ocurrencias	Total de CVEs
37	13,77%	3,08%	100.00%	42,93%	7.15	4.32	1.404.249	62.445

Descripción.

Una vulnerabilidad de inyección es una falla del sistema que permite a un atacante insertar código o comandos maliciosos (como código SQL o de shell) en los campos de entrada de un programa, engañando al sistema para que los ejecute como si fueran parte del sistema. Esto puede tener consecuencias realmente graves.

Descripción.

Una vulnerabilidad de inyección es una falla del sistema que permite a un atacante insertar código o comandos maliciosos (como código SQL o de shell) en los campos de entrada de un programa, engañando al sistema para que los ejecute como si fueran parte del sistema. Esto puede tener consecuencias realmente graves.

Una aplicación es vulnerable a ataques cuando:

• Los datos proporcionados por el usuario no son validados, filtrados ni desinfectados por la aplicación.
• Las consultas dinámicas o llamadas no parametrizadas sin escape consciente del contexto se utilizan directamente en el intérprete.
• Los datos no desinfectados se utilizan dentro de los parámetros de búsqueda de mapeo relacional de objetos (ORM) para extraer registros confidenciales adicionales.
• Se utilizan directamente o se concatenan datos potencialmente hostiles. El SQL o comando contiene la estructura y los datos maliciosos en consultas dinámicas, comandos o procedimientos almacenados.

Algunas de las inyecciones más comunes son SQL, NoSQL, comandos del sistema operativo, mapeo relacional de objetos (ORM), LDAP y lenguaje de expresión (EL) u biblioteca de navegación de gráficos de objetos (OGNL). El concepto es idéntico en todos los intérpretes. La detección se logra mejor combinando la revisión del código fuente con pruebas automatizadas (incluyendo fuzzing) de todos los parámetros, encabezados, URL, cookies, JSON, SOAP y datos XML. La incorporación de herramientas de pruebas de seguridad de aplicaciones estáticas (SAST), dinámicas (DAST) e interactivas (IAST) en la canalización de CI/CD también puede ser útil para identificar fallos de inyección antes de la implementación en producción.

Una clase relacionada de vulnerabilidades de inyección se ha vuelto común en los LLM. Estas se analizan por separado en el Top 10 de LLM de OWASP , específicamente LLM01:2025 Inyección rápida .

Cómo prevenir.

La mejor manera de evitar la inyección es mantener los datos separados de los comandos y las consultas:

• La opción preferida es usar una API segura que evite el uso del intérprete por completo, proporcione una interfaz parametrizada o migre a herramientas de mapeo relacional de objetos (ORM). Nota: Incluso con parametrización, los procedimientos almacenados pueden introducir inyección SQL si PL/SQL o T-SQL concatenan consultas y datos o ejecutan datos hostiles con EXECUTE IMMEDIATE o exec().

Cuando no es posible separar los datos de los comandos, puede reducir las amenazas utilizando las siguientes técnicas.

• Utilice la validación de entrada positiva del lado del servidor. Esto no constituye una defensa completa, ya que muchas aplicaciones requieren caracteres especiales, como áreas de texto o API para aplicaciones móviles.
• Para cualquier consulta dinámica residual, escape los caracteres especiales utilizando la sintaxis de escape específica de ese intérprete. Nota: Las estructuras SQL, como nombres de tablas y columnas, no se pueden escapar, por lo que los nombres de estructura proporcionados por el usuario son peligrosos. Este es un problema común en el software de generación de informes.

Advertencia: estas técnicas implican analizar y escapar cadenas complejas, lo que las hace propensas a errores y no robustas frente a cambios menores en el sistema subyacente.

Ejemplos de escenarios de ataque.

Escenario n.° 1: una aplicación utiliza datos no confiables en la construcción de la siguiente llamada SQL vulnerable:

String query = «SELECT \* FROM accounts WHERE custID='» + request.getParameter(«id») + «‘»;

Escenario n.° 2: De manera similar, la confianza ciega de una aplicación en los marcos puede generar consultas que aún sean vulnerables (por ejemplo, Hibernate Query Language (HQL)):

Query HQLQuery = session.createQuery(«FROM accounts WHERE custID='» + request.getParameter(«id») + «‘»);

En ambos casos, el atacante modifica el valor del parámetro ‘id’ en su navegador para enviar: ‘UNION SLEEP(10);–. Por ejemplo:

http://example.com/app/accountView?id=’ UNION SELECT SLEEP(10);–

Esto cambia el significado de ambas consultas para devolver todos los registros de la tabla de cuentas. Ataques más peligrosos podrían modificar o eliminar datos o incluso invocar procedimientos almacenados.

Ejemplos de escenarios de ataque

Una aplicación concatena un parámetro en una consulta: SELECT * FROM accounts WHERE custID=’ + id + ‘. Otra, usando HQL, hace algo equivalente. Si el atacante fija id a ‘> UNION SELECT SLEEP(10);–, cambia el significado de la consulta (p. ej., forzando demoras o extrayendo todo el conjunto de cuentas) mediante una URL como http://example.com/app/accountView?id=’ UNION SELECT SLEEP(10);–. Ataques más agresivos pueden modificar o borrar datos o invocar procedimientos almacenados.

SQL Injection clásico

Supongamos un formulario de login:

String query = «SELECT * FROM users WHERE username = ‘» + user + «‘ AND password = ‘» + pwd + «‘»;

Si el usuario ingresa:

• user = ‘ OR ‘1’=’1
• pwd = algo

La consulta resultante podría volverse:

SELECT * FROM users WHERE username = » OR ‘1’=’1′ AND password = ‘algo’

La condición ‘1’=’1′ siempre es verdadera, por lo que el atacante podría acceder sin credenciales válidas.

Inyección de comandos al sistema

Supongamos una aplicación que ejecuta ping:

ping -c 4 “ + userHost

Si userHost = «8.8.8.8; rm -rf /», entonces el sistema ejecutará primero ping 8.8.8.8 y luego borrará ficheros del servidor. Esa es una forma básica de command injection.

NoSQL Injection

Con una base de datos MongoDB, una consulta típica podría ser:

db.users.find({ username: inputUser, password: inputPass })

Si un atacante envía:

{ «username»: { «$ne»: null }, «password»: { «$ne»: null } }

Ese filtro coincide con todos los registros donde ambos campos no sean nulos, posibilitando un bypass de autenticación.

Inyección en plantillas / lenguaje de expresiones

Si la aplicación permite al usuario definir una parte de la plantilla que incluye una expresión embebida (por ejemplo en frameworks de template que permiten lógica), podría insertar código para ejecutarse en el servidor.

A05:2025 – Injection

(Antes “Injections” en general; agrupa SQLi, NoSQLi, LDAPi, OS Command Injection, Template Injection, Expression Injection, ORM Injection, XPath, CRLF, SMTP, etc.)

En 2025, Injection baja hasta el puesto 5, no porque sea menos peligrosa, sino porque los frameworks modernos bloquean parte de estos ataques por defecto.

Aun así, cuando ocurre → impacto crítico: RCE, robo de datos, movimientos laterales, compromisos totales.

🧩 Ejemplos típicos (2025)

• SQL Injection clásico por concatenación de cadenas.
• NoSQL Injection en MongoDB usando operadores ($ne, $gt, $regex).
• Command Injection via exec(), system(), Runtime.exec().
• Template Injection (SSTI) en engines como Jinja2, Twig, Handlebars.
• LDAP Injection permitiendo manipular filtros.
• LDAP/AD: (&(user=*)(password=*)).
• Server-Side Expression Injection (SpEL, OGNL).
• GraphQL Injection manipulando consultas.
• CLI injection al pasar argumentos a herramientas del SO.
• CRLF Injection → HTTP response splitting.
• Inyección en ORM (inserción de fragmentos SQL en ORMs mal usados).
• XPath/XQuery injection sobre XML.

🔍 Mini-guía de explotación (Pentesting 2025)

1. Buscar concatenaciones de entradas del usuario.
2. Probar payloads simples: ‘ OR 1=1–, » OR «»=», ${{7*7}}.
3. Probar bypass de filtros: encoding, doble codificación, unicode, JSON.
4. Probar DB específicas (MySQL, Postgres, MSSQL, Oracle).
5. En NoSQL usar operadores JSON maliciosos.
6. Forzar errores para ver stack traces o mensajes de DB.
7. Probar función de exportación → sospecha de usage de comandos internos.
8. Probar plantillas enviando payloads SSTI ${{7*7}}.
9. Probar GraphQL alterando queries, fragments y variables.
10. Probar CRLF injection (%0D%0A).
11. Probar OS injection usando ;, |, &&, $(), backticks.
12. Probar LDAP injection con operadores *, )(, (|(user=*)).

🎯 Consecuencias

• Robo de bases de datos completas.
• RCE (por Command Injection o SSTI).
• Escalada de privilegios en servidores.
• Manipulación de autenticación/identidad.
• Deserialización forzada → RCE.
• Bypass de autorización.
• Alteración de lógica de negocio.
• Exfiltración de datos críticos.
• Persistencia en el sistema mediante comandos inyectados.

🛡 Defensas modernas (2025)

• Prepared statements / consultas parametrizadas (obligatorio).
• Validación estricta de entrada (whitelist, no blacklist).
• ORM seguro: evitar concatenar strings en consultas.
• Plantillas seguras que no ejecutan expresiones.
• Sanitización automática para engines de template.
• Escape de datos según contexto (SQL, HTML, XPath, JSON).
• Validación fuerte en JSON para evitar NoSQL injection.
• Deshabilitar funciones peligrosas (eval, exec, system).
• Policies AppArmor/SELinux para limitar impacto.
• Escaneo en pipeline (SAST + DAST + SCA).
• TLS + controles en API Gateway para evitar payloads manipulados.
• Rate limiting + WAF (inyecciones básicas).

📚 Subtipos / Patrones modernos (2025)

(Como en tus tablas anteriores)

Subtipo / patrón	Definición	Ejemplo bancario	Pentesting (qué probar)	Ataque / PoC	Consecuencia	Defensa	Tips examen
SQL Injection	Inyección en queries SQL	Transferencias filtradas	‘ OR 1=1–	Dump DB	Robo total	Prepared stmt	“Concatenación = SQLi”
NoSQL Injection	Inyección en Mongo/NoSQL	Bypass en login	{«user»:{«$ne»:null}}	Login sin password	ATO	Validación JSON	Buscar $ne, $gt
Command Injection	Ejecutar comandos SO	Export de CSV ejecuta SO	;id `	whoami`	RCE	Control total	Sanitizar + no usar exec()
SSTI	Inyección en plantillas	Emails render con Jinja	${{7*7}}	Ejecutar code	RCE	Motores seguros	Payload tipo 7*7
LDAP Injection	Manipular filtros LDAP/AD	Login AD bypass	`*)(	(user=*))`	Enumerar AD	Escalada	Escaped filters
XPath Injection	Manipular consultas XML	Acceso a datos XML	‘ or ‘1’=’1	Leer XML	Exfiltración	Validación	XML = sospechar
GraphQL Injection	Alterar queries	Mutaciones no autorizadas	Cambiar query	Exfiltración	Control API	Depth/Rate limit	Buscar unions, fragments
CRLF Injection	Inyección de headers	Manipular cookies/response	%0D%0ASet-Cookie:	Hijack ses	Split resp	Sanitizar	“HTTP splitting”
ORM Injection	Abusar de ORMs	Query construida mal	order=drop table	SQLi indirecta	RCE/db wipe	Parametrizar	ORMs no son magia
Expression Injection	Eval/OGNL/SpEL	Expresión en header	#{7*7}	Exec code	RCE	Disable expression	Buscar strings OGNL

🧪 Checklist rápida de pentesting A05:2025

• Probar payloads básicos de SQLi.
• Probar JSON malicioso (NoSQL).
• Enviar payloads SSTI ${{7*7}}.
• Buscar concatenaciones en logs o errores.
• Fuzzear parámetros sospechosos.
• Revisar si usan ORMs de forma insegura.
• Probar OS injection con ;, |, $(), backticks.
• Probar LDAP injection con )(.
• Probar GraphQL manipulando queries.
• Revisar headers para CRLF.
• Forzar leaks para encontrar mensajes de error.

🧾 Resumen ejecutivo (para tu curso)

A05:2025 Injection agrupa todas las vulnerabilidades donde una aplicación ejecuta datos del usuario como código o como parte de una instrucción interpretada: SQL, NoSQL, comandos del sistema operativo, plantillas, expresiones, LDAP, XML, GraphQL y más. A pesar de los avances de frameworks modernos, sigue siendo una categoría crítica porque permite robo de bases completas, ejecución remota de código, bypass de autenticación, alteración de lógica y compromisos totales. La mitigación depende de parametrización obligatoria, escape contextual, eliminación de funciones peligrosas, validación estricta de entrada, plantillas seguras y auditoría de pipelines automáticos SAST/DAST/SCA. Injection sigue siendo una de las vulnerabilidades más explotadas en el mundo real.

A06:2025 Diseño inseguro

El Diseño Inseguro baja dos puestos, del 4.º al 6.º, superando a la categoría A02:2025 (Configuración incorrecta de seguridad) y A03:2025 (Fallo en la cadena de suministro de software) .

Esta categoría, introducida en 2021, ha permitido observar mejoras notables en el sector en lo que respecta al modelado de amenazas y un mayor énfasis en el diseño seguro. Esta categoría se centra en los riesgos relacionados con fallos de diseño y arquitectura, con un mayor uso del modelado de amenazas, patrones de diseño seguro y arquitecturas de referencia.

Esto incluye fallos en la lógica de negocio de una aplicación, como la falta de definición de cambios de estado no deseados o inesperados dentro de ella. Como comunidad, debemos ir más allá del «desplazamiento a la izquierda» en el ámbito de la codificación para precodificar actividades como la redacción de requisitos y el diseño de aplicaciones, que son fundamentales para los principios de Seguridad por Diseño (p. ej., véase » Establecer un programa moderno de AppSec: Fase de planificación y diseño «).

Las enumeraciones de debilidad común (CWE) notables incluyen CWE-256: almacenamiento desprotegido de credenciales, CWE-269 administración incorrecta de privilegios, CWE-434 carga sin restricciones de archivo con tipo peligroso, CWE-501: violación del límite de confianza y CWE-522: credenciales insuficientemente protegidas.

Tabla de puntuación.

CWE mapeados	Tasa máxima de incidencia	Tasa de incidencia promedio	Cobertura máxima	Cobertura promedio	Exploit ponderado promedio	Impacto ponderado promedio	Total de ocurrencias	Total de CVEs
39	22,18%	1,86%	88,76%	35,18%	6.96	4.05	729.882	7.647

Descripción.

El diseño inseguro es una categoría amplia que representa diferentes debilidades, expresadas como un diseño de control ineficaz o ausente. No es la causa de las demás diez categorías de riesgo principales. Cabe destacar que existe una diferencia entre el diseño inseguro y la implementación insegura.

Distinguimos entre fallas de diseño y defectos de implementación por una razón: tienen diferentes causas, ocurren en diferentes momentos del proceso de desarrollo y requieren diferentes soluciones. Un diseño seguro puede presentar defectos de implementación que generen vulnerabilidades susceptibles de ser explotadas.

Un diseño inseguro no se puede solucionar con una implementación perfecta, ya que nunca se crearon los controles de seguridad necesarios para defenderse de ataques específicos. Uno de los factores que contribuye al diseño inseguro es la falta de un perfil de riesgos empresariales inherente al software o sistema en desarrollo y, por lo tanto, la imposibilidad de determinar el nivel de seguridad requerido.

Tres partes clave para tener un diseño seguro son:

• Recopilación de requisitos y gestión de recursos
• Creando un diseño seguro
• Tener un ciclo de vida de desarrollo seguro

Requisitos y gestión de recursos

Recopile y negocie con la empresa los requisitos de negocio para una aplicación, incluyendo los requisitos de protección relativos a la confidencialidad, integridad, disponibilidad y autenticidad de todos los activos de datos, así como la lógica de negocio prevista. Considere la exposición de su aplicación y si necesita segregación de usuarios (más allá de los necesarios para el control de acceso). Recopile los requisitos técnicos, incluyendo los de seguridad funcionales y no funcionales. Planifique y negocie el presupuesto que cubra todo el diseño, la construcción, las pruebas y la operación, incluyendo las actividades de seguridad.

Diseño seguro

El diseño seguro es una cultura y metodología que evalúa constantemente las amenazas y garantiza que el código esté diseñado y probado de forma robusta para prevenir métodos de ataque conocidos. El modelado de amenazas debe integrarse en las sesiones de refinamiento (o actividades similares); busque cambios en los flujos de datos y el control de acceso u otros controles de seguridad.

Durante el desarrollo de la historia de usuario, determine el flujo correcto y los estados de fallo, y asegúrese de que las partes responsables e impactadas los comprendan y acuerden. Analice las suposiciones y condiciones para los flujos esperados y de fallo para garantizar que sigan siendo precisos y deseables.

Determine cómo validar las suposiciones e implementar las condiciones necesarias para un comportamiento adecuado. Asegúrese de que los resultados se documenten en la historia de usuario. Aprenda de los errores y ofrezca incentivos positivos para promover mejoras. El diseño seguro no es un complemento ni una herramienta que se pueda añadir al software.

Ciclo de vida del desarrollo seguro

Un software seguro requiere un ciclo de vida de desarrollo seguro, un patrón de diseño seguro, una metodología de trabajo asfaltada, una biblioteca de componentes seguros, herramientas adecuadas, modelado de amenazas y análisis post-mortem de incidentes que se utilizan para mejorar el proceso. Contacte con sus especialistas en seguridad al inicio de un proyecto de software, durante todo el proyecto y para el mantenimiento continuo del software. Considere aprovechar el Modelo de Madurez de Garantía de Software (SAMM) de OWASP para estructurar sus iniciativas de desarrollo de software seguro.

Cómo prevenir.

• Establecer y utilizar un ciclo de vida de desarrollo seguro con profesionales de AppSec para ayudar a evaluar y diseñar controles relacionados con la seguridad y la privacidad.
• Establecer y utilizar una biblioteca de patrones de diseño seguros o componentes de carreteras pavimentadas
• Utilice el modelado de amenazas para partes críticas de la aplicación, como autenticación, control de acceso, lógica empresarial y flujos de claves.
• Integrar lenguaje y controles de seguridad en las historias de usuario
• Integre comprobaciones de plausibilidad en cada nivel de su aplicación (desde el frontend hasta el backend)
• Redacte pruebas unitarias y de integración para validar que todos los flujos críticos sean resistentes al modelo de amenazas. Recopile casos de uso y casos de uso indebido para cada nivel de su aplicación.
• Segregar capas de niveles en las capas del sistema y de la red, según las necesidades de exposición y protección
• Segregar a los inquilinos de forma sólida mediante diseño en todos los niveles

Ejemplos de escenarios de ataque.

Escenario n.° 1: Un flujo de trabajo de recuperación de credenciales podría incluir preguntas y respuestas, lo cual está prohibido por NIST 800-63b, OWASP ASVS y OWASP Top 10. No se puede confiar en las preguntas y respuestas como

prueba de identidad, ya que más de una persona puede conocerlas. Esta funcionalidad debería eliminarse y reemplazarse con un diseño más seguro.

Escenario n.° 2: Una cadena de cines ofrece descuentos por reserva de grupo y tiene un máximo de quince asistentes antes de exigir un depósito. Los atacantes podrían modelar este flujo y comprobar si encuentran un vector de ataque en la lógica de negocio de la aplicación; por ejemplo, reservar seiscientas entradas y todos los cines a la vez en unas pocas solicitudes, lo que causaría una pérdida masiva de ingresos.

Escenario n.° 3: El sitio web de comercio electrónico de una cadena minorista no cuenta con protección contra bots administrados por revendedores que compran tarjetas de video de alta gama para revenderlas en sitios web de subastas. Esto genera una mala publicidad para los fabricantes de tarjetas de video y los propietarios de las cadenas minoristas, además de generar una mala relación con los aficionados que no pueden obtener estas tarjetas a ningún precio. Un diseño antibots cuidadoso y reglas de lógica de dominio, como las compras realizadas a los pocos segundos de estar disponibles, podrían identificar compras no auténticas y rechazar dichas transacciones.

A06:2025 – Diseño Inseguro (Insecure Design)

En 2025, Diseño Inseguro baja del puesto #4 al #6, pero no porque el riesgo haya disminuido, sino porque la industria ha avanzado en modelado de amenazas y arquitecturas seguras.

A06 abarca todo fallo conceptual, no de implementación: lógica de negocio débil, flujos mal pensados, ausencia de reglas, permisos mal definidos, validaciones que “nunca se diseñaron”, arquitecturas que permiten abuso, etc.

No es un bug: es una mala decisión de arquitectura o lógica.

🧩 Ejemplos típicos (2025)

• Flujos que permiten saltarse pasos importantes (ej: completar un pago sin validar fondos).
• Falta de límites o controles de tasa (rate limiting).
• APIs que asumen “que nadie probara eso”.
• Reglas de negocio mal diseñadas (ej: modificar saldo vía API “de prueba”).
• Operaciones críticas sin MFA ni reconfirmación.
• Falta de separación de roles en acciones sensibles.
• Lógica inconsistente: un endpoint valida, otro no.
• Funciones críticas accesibles sin validación secundaria.
• No considerar abuso de funciones legítimas (Business Logic Abuse).
• Sistemas de workflow donde se puede cambiar de estado sin permisos.
• Endpoint que permite subir cualquier archivo sin analizar su tipo real.

🔍 Mini-guía de explotación (Pentesting 2025)

1. Entender la lógica del negocio. Todo está ahí.
2. Buscar qué pasa si haces lo “incorrecto”:
   • saltar pasos
   • repetir pasos
   • invertir flujos
   • mandar parámetros faltantes
3. Manipular estados (“pending” → “approved”).
4. Repetir operaciones idempotentes para duplicar efectos.
5. Abusar funciones legítimas (pago parcial múltiples veces).
6. Ver inconsistencias entre endpoints / políticas.
7. Probar race conditions: simultaneidad y doble-gasto.
8. Manipular permisos en objetos críticos.
9. Cargar archivos y manipular extensiones.
10. Buscar falta de MFA o reconfirmación en operaciones críticas.

🎯 Consecuencias

• Fraude financiero (pagos duplicados, manipulación de saldos).
• Acceso indebido a acciones críticas o peligrosas.
• Manipulación de procesos internos.
• Saltos de flujo que permiten bypass de reglas de seguridad.
• Modificación de estados sin autorización.
• Creación de cuentas privilegiadas.
• Explotación de falta de rate-limiting → DoS o fuerza bruta.
• Abuso funcional sin explotar bugs técnicos.
• Exfiltración mediante flujos de trabajo débiles.

🛡 Defensas modernas (2025)

• Threat Modeling obligatorio (STRIDE, PASTA, LINDDUN) antes de escribir código.
• Documentar reglas de negocio y flujos completos.
• Validar estado/flujo en cada endpoint.
• Rate limiting / anti-automation en funciones críticas.
• Revisión de lógica de negocio por equipos mixtos (Dev + QA + AppSec).
• MFA para operaciones sensibles.
• Checks de autorización por estado (no solo por rol).
• Pruebas automáticas de flujos críticos.
• Asegurar consistencia entre endpoints que hacen lo mismo.
• Seguridad por diseño: “Si no está prohibido explícitamente, estará permitido accidentalmente.”

📚 Subtipos / Patrones modernos (2025)

Subtipo / patrón	Definición	Ejemplo bancario	Pentesting (qué probar)	Ataque / PoC	Consecuencia	Defensa	Tips examen
Business Logic Abuse	Abusar funciones legítimas	Transferir $0.01 infinitas veces	Probar multi-acciones	Duplicar transacciones	Fraude	Validación de reglas	“No es bug técnico”
Missing Step Validation	Falta validar etapas	Saltar validación de saldo	Saltar pasos	Pago sin fondos	Pérdida $	Validaciones por estado	Buscar flujos incompletos
Role/State Mismatch	Permisos por estado mal definidos	Aprobación de crédito sin rol	Cambiar estado	Forzar “approved”	Autorización rota	RBAC + ABAC	Mirar estados JSON
Weak MFA on critical ops	Sin MFA en funciones críticas	Cambiar CBU sin revalidación	Probar sin MFA	Secuestrar cuentas	Modificación crítica	MFA contextual	MFA en cambios clave
Workflow Manipulation	Cambiar estado vía API	Ticket pasa a “closed” sin permiso	Mandar PATCH	Saltar proceso	Manipulación interna	Validar transición	“Pending → approved = fallo”
Lógica inconsistente	Un endpoint valida, otro no	/v1/pay valida, /v1/pay2 no	Comparar endpoints	Bypass	Fraude	Uniformidad	Revisar versiones API
File Upload without rules	Subida sin controles	Cargar ejecutable renombrado	Cambiar MIME/ext	RCE/DoS	Toma de server	Validación MIME	Buscar upload “libre”
Rate Limit inexistente	No limitar solicitudes	Intentos ilimitados login	Fuerza bruta	ATO	Lockout/rate limit	“Si no hay límites → inseguro”
Race Condition	Condición de carrera	Doble transferencia	Flood simultáneo	Doble gasto	Pérdidas $	Locks transaccionales	Probar varias requests
Insecure Defaults in Design	Suposiciones erróneas	API abierta “para testing”	Revisar config	Acceso excesivo	Exposición	Diseño seguro	“Default = deny”

🧪 Checklist rápida de pentesting A06:2025

• Analizar flujos completos (inicio → fin).
• Probar saltar etapas.
• Probar revertir etapas.
• Probar repetir etapas.
• Probar endpoints alternativos para misma acción.
• Testear race conditions.
• Testear rate limiting.
• Testear abusos funcionales.
• Revisar consistencia entre roles, estados y acciones.
• Revisar validación de estado en endpoints críticos.
• Abuse de workflows: transiciones ilegales de estado.

🧾 Resumen ejecutivo para cursos

A06:2025 Diseño Inseguro engloba fallas que no provienen de errores de programación sino de decisiones de arquitectura, lógica de negocio o flujos mal definidos. Es un problema estructural que permite fraude, saltos de lógica, manipulación de estados, abusos funcionales y acceso a operaciones críticas sin controles adecuados. Prevenirlo requiere modelado de amenazas desde el inicio, validación estricta de flujos, controles por estado, MFA contextual, consistencia en endpoints y limitación de abuso funcional. Esta categoría refleja que el software moderno no se quiebra solo por bugs, sino por malas decisiones conceptuales.

A07:2025 Errores de autenticación

Fallos de autenticación mantiene su posición número 7 con un ligero cambio de nombre para reflejar con mayor precisión las 36 CWE de esta categoría. A pesar de las ventajas de los marcos estandarizados, esta categoría ha mantenido su puesto número 7 desde 2021. Entre las CWE más destacadas se incluyen CWE-259: Uso de contraseñas codificadas , CWE-297: Validación incorrecta de certificado con discrepancia de host , CWE-287: Autenticación incorrecta , CWE-384: Fijación de sesión y CWE-798: Uso de credenciales codificadas.

Tabla de puntuación.

CWE mapeados	Tasa máxima de incidencia	Tasa de incidencia promedio	Cobertura máxima	Cobertura promedio	Exploit ponderado promedio	Impacto ponderado promedio	Total de ocurrencias	Total de CVEs
36	15,80%	2,92%	100.00%	37,14%	7.69	4.44	1.120.673	7.147

Descripción.

Cuando un atacante logra engañar a un sistema para que reconozca a un usuario inválido o incorrecto como legítimo, se presenta esta vulnerabilidad. Puede haber vulnerabilidades de autenticación si la aplicación:

• Permite ataques automatizados como el robo de credenciales, donde el atacante obtiene una lista vulnerada de nombres de usuario y contraseñas válidos. Recientemente, este tipo de ataque se ha ampliado para incluir ataques híbridos de contraseñas (también conocidos como ataques de rociado de contraseñas), donde el atacante utiliza variaciones o incrementos de credenciales robadas para obtener acceso, por ejemplo, probando «Contraseña1!», «Contraseña2!», «Contraseña3!», etc.
• Permite ataques de fuerza bruta u otros ataques automatizados y programados que no se bloquean rápidamente.
• Permite contraseñas predeterminadas, débiles o conocidas, como «Contraseña1» o el nombre de usuario «admin» con una contraseña «admin».
• Permite a los usuarios crear nuevas cuentas con credenciales que ya se sabe que han sido violadas.
• Permite el uso de procesos de recuperación de credenciales débiles o ineficaces y de contraseña olvidada, como «respuestas basadas en conocimiento», que no se pueden hacer seguras.
• Utiliza almacenes de datos de contraseñas de texto simple, cifradas o con algoritmos hash débiles (consulte A02:2021-Fallos criptográficos ).
• Tiene autenticación multifactor faltante o ineficaz.
• Permite el uso de alternativas débiles o ineficaces si la autenticación multifactor no está disponible.
• Expone el identificador de sesión en la URL, un campo oculto u otra ubicación insegura a la que puede acceder el cliente.
• Reutiliza el mismo identificador de sesión después de un inicio de sesión exitoso.
• No invalida correctamente las sesiones de usuario o los tokens de autenticación (principalmente tokens de inicio de sesión único (SSO)) durante el cierre de sesión o un período de inactividad.

Cómo prevenir.

• Siempre que sea posible, implemente y haga cumplir el uso de autenticación multifactor para evitar el relleno automatizado de credenciales, la fuerza bruta y los ataques de reutilización de credenciales robadas.
• Siempre que sea posible, fomente y habilite el uso de administradores de contraseñas para ayudar a los usuarios a tomar mejores decisiones.
• No envíe ni implemente con credenciales predeterminadas, especialmente para usuarios administradores.
• Implemente verificaciones de contraseñas débiles, como probar contraseñas nuevas o modificadas comparándolas con la lista de las 10 000 peores contraseñas.
• Durante la creación de una nueva cuenta y los cambios de contraseña, valide con listas de credenciales violadas conocidas (por ejemplo: usando haveibeenpwned.com ).
• Alinee las políticas de longitud, complejidad y rotación de contraseñas con las pautas 800-63b del Instituto Nacional de Estándares y Tecnología (NIST) en la sección 5.1.1 para secretos memorizados u otras políticas de contraseñas modernas basadas en evidencia.
• No obligue a las personas a rotar sus contraseñas a menos que sospeche una vulneración. Si sospecha una vulneración, fuerce el restablecimiento de las contraseñas inmediatamente.
• Asegúrese de que las rutas de registro, recuperación de credenciales y API estén reforzadas contra ataques de enumeración de cuentas mediante el uso de los mismos mensajes para todos los resultados («Nombre de usuario o contraseña no válidos»).
• Limite o retrase cada vez más los intentos fallidos de inicio de sesión, pero tenga cuidado de no crear un escenario de denegación de servicio. Registre todos los fallos y alerte a los administradores cuando se detecten o sospechen ataques de robo de credenciales, fuerza bruta u otros.
• Utilice un gestor de sesiones integrado, seguro y del lado del servidor que genere un nuevo ID de sesión aleatorio con alta entropía tras el inicio de sesión. Los identificadores de sesión no deben estar en la URL, deben almacenarse de forma segura en una cookie segura y se invalidan tras el cierre de sesión, inactividad y tiempos de espera absolutos.
• Lo ideal es utilizar un sistema prediseñado y confiable para gestionar la autenticación, la identidad y la gestión de sesiones. Transfiera este riesgo siempre que sea posible adquiriendo y utilizando un sistema robusto y bien probado.

Ejemplos de escenarios de ataque.

Escenario n.° 1: El robo de credenciales, el uso de listas de combinaciones conocidas de nombre de usuario y contraseña, es ahora un ataque muy común. Recientemente, se ha descubierto que los atacantes incrementan o ajustan las contraseñas basándose en el comportamiento humano común. Por ejemplo, cambian «Winter2025» por «Winter2026», o «ILoveMyDog6» por «ILoveMyDog7» o «ILoveMyDog5». Este ajuste de los intentos de contraseña se denomina ataque híbrido de robo de credenciales o ataque de rociado de contraseñas, y puede ser incluso más efectivo que la versión tradicional. Si una aplicación no implementa defensas contra amenazas automatizadas (fuerza bruta, scripts o bots) o robo de credenciales, puede utilizarse como un oráculo de contraseñas para determinar si las credenciales son válidas y obtener acceso no autorizado.

Escenario n.° 2: La mayoría de los ataques de autenticación exitosos se producen debido al uso continuo de contraseñas como único factor de autenticación. Una vez consideradas las mejores prácticas, la rotación de contraseñas y los requisitos de complejidad incitan a los usuarios a reutilizar contraseñas y a usar contraseñas débiles. Se recomienda a las organizaciones que cesen estas prácticas según la norma NIST 800-63 y que apliquen la autenticación multifactor en todos los sistemas importantes.

Escenario n.° 3: Los tiempos de espera de las sesiones de las aplicaciones no se implementan correctamente. Un usuario usa un ordenador público para acceder a una aplicación y, en lugar de seleccionar «cerrar sesión», simplemente cierra la pestaña del navegador y se retira.

Otro ejemplo es si una sesión de inicio de sesión único (SSO) no se puede cerrar con un cierre de sesión único (SLO). Es decir, un solo inicio de sesión inicia sesión, por ejemplo, en su lector de correo, su sistema de documentos y su sistema de chat. Sin embargo, el cierre de sesión solo se produce en el sistema actual.

Si un atacante usa el mismo navegador después de que la víctima crea haber cerrado sesión correctamente, pero con el usuario aún autenticado en algunas aplicaciones, puede acceder a su cuenta. El mismo problema puede ocurrir en oficinas y empresas cuando una aplicación sensible no se ha cerrado correctamente y un compañero tiene acceso (temporal) al ordenador desbloqueado.

A07:2025 – Fallos de Identificación y Autenticación (Identification & Authentication Failures)

Antes conocido como Broken Authentication.

En 2025 sigue siendo una categoría crítica porque la identidad digital es el eje de cualquier aplicación moderna.

Falla todo lo que permita suplantar usuarios, evitar autenticación, manipular sesiones o romper MFA.

Incluye errores en sesiones, contraseñas, MFA, tokens, gestión de identidad y flujos de login.

🧩 Ejemplos típicos (2025)

• Logins sin MFA en operaciones críticas.
• Tokens JWT sin validación correcta, firma débil o expiración excesiva.
• Sesiones sin rotación tras login o cambio de clave.
• Sesiones predecibles o sin protección contra hijacking.
• Recuperación de contraseña insegura / tokens débiles.
• Reutilización de tokens de reset múltiples veces.
• Falta de limitación de intentos en login (fuerza bruta).
• Contraseñas almacenadas sin hashing adecuado.
• Parámetros ocultos para “impersonación” no validados.
• Falta de validación adecuada en SSO (OpenID Connect / OAuth).
• Validación débil del “state”/“nonce” en OAuth → CSRF/OAuth hijack.
• Sesiones enviadas vía HTTP sin Secure o sin HttpOnly.

🔍 Mini-guía de explotación (pentesting 2025)

1. Probar bypass de login (tokens viejos, endpoints alternativos, mobile/legacy).
2. Enumerar tokens JWT → verificar alg, firma, expiración.
3. Forzar errores en flujo OAuth → comprobar validación de state, nonce.
4. Probar fuerza bruta si no hay límites o captcha.
5. Ver si el login alternativo (v2, mobile) salta controles.
6. Intentar session fixation:
   • iniciar sesión con cookie previa
   • observar si rota la sesión
7. Ver si las sesiones son predecibles o sin expiración.
8. Probar flujos de recuperación de contraseña:
   • tokens cortos
   • links sin expiración real
   • tokens reutilizables
9. Probar impersonación
   • parámetros “user_id” ocultos
   • endpoints de “login as…” expuestos
10. Inyectar parámetros en SSO para validar OIDC/OAuth.

🎯 Consecuencias

• Toma de cuentas (Account Takeover, ATO).
• Robo de identidad.
• Modificación de datos sensibles sin autenticación adecuada.
• Escalada de privilegios (impersonación).
• Acceso persistente usando tokens no expirados.
• Secuestro de sesión mediante hijacking.
• Fraude financiero y transferencia de fondos.
• Compromiso total en servicios críticos (SSO).

🛡 Defensas modernas (2025)

• MFA obligatorio para login y operaciones sensibles.
• JWT con RS256/ES256, expiraciones cortas y rotación.
• Validación estricta de:
  • iss
  • aud
  • exp
  • firma
  • kid
• Rotación obligatoria de sesión tras login y tras cambio de clave.
• Rate limiting + captcha anti-fuerza bruta.
• Hash seguro de contraseñas: Argon2id / bcrypt cost alto.
• Deshabilitar endpoints alternativos o mantenerlos coherentes.
• Session cookie con HttpOnly, Secure, SameSite=Strict.
• Revalidación de identidad para operaciones críticas.
• Validación estricta del flujo OAuth/OIDC (state/nonce).
• Sesiones cortas y expiración forzada.
• Proteger flujos de recuperación → tokens fuertes, uso único.

📚 Subtipos / patrones modernos (2025)

Subtipo / patrón	Definición	Ejemplo bancario	Pentesting (qué probar)	Ataque / PoC	Consecuencia	Defensa	Tips examen
Password Weakness	Contraseñas débiles o sin límite	Login sin rate-limit	Fuerza bruta	Login exitoso	ATO	Rate limit + MFA	“Sin límites = inseguro”
Weak Session Management	Sesión sin rotación ni flags	Cookie sin Secure	Session fixation	Secuestro	Hijack	Rotar + flags	Buscar HttpOnly
JWT Misuse	Firma débil / alg=none	Token HS256 con clave corta	Modif. token	Escalada total	Impersonación	RS256	Keyword: “HS256 débil”
OAuth/OIDC Misconfig	Validación débil del flujo	state no verificado	Manipular callback	Login como otro	Compromiso SSO	Validar state/nonce	Atención a SSO
Weak MFA	MFA inconsistente o opcional	Cambiar CBU sin MFA	Intentar bypass	Secuestro	Robo fondos	MFA robusta	Buscar “critical ops” sin MFA
Weak Password Reset	Tokens débiles o reusables	Reset link sin expirar	Reusar link	Reset sin dueño	ATO	Tokens fuertes	Revisar expiración
User Impersonation Flaws	Impersonar usuarios por parámetro	?user_id=123	Cambiar user_id	ATO	Escalada	Revalidar AuthZ	“user_id en request”
Token Reuse	Tokens que no expiran	Tokens de meses	Reusar tokens	ATO persistente	Persistencia	Rotación	“Exp larga = peligro”
Missing Logout / revocation	No invalidar tokens	Logout no invalida	Probar token viejo	Sesión activa	Secuestro	Revocación	Ver listado de tokens
Insecure Challenge Flows	Preguntas débiles	Preguntas triviales	Probar bypass	ATO	Robo	MFA real	“pregunta secreta” = peligro

🧪 Checklist rápida de pentesting A07:2025

• Revisar si hay rate limiting en login.
• Revisar almacenamiento y hashing de contraseñas.
• Decodificar JWTs y validar firmas/algoritmos.
• Ver si hay endpoints alternativos para login (/mobile/login).
• Probar reuso de tokens de reset.
• Probar impersonación con parámetros (user_id, email).
• Revisar expiración real de tokens y sesiones.
• Revisar validación de OAuth/OIDC (state, nonce).
• Revisar flags de cookies (HttpOnly, Secure, SameSite).
• Ver si la sesión rota tras login.
• Probar bypass de MFA en operaciones sensibles.
• Probar session fixation.

🧾 Resumen ejecutivo para cursos

A07:2025 Fallos de Identificación y Autenticación incluye todas las debilidades que permiten a un atacante asumir la identidad de otro usuario: contraseñas débiles, flujos de login sin límites, hashing deficiente, sesiones sin rotación, JWT mal firmados, OAuth mal configurado, tokens de recuperación inseguros y fallos de MFA. Es una categoría crítica porque permite Account Takeover, secuestro de sesiones, escalada de privilegios y fraude. La mitigación exige MFA, controles estrictos en sesiones, validación correcta de JWT/OAuth, rate limiting, hashing moderno y protección de flujos sensibles. La identidad es la primera línea de defensa: si falla, todo el sistema cae.

A08:2025 Fallas de integridad de software o datos

Las fallas de integridad de software o datos continúan en el puesto n.° 8, con un ligero cambio de nombre, aclaratorio, de «Fallas de integridad de software y datos». Esta categoría se centra en la incapacidad de mantener los límites de confianza y verificar la integridad del software, el código y los artefactos de datos a un nivel inferior al de las fallas de la cadena de suministro de software. Esta categoría se centra en realizar suposiciones relacionadas con actualizaciones de software y datos críticos, sin verificar su integridad. Entre las Enumeraciones de Debilidades Comunes (CWE) más destacadas se incluyen CWE-829: Inclusión de funcionalidad de una esfera de control no confiable , CWE-915: Modificación controlada incorrectamente de atributos de objetos determinados dinámicamente y CWE-502: Deserialización de datos no confiables .

Tabla de puntuación.

CWE mapeados	Tasa máxima de incidencia	Tasa de incidencia promedio	Cobertura máxima	Cobertura promedio	Exploit ponderado promedio	Impacto ponderado promedio	Total de ocurrencias	Total de CVEs
14	8,98%	2,75%	78,52%	45,49%	7.11	4.79	501.327	3.331

Descripción.

Las fallas de integridad de software y datos se relacionan con código e infraestructura que no protegen contra código o datos no válidos o no confiables que se consideran confiables y válidos. Un ejemplo de esto es cuando una aplicación depende de complementos, bibliotecas o módulos de fuentes, repositorios y redes de entrega de contenido (CDN) no confiables.

Una canalización de CI/CD insegura que no consume ni proporciona comprobaciones de integridad de software puede generar acceso no autorizado, código inseguro o malicioso, o comprometer el sistema. Otro ejemplo de esto es una CI/CD que extrae código o artefactos de ubicaciones no confiables o no los verifica antes de su uso (mediante la comprobación de la firma o un mecanismo similar).

Por último, muchas aplicaciones ahora incluyen la función de actualización automática, donde las actualizaciones se descargan sin una verificación de integridad suficiente y se aplican a la aplicación que antes era confiable. Los atacantes podrían potencialmente cargar sus propias actualizaciones para que se distribuyan y ejecuten en todas las instalaciones. Otro ejemplo es cuando los objetos o datos se codifican o serializan en una estructura que un atacante puede ver y modificar, lo que es vulnerable a la deserialización insegura.

Cómo prevenir.

• Utilice firmas digitales o mecanismos similares para verificar que el software o los datos provienen de la fuente esperada y no han sido alterados.
• Asegúrese de que las bibliotecas y dependencias, como npm o Maven, solo utilicen repositorios de confianza. Si su perfil de riesgo es mayor, considere alojar un repositorio interno de confianza y verificado.
• Asegúrese de que exista un proceso de revisión de los cambios de código y configuración para minimizar la posibilidad de que se introduzcan códigos o configuraciones maliciosos en su flujo de trabajo de software.
• Asegúrese de que su canalización de CI/CD tenga la segregación, la configuración y el control de acceso adecuados para garantizar la integridad del código que fluye a través de los procesos de compilación e implementación.
• Asegúrese de que no se reciban datos serializados sin firmar o sin cifrar de clientes no confiables y que posteriormente se utilicen sin algún tipo de verificación de integridad o firma digital para detectar alteraciones o reproducción de los datos serializados.

Ejemplos de escenarios de ataque.

Escenario n.° 1: Inclusión de funcionalidad web de una fuente no confiable: Una empresa utiliza un proveedor de servicios externo para brindar soporte. Para mayor comodidad, cuenta con una asignación DNS para [ myCompany.SupportProvider.comnombre del dominio support.myCompany.com]. Esto significa que todas las cookies, incluidas las de autenticación, configuradas en el myCompany.comdominio se enviarán al proveedor de soporte. Cualquiera con acceso a la infraestructura del proveedor de soporte puede robar las cookies de todos los usuarios que hayan visitado su sitio support.myCompany.comy realizar un ataque de secuestro de sesión.

Escenario n.° 2: Actualización sin firma: Muchos routers domésticos, decodificadores, firmware de dispositivos y otros no verifican las actualizaciones mediante firmware firmado. El firmware sin firmar es un objetivo cada vez mayor para los atacantes y se prevé que empeore. Esto es una gran preocupación, ya que muchas veces no hay otra solución que corregirlo en una versión futura y esperar a que las versiones anteriores queden obsoletas.

Escenario n.° 2: Un desarrollador tiene problemas para encontrar la versión actualizada del paquete que busca, por lo que la descarga en lugar del gestor de paquetes habitual y de confianza, sino de un sitio web. El paquete no está firmado, por lo que no es posible garantizar su integridad. El paquete incluye código malicioso.

Escenario n.° 3: Deserialización insegura: Una aplicación React invoca un conjunto de microservicios de Spring Boot. Como programadores funcionales, intentaron garantizar la inmutabilidad de su código. La solución que idearon fue serializar el estado del usuario y transferirlo con cada solicitud. Un atacante detecta la firma del objeto Java «rO0» (en base64) y utiliza el escáner de deserialización de Java para ejecutar código remoto en el servidor de aplicaciones.

A08:2025 – Fallos en la Integridad de Datos y Software

Esta categoría aparece cuando la aplicación confía ciegamente en datos, actualizaciones, integraciones o sistemas externos sin verificar su integridad o procedencia.

Incluye: manipulación de datos, integridad rota en pipelines, encabezados inseguros, repositorios externos, CI/CD comprometido, cargas de archivos mal validadas, deserialización insegura, actualizaciones sin firma y abuso de metadatos. Es crítica porque se rompe el fundamento más básico: “lo que recibo es lo que espero”.

🧩 Ejemplos típicos (2025)

• Deserialización insegura en JSON, XML, Pickle, Java, PHP, .NET.
• Archivos subidos sin verificación real de tipo o integridad.
• Pipeline CI/CD que descarga scripts o paquetes sin verificar firma.
• Actualizaciones de software sin firma criptográfica.
• Manipulación de datos en tránsito sin integridad (faltan MAC/HMAC).
• Firmas de documentos o tokens sin validación correcta.
• Parámetros de integridad no validados en APIs (hash, signature).
• Dependencias externas cargadas en runtime sin validación.
• Falta de controles en Webhooks o colas de mensajes.
• Aplicación que confía en encabezados controlados por el cliente (X-User, X-Role).
• Falta de atomicidad en operaciones críticas (race conditions).
• Configuración o firmware de IoT sin firma.

🔍 Mini-guía de explotación (pentesting 2025)

1. Probar deserialización enviando payloads controlados.
2. Manipular archivos subidos: cambiar extensión, MIME, contenido interno.
3. Interceptar datos en tránsito → verificar si la integridad está protegida.
4. Alterar parámetros sensibles:
   • amount, balance, price, role, status
5. Probar el uso de encabezados falsificados (X-User: admin).
6. Probar payloads en webhooks o colas con datos manipulados.
7. Verificar si el software o contenedores se actualizan sin firma.
8. Inyectar datos en pipelines CI/CD.
9. Editar JSON/requests para forzar estados incoherentes.
10. Probar race conditions para romper atomicidad.

🎯 Consecuencias

• Manipulación total de datos (saldo, precios, inventario).
• RCE por deserialización insegura.
• Inyección de código o paquetes maliciosos.
• Compromiso de pipelines CI/CD.
• Actualizaciones maliciosas o backdoors instalados sin detección.
• Elevación de privilegios mediante encabezados falsificados.
• Corrupción de datos críticos o estados inválidos.
• Violación de integridad en procesos internos y auditorías.

🛡 Defensas modernas (2025)

• Verificación de integridad:
  • HMAC, firmas digitales, checksum SHA-256/512.
• Validación estricta de archivos:
  • tamaño, magic numbers, MIME real, sandboxing.
• Deserializar solo formatos seguros (JSON estricto; evitar objetos complejos).
• Nunca deserializar objetos arbitrarios del cliente.
• CI/CD seguro:
  • verificar firmas
  • evitar código externo en runtime
  • runners aislados
• Validación estricta de webhooks y colas con firmas.
• Validar encabezados sensibles del lado del servidor (no confiar en el cliente).
• Atomicidad en operaciones críticas (transacciones).
• Verificación de integridad en firmware/actualizaciones.
• Políticas “deny-by-default” para cualquier dato sin procedencia clara.

📚 Subtipos / patrones modernos (2025)

Subtipo / patrón	Definición	Ejemplo bancario	Pentesting (qué probar)	Ataque / PoC	Consecuencia	Defensa	Tips examen
Deserialización insegura	Ejecutar objetos maliciosos	Procesar XML/PHP/Java	Enviar payload	RCE	Control total	JSON seguro	“Deserializar = peligro”
Upload sin validación	Archivos manipulados	Subir PDF → .php	Cambiar MIME	RCE/File abuse	Toma servidor	Validación MIME	Revisar magic bytes
Encabezados confiados	App confía en headers cliente	X-Role: admin	Enviar headers falsos	Escalada	Impersonación	Ignorar headers	Revisar WAF/GW
Integridad rota	Datos sin HMAC o firma	Modificar amount	Cambiar valores	Fraude	Manipulación	HMAC	Preguntas sobre “tampering”
CI/CD inseguro	Pipeline sin firmas	Build descarga script	Alterar URL	Backdoor	Compromiso total	Firmas/COSIGN	Buscar “script remoto”
Firmware/updates sin firma	Actualización manipulable	ATM/PoS update inseguro	Cambiar firmware	Backdoor	Fraude masivo	Secure Boot	IoT sin firma = fallo
Race conditions	Operaciones no atómicas	Doble débito	Enviar reqs simultáneas	Doble gasto	Pérdida $	Locks	Race = integridad
JSON tampering	Parámetros críticos alterados	balance, status	Cambiar JSON	Alterar datos	Fraude	Validar campos	“Precio oculto”
Webhooks inseguros	Sin firma/verificación	Payment success webhook	Falsificar POST	Confirmar pago falso	Fraude	Validar firma	Buscar X-Signature
Repos externos inseguros	Confianza ciega	Descarga lib externa	Cambiar URL	Inyección	Compromiso	Firmas	External = riesgo

🧪 Checklist rápida de pentesting A08:2025

• Buscar deserialización en endpoints (XML, PHP, Java, Pickle, .NET).
• Probar uploads con múltiples extensiones.
• Validar magic bytes y MIME real.
• Enviar headers falsificados.
• Manipular parámetros sensibles (price, status, role).
• Probar alteración de webhooks.
• Revisar si pipelines descargan código externo.
• Verificar que updates/firmware tengan firma válida.
• Simular race conditions.
• Alterar JSON para romper integridad.
• Explorar colas de mensajes (SQS, Kafka, Redis).
• Verificar HMAC o signatures en cada request sensible.

🧾 Resumen ejecutivo para tu curso

A08:2025 Fallos en la Integridad de Datos y Software ocurre cuando una aplicación confía en datos, archivos, actualizaciones, encabezados, integraciones o pipelines sin verificar su integridad o autenticidad. Esto permite manipulación de datos, ejecución remota de código, alteración de estados, fraude, compromisos completos en CI/CD, carga de archivos maliciosos y actualizaciones adulteradas. La mitigación depende de verificación de firmas, HMAC, validación estricta de archivos, transacciones atómicas, deserialización segura, pipelines robustos y estricta validación del origen de cada dato. Si se rompe la integridad, se rompe el corazón del sistema.

A09:2025 Errores de registro y alertas

Los fallos de registro y alertas mantienen su puesto número 9. Esta categoría ha cambiado ligeramente de nombre para enfatizar la función de alerta necesaria para inducir la acción sobre eventos de registro relevantes. Esta categoría siempre estará subrepresentada en los datos y, por tercera vez, ha sido incluida en la lista por los participantes de la encuesta de la comunidad. Esta categoría es extremadamente difícil de probar y tiene una representación mínima en los datos de CVE/CVSS (solo 723 CVE); sin embargo, puede tener un gran impacto en la visibilidad, las alertas de incidentes y el análisis forense. Esta categoría incluye problemas con la correcta gestión de la codificación de salida a archivos de registro (CWE-117), la inserción de datos confidenciales en archivos de registro (CWE-532) y el registro insuficiente (CWE-778).

Tabla de puntuación.

CWE mapeados	Tasa máxima de incidencia	Tasa de incidencia promedio	Cobertura máxima	Cobertura promedio	Exploit ponderado promedio	Impacto ponderado promedio	Total de ocurrencias	Total de CVEs
5	11,33%	3,91%	85,96%	46,48%	7.19	2.65	260.288	723

Descripción.

Sin registro ni monitorización, no se pueden detectar ataques ni infracciones, y sin alertas es muy difícil responder con rapidez y eficacia ante un incidente de seguridad. La insuficiencia de registro, monitorización continua, detección y alertas para iniciar respuestas activas ocurre en cualquier momento:

• Los eventos auditables, como inicios de sesión, inicios de sesión fallidos y transacciones de alto valor, no se registran o se registran de manera inconsistente (por ejemplo, solo se registran los inicios de sesión exitosos, pero no los intentos fallidos).
• Las advertencias y los errores no generan mensajes de registro, estos son inadecuados o poco claros.
• La integridad de los registros no está protegida adecuadamente contra manipulaciones.
• Los registros de aplicaciones y API no se monitorean para detectar actividad sospechosa.
• Los registros solo se almacenan localmente y no se realizan copias de seguridad adecuadas.
• No se han establecido umbrales de alerta adecuados ni se han implementado procesos de escalamiento de respuestas eficaces. Las alertas no se reciben ni se revisan en un plazo razonable.
• Las pruebas de penetración y los análisis realizados mediante herramientas de pruebas de seguridad de aplicaciones dinámicas (DAST) (como Burp o ZAP) no activan alertas.
• La aplicación no puede detectar, escalar ni alertar sobre ataques activos en tiempo real o casi en tiempo real.
• Usted es vulnerable a la fuga de información confidencial si hace que los eventos de registro y alerta sean visibles para un usuario o un atacante (consulte A01:2025-Broken Access Control ) o si registra información confidencial que no debería registrarse (como PII o PHI).
• Usted es vulnerable a inyecciones o ataques a los sistemas de registro o monitoreo si los datos de registro no están codificados correctamente.
• La aplicación no detecta o no gestiona correctamente los errores y otras condiciones excepcionales, por lo que el sistema no sabe que hubo un error y, por lo tanto, no puede registrar que hubo un problema.
• Faltan ‘casos de uso’ adecuados para emitir alertas o están desactualizados para reconocer una situación especial.
• Demasiadas alertas falsas positivas hacen que sea imposible distinguir las alertas importantes de las que no lo son, y como resultado, se las reconoce demasiado tarde o no se las reconoce en absoluto (sobrecarga física del equipo SOC).
• Las alertas detectadas no se pueden procesar correctamente porque el manual para el caso de uso está incompleto, desactualizado o falta.

Cómo prevenir.

Los desarrolladores deben implementar algunos o todos los siguientes controles, según el riesgo de la aplicación:

• Asegúrese de que todos los fallos de inicio de sesión, control de acceso y validación de entrada del lado del servidor se puedan registrar con suficiente contexto de usuario para identificar cuentas sospechosas o maliciosas y se puedan conservar durante el tiempo suficiente para permitir un análisis forense retrasado.
• Asegúrese de que cada parte de su aplicación que contenga un control de seguridad quede registrada, independientemente de si tiene éxito o falla.
• Asegúrese de que los registros se generen en un formato que las soluciones de gestión de registros puedan consumir fácilmente.
• Asegúrese de que los datos de registro estén codificados correctamente para evitar inyecciones o ataques a los sistemas de registro o monitoreo.
• Asegúrese de que todas las transacciones tengan un registro de auditoría con controles de integridad para evitar la manipulación o eliminación, como tablas de bases de datos de solo anexión o similares.
• Asegúrese de que todas las transacciones que generen un error se reviertan y se reinicien. Siempre se cierran con error.
• Si su aplicación o sus usuarios se comportan de forma sospechosa, emita una alerta. Cree una guía para sus desarrolladores sobre este tema para que puedan codificar en consecuencia o adquirir un sistema para ello.
• Los equipos de seguridad y DevSecOps deben establecer casos de uso de monitoreo y alerta efectivos, incluidos manuales de estrategias, de modo que el equipo del Centro de Operaciones de Seguridad (SOC) detecte y responda rápidamente a las actividades sospechosas.
• Agregue «honeytokens» como trampas para atacantes en su aplicación, por ejemplo, en la base de datos, como identidades de usuario reales o técnicas. Dado que no se utilizan en la actividad empresarial habitual, cualquier acceso genera datos de registro que pueden alertarse con casi ningún falso positivo.
• El análisis del comportamiento y el soporte de IA podrían ser opcionalmente una técnica adicional para respaldar tasas bajas de falsos positivos en las alertas.
• Establezca o adopte un plan de respuesta y recuperación ante incidentes, como el del Instituto Nacional de Estándares y Tecnología (NIST) 800-61r2 o posterior. Enseñe a sus desarrolladores de software cómo se presentan los ataques e incidentes de aplicaciones para que puedan reportarlos.

Existen productos comerciales y de código abierto para la protección de aplicaciones, como el conjunto de reglas básicas de OWASP ModSecurity, y software de correlación de registros de código abierto, como Elasticsearch, Logstash y Kibana (ELK), que incluyen paneles de control personalizados y alertas que pueden ayudarle a combatir estos problemas. También existen herramientas comerciales de observabilidad que pueden ayudarle a responder o bloquear ataques prácticamente en tiempo real.

Ejemplos de escenarios de ataque.

Escenario n.° 1: El operador del sitio web de un proveedor de seguros médicos infantiles no pudo detectar una filtración debido a la falta de monitoreo y registro. Un tercero informó al proveedor de seguros médicos que un atacante había accedido y modificado miles de historiales médicos confidenciales de más de 3,5 millones de niños. Una revisión posterior al incidente reveló que los desarrolladores del sitio web no habían abordado vulnerabilidades significativas. Al no existir registro ni monitoreo del sistema, la filtración de datos podría haber estado ocurriendo desde 2013, un período de más de siete años.

Escenario n.° 2: Una importante aerolínea india sufrió una filtración de datos que afectó a más de diez años de datos personales de millones de pasajeros, incluyendo datos de pasaportes y tarjetas de crédito. La filtración se produjo en un proveedor externo de alojamiento en la nube, quien notificó a la aerolínea la filtración después de un tiempo.

Escenario n.° 3: Una importante aerolínea europea sufrió una infracción notificable del RGPD. La infracción se debió, según se informa, a vulnerabilidades de seguridad en aplicaciones de pago explotadas por atacantes que obtuvieron más de 400 000 registros de pago de clientes. Como resultado, la aerolínea recibió una multa de 20 millones de libras por parte del regulador de privacidad.

A09:2025 – Fallos de Registro y Monitoreo de Seguridad (Security Logging & Monitoring Failures)

Esta categoría engloba todo lo que impide detectar, registrar, responder o correlacionar actividades sospechosas.

No es solo “no loguear”: es loguear mal, loguear tarde, loguear sin contexto, no monitorear, no alertar y no proteger el pipeline de logs.

En 2025 sigue siendo una de las principales causas de detección tardía de intrusiones y de brechas masivas que pasan meses sin descubrirse.

🧩 Ejemplos típicos (2025)

• Falta de logs en endpoints críticos (login, admin, pagos).
• Logs incompletos (sin IP, user-agent, usuario, origen).
• No registrar fallos de autenticación → fuerza bruta invisible.
• No registrar cambios de configuración o privilegios.
• Alertas que nunca disparan o están mal configuradas.
• Tiempo de retención insuficiente (7 días = inútil).
• Logs almacenados localmente sin protección → manipulación.
• Logs sin integridad (sin hash o sin firma).
• Sistemas SIEM sin correlación real.
• Cargas útiles mal sanitizadas que rompen logs (“log injection”).
• Faltan auditorías de acceso a datos sensibles.
• No monitorear APIs, colas, S3, DB, contenedores o CI/CD.
• Telemetría inconsistente entre microservicios.

🔍 Mini-guía de explotación (Pentesting 2025)

1. Realizar intentos de login fallidos → verificar si aparecen en logs.
2. Probar fuerza bruta suave para ver si dispara alertas.
3. Modificar varios estados/roles → revisar si hay auditoría.
4. Eliminar o modificar datos → mirar si hay registro.
5. Inyectar cargas en logs (\n, %0D%0A, <script>) para detectar log injection.
6. Monitorear tiempo de reacción del SOC o SIEM (si es permitido).
7. Cambiar configuración de aplicaciones → ver si queda registrado.
8. Usar API no documentadas/legacy → ver si genera eventos.
9. Realizar escaneo moderado para detectar detección de patrones.
10. Acceder a S3/Storage sin permisos → ver si hay alerta.

🎯 Consecuencias

• Intrusiones que pasan meses sin detectarse.
• Falta de evidencia para incident response.
• Alteración de datos sin auditoría.
• Escaladas de privilegio invisibles.
• Explotación sostenida de vulnerabilidades sin rastros.
• Borrar logs → encubrir actividades maliciosas.
• Fraude financiero no trazable.
• Compromiso de infraestructura sin alertas.

🛡 Defensas modernas (2025)

• Logueo estructurado (JSON, ECS, OpenTelemetry).
• Logs obligatorios en:
  • autenticación
  • autorización
  • pagos
  • acciones administrativas
  • almacenamiento
  • API Gateway
  • CI/CD
• Retención mínima de 90–180 días (según regulación).
• Integridad de logs: hashing, firma, WORM storage.
• Centralización en SIEM/SOAR (Elastic, Splunk, Sentinel, QRadar).
• Correlación de eventos entre microservicios.
• Alertas basadas en comportamiento (UEBA).
• Monitoreo real de APIs, colas, contenedores, serverless y S3.
• Alertas de anomalías:
  • tasas de login
  • tráfico inusual
  • cambios repentinos de privilegios
• Protección ante log injection (escape y sanitización).
• Monitoreo del pipeline CI/CD.
• Dashboards en tiempo real y SLAs de respuesta.

📚 Subtipos / patrones modernos (2025)

Subtipo / patrón	Definición	Ejemplo bancario	Pentesting (qué probar)	Ataque / PoC	Consecuencia	Defensa	Tips examen
Missing Auth Logs	No se registran logins	Fuerza bruta invisible	Fallar logins	Invisibilidad	ATO silencioso	Log de login	“login invisible = fail”
Missing Privilege Logs	Cambios no auditados	Rol admin sin registro	Cambiar rol	Escalada oculta	Robo total	Auditoría	Buscar “role change”
Log Injection	Inyección en logs	Inyectar saltos/JS	\n %0D%0A	Romper logs	Manipulación	Escape adecuado	Keywords: “CRLF”
Insufficient Retention	Retención pobre	7 días de logs	Analizar retención	Fuga sin huellas	Sin evidencia	90+ días	Regulaciones requieren 6 meses
No SIEM / No Alerts	Logs sin monitoreo	Incidentes invisibles	Generar eventos	Sin alarmas	Persistencia	SIEM real	“SIEM sin reglas = inútil”
No Data Access Logging	Lectura de PII no registrada	Consulta de datos cliente	Leer datos	Robo PII	Fuga	Audit logs	PII siempre auditada
API/Cloud Unmonitored	Sin logs de API/S3	Bucket accesado	Acceder S3	Robo masivo	Fuga	CloudTrail/Monitor	Buscar “S3 sin logging”
CI/CD Logging Failures	Pipeline sin logs	Cambiar build	Alterar código	Backdoor	Compromiso	Logs CI/CD	Pipelines son críticos
Microservices Uncorrelated	Eventos aislados	Cada microservicio loguea distinto	Correlación manual	Ocultar actividad	Persistencia	OpenTelemetry	Buscar “trace-id”
Tamperable Logs	Logs editables localmente	/var/log editable	Modificar logs	Encubrimiento	Sin evidencia	WORM	Integridad = fundamental

🧪 Checklist rápida de pentesting A09:2025

• Revisar logs de login, logout, cambios de privilegio.
• Probar fuerza bruta controlada.
• Revisar retención de logs.
• Revisar integridad → ¿hash/sig?
• Probar log injection con CRLF y caracteres especiales.
• Revisar logs de API Gateway, WAF, NGINX, CloudTrail.
• Revisar logs de CI/CD.
• Ver si microservicios comparten trace-id.
• Revisar auditoría de lectura de datos sensibles.
• Simular anomalías: muchas requests, cambios de rol, peticiones sospechosas.

🧾 Resumen ejecutivo para cursos

A09:2025 Fallos de Registro y Monitoreo de Seguridad implica no detectar ni registrar adecuadamente eventos críticos, lo que permite ataques invisibles que pueden persistir durante meses sin ser descubiertos. Incluye falta de logs, logs incompletos, logs manipulables, ausencia de alertas, retención insuficiente, falta de correlación entre microservicios y monitoreo incompleto en APIs, storage o CI/CD. Su mitigación requiere logging estructurado, integridad y centralización de logs, retención adecuada, alertas realistas, correlación entre servicios y monitoreo continuo del comportamiento. Sin visibilidad, no hay seguridad.

A10:2025 Mal manejo de condiciones excepcionales

Manejo Inadecuado de Condiciones Excepcionales es una nueva categoría para 2025. Esta categoría contiene 24 CWE y se centra en el manejo inadecuado de errores, errores lógicos, fallos de apertura y otros escenarios relacionados derivados de condiciones y sistemas anormales. Esta categoría incluye algunos CWE que anteriormente se asociaban con una calidad de código deficiente. Esto era demasiado general para nosotros; en nuestra opinión, esta categoría más específica ofrece una mejor orientación.

CWE notables incluidos en esta categoría: CWE-209 Generación de mensaje de error que contiene información confidencial, CWE-234 Error al manejar parámetros faltantes, CWE-274 Manejo inadecuado de privilegios insuficientes, CWE-476 Desreferencia de puntero nulo y *CWE-636 No falla de forma segura (‘Fallo de apertura’), *

Tabla de puntuación.

CWE mapeados	Tasa máxima de incidencia	Tasa de incidencia promedio	Cobertura máxima	Cobertura promedio	Exploit ponderado promedio	Impacto ponderado promedio	Total de ocurrencias	Total de CVEs
24	20,67%	2,95%	100.00%	37,95%	7.11	3.81	769.581	3.416

Descripción.

La gestión inadecuada de condiciones excepcionales en el software ocurre cuando los programas no logran prevenir, detectar ni responder a situaciones inusuales e impredecibles, lo que provoca fallos, comportamientos inesperados y, en ocasiones, vulnerabilidades. Esto puede implicar una o más de las siguientes tres fallas: la aplicación no previene la ocurrencia de una situación inusual, no la identifica en el momento en que ocurre o responde de forma deficiente o nula a la situación posteriormente.

Las condiciones excepcionales pueden deberse a una validación de entrada incompleta, deficiente o faltante, a un manejo tardío de errores de alto nivel en las funciones donde ocurren, o a estados ambientales inesperados, como problemas de memoria, privilegios o red, manejo inconsistente de excepciones o excepciones que no se manejan en absoluto, lo que permite que el sistema caiga en un estado desconocido e impredecible. Cada vez que una aplicación no está segura de su siguiente instrucción, se ha manejado incorrectamente una condición excepcional. Los errores y excepciones difíciles de encontrar pueden amenazar la seguridad de toda la aplicación durante mucho tiempo.

Pueden ocurrir muchas vulnerabilidades de seguridad diferentes cuando gestionamos mal las condiciones excepcionales,

Como errores lógicos, desbordamientos, condiciones de carrera, transacciones fraudulentas o problemas con la memoria, el estado, los recursos, la sincronización, la autenticación y la autorización. Este tipo de vulnerabilidades puede afectar negativamente la confidencialidad, la disponibilidad o la integridad de un sistema o de sus datos. Los atacantes manipulan la gestión de errores defectuosa de una aplicación para aprovechar esta vulnerabilidad.

Cómo prevenir.

Para gestionar adecuadamente una condición excepcional, debemos planificar para tales situaciones (esperar lo peor). Debemos detectar cada posible error del sistema directamente donde ocurre y gestionarlo (lo que significa tomar medidas significativas para resolver el problema y asegurarnos de recuperarnos). Como parte del control, debemos incluir el lanzamiento de un error (para informar al usuario de forma comprensible), el registro del evento y la emisión de una alerta si lo consideramos justificado. También deberíamos contar con un gestor de excepciones global por si alguna vez se nos ha pasado por alto algo. Idealmente, también deberíamos contar con herramientas o funcionalidades de monitorización y/u observabilidad que detecten errores o patrones repetidos que indiquen un ataque en curso, que podría emitir una respuesta, defensa o bloqueo de algún tipo. Esto puede ayudarnos a bloquear y responder a scripts y bots que se centran en nuestras debilidades en el control de errores.

Detectar y gestionar condiciones excepcionales garantiza que la infraestructura subyacente de nuestros programas no se vea obligada a lidiar con situaciones impredecibles. Si se encuentra en medio de una transacción, es fundamental que la revierta por completo y la vuelva a iniciar (lo que se conoce como cierre fallido). Intentar recuperar una transacción a mitad de proceso suele ser el origen de errores irrecuperables.

Siempre que sea posible, agregue limitaciones de velocidad, cuotas de recursos, limitación y otros límites para evitar condiciones excepcionales desde el principio. En las tecnologías de la información, nada debe ser ilimitado, ya que esto conlleva falta de resiliencia de las aplicaciones, denegación de servicio, ataques de fuerza bruta exitosos y facturas de nube extraordinarias. Considere si los errores repetidos idénticos, por encima de una tasa determinada, solo deben mostrarse como estadísticas que muestren su frecuencia y el período de tiempo en que ocurrieron. Esta información debe adjuntarse al mensaje original para no interferir con el registro y la monitorización automatizados (véase A09:2025 Registro y alertas de fallos TJ).

Además, queremos incluir una validación de entrada estricta (con sanitización o escape para caracteres potencialmente peligrosos que debemos aceptar), gestión de errores, registro, monitorización y alertas centralizadas , y un gestor de excepciones global. Una aplicación no debería tener múltiples funciones para gestionar condiciones excepcionales; debe ejecutarse en un solo lugar y de la misma manera cada vez. También debemos crear requisitos de seguridad del proyecto para todos los consejos de esta sección, realizar modelado de amenazas o actividades de revisión de diseño seguro en la fase de diseño de nuestros proyectos, realizar revisiones de código o análisis estático, así como realizar pruebas de estrés, rendimiento y penetración del sistema final.

Si es posible, toda la organización debería manejar las condiciones excepcionales de la misma manera, ya que esto facilita la revisión y auditoría del código para detectar errores en este importante control de seguridad.

Ejemplos de escenarios de ataque.

A10:2025 – Manejo Inadecuado de Condiciones Excepcionales

Es una nueva categoría que une varias debilidades históricas relacionadas con:

• errores en el manejo de fallos de la aplicación
• casos de borde no contemplados
• estados anormales
• fallos lógicos en condiciones inesperadas
• “fail-open” (fallar abierto)
• manejo defectuoso de errores, timeouts, retry o fallos de servicios externos
• divulgación accidental de información sensible mediante mensajes de error

Es básicamente todo comportamiento inseguro que ocurre cuando la aplicación se enfrenta a una situación no prevista.

Esta categoría incluye CWE como:

• CWE-209 (exposición de info en mensajes de error)
• CWE-234 (manejo incorrecto de parámetros faltantes)
• CWE-274 (manejo inseguro de privilegios insuficientes)
• CWE-476 (null pointer dereference)
• CWE-636: Fail-open (la más peligrosa)

🧩 Ejemplos típicos (2025)

• Autorización que falla “abierta” cuando un microservicio no responde (“si no responde, permito todo”).
• Login que queda bypasseado si un campo viene nulo o vacío.
• API que no valida parámetros faltantes y asume defaults peligrosos.
• Errores internos que devuelven stack traces completos.
• Microservicio que cae y provoca que el API Gateway deje pasar requests críticas.
• Timeouts mal manejados que permiten repetir o saltar validaciones.
• Excepción no controlada → aplicación expone framework, rutas internas, secrets en logs.
• Sistemas de verificación que, ante error, dan acceso (fail-open).
• Procesos de pago donde un fallo intermedio deja transacciones a medias o inconsistentes.
• Validación de privilegios incorrecta ante condiciones inesperadas.
• Estado inconsistente por condiciones de carrera o interrupciones.
• Lectura de archivos inexistentes → respuestas con paths internos.

🔍 Mini-guía de explotación (pentesting 2025)

1. Romper flujos con valores nulos:
   • null, «», undefined, {}
2. Forzar timeouts (cortar la conexión a propósito).
3. Enviar parámetros faltantes para ver si asume defaults peligrosos.
4. Interrumpir flujos (dos requests a la vez, cancelar en medio).
5. Simular caída de microservicios (si tenés acceso permitido).
6. Buscar stack traces forzando errores.
7. Enviar payloads inesperados: tipos incorrectos, estructuras mal formadas.
8. Probar fail-open:
   • borrar headers
   • enviar tokens vacíos
   • valores “0”, “false”, “null”
9. Duplicar operaciones para encontrar estados inconsistentes.
10. Provocar errores internos y ver qué revela la respuesta.

🎯 Consecuencias

• Bypass total de autenticación o autorización.
• Exposición de información sensible (secret keys, rutas internas, DB hostnames).
• Estados corruptos: pagos duplicados, datos incoherentes.
• Acceso a recursos sin permisos por fallas “silent fail”.
• RCE indirecto a partir de excepciones mal manejadas.
• Caída total de sistemas o microservicios.
• Fugas de logs con secretos o credenciales.
• Escaladas de privilegios mediante parámetros faltantes.
• Acciones críticas sin validación (si falla la lógica previa).

🛡 Defensas modernas (2025)

• Fail-secure: ante error → bloquear, nunca permitir.
• Manejo uniforme y centralizado de errores.
• Validar estrictamente parámetros faltantes o nulos.
• Timeouts bien definidos + políticas claras (retry, fallback).
• Logging seguro (sin stack traces en producción).
• API Gateway con fallback seguro (deny-by-default).
• Mecanismos de circuit breaker (Hystrix, Resilience4j).
• Validación explícita de privilegios en cada paso, incluso ante fallos.
• Sanitización estricta de mensajes de error.
• Testing de caos / chaos engineering para asegurar resiliencia segura.
• Detección de estados inconsistentes (DB + transacciones).
• Políticas claras ante fallos de sistemas externos → bloquear.

 Subtipos / patrones modernos (2025)

Subtipo / patrón	Definición	Ejemplo bancario	Pentesting (qué probar)	Ataque / PoC	Consecuencia	Defensa	Tips examen
Fail-Open	Error que permite acceso	Microservicio Auth cae → acceso permitido	Cortar peticiones	Login bypass	ATO	Fail-secure	“si falla → bloquear”
Null Handling Failure	Manejo inseguro de nulos	role=null → rol admin	Enviar null/»»	Escalada	Impersonación	Validate null	Buscar null
Missing Parameter Handling	Parámetros faltantes → default peligroso	amount vacío = 0 → transacción	Quitar parámetros	Transacciones inconsistentes	Fraude	Validar obligatoriedad	Parámetros faltantes = alerta
Improper Error Message	Errores revelan información	Stack trace en /login	Forzar error	Info leakage	Robo de secrets	Mensajes genéricos	“Error detallado = peligro”
Timeout / Retry Issues	Timeout provoca estado inconsistente	Pago duplicado	Cortar conexión	Double spend	Pérdida $	Transacciones atómicas	Probar interrumpir
Privilege Check Failure	Error lógico en roles	if(error) allow()	Forzar error	Escalada	Impersonación	Validación universal	Preguntas sobre fallback
Unhandled Exception	Excepción sin control	Excepción muestra ruta	Payload inválido	Info leakage	Recon interno	Catch global	“Unhandled” = crítico
Race Condition on Errors	Error crea ventana	Error en update	Enviar dos requests	Inconsistencia	Corrupción	Locks/transactions	Race bajo error
Inconsistent State	Estado incompleto por fallo	Pago pasa a “pagado” sin serlo	Romper flujo	Estados corruptos	Fraude	Checks de integridad	Buscar “partial state”
External Service Failure	Falla en terceros mal manejada	Falla SMS y salta MFA	Simular caída	Bypass MFA	ATO	Fallback seguro	Terceros deben bloquear

🧪 Checklist rápida de pentesting A10:2025

• Enviar null, «», {}, arrays vacíos.
• Quitar parámetros críticos.
• Forzar errores internos y ver detalles.
• Causar timeouts intencionales.
• Cancelar requests a mitad de proceso.
• Revisar estados inconsistentes tras fallos.
• Simular caídas de microservicios (si está permitido).
• Probar fail-open cambiando headers o tokens vacíos.
• Forzar errores de terceros (SMS, mail, pagos) → ver si se abre acceso.
• Revisar mensajes de error y filtración.
• Revisar fallback en circuit breakers.
• Probar múltiples requests simultáneas en escenarios de error.

🧾 Resumen ejecutivo para cursos

A10:2025 Manejo Inadecuado de Condiciones Excepcionales es una categoría nueva que representa todos los fallos que ocurren cuando la aplicación enfrenta errores o situaciones anómalas: fallos en parámetros, nulos, timeouts, caídas de servicios externos, errores de lógica, fallos de autorización y comportamientos “fail-open”. Cuando estos errores no se manejan correctamente, pueden provocar bypass de autenticación, exposición de información sensible, inconsistencias de datos, duplicación de transacciones y acceso indebido a recursos. La mitigación exige fail-secure, validación estricta de parámetros, manejo centralizado de errores, circuit breakers, fallback seguro y testing de caos. Si la aplicación falla abierta, falla por completo.

FIXME : Actualizar los ejemplos para que sean más modernos

Escenario n.° 1: El agotamiento de recursos por la gestión incorrecta de condiciones excepcionales (denegación de servicio) podría ocurrir si la aplicación detecta excepciones al cargar archivos, pero no libera los recursos correctamente después. Cada nueva excepción bloquea los recursos o los deja indisponibles hasta que se agotan.

Escenario n.° 2: Exposición de datos confidenciales por manejo inadecuado o errores en la base de datos que revelan el error completo del sistema al usuario. El atacante continúa forzando errores para usar la información confidencial del sistema para crear un mejor ataque de inyección SQL. Los datos confidenciales en los mensajes de error del usuario son de reconocimiento. Escenario n.° 3: La corrupción de estado en transacciones financieras podría deberse a que un atacante interrumpa una transacción de varios pasos mediante interrupciones de la red. Imagine que el orden de la transacción fuera: debitar la cuenta del usuario, acreditar la cuenta de destino, registrar la transacción. Si el sistema no revierte correctamente toda la transacción (cerrado por error) cuando se produce un error durante el proceso, el atacante podría vaciar la cuenta del usuario o posiblemente generar una condición de carrera que le permita enviar dinero al destino varias veces.

¿Cuáles son los riesgos de seguridad de las aplicaciones?

Los atacantes pueden usar diversas rutas a través de su aplicación para perjudicar a su empresa u organización. Cada una de estas vías representa un riesgo potencial que debe investigarse.

Agentes de amenaza	Ataque \ Vectores	Explotabilidad	Probabilidad de falta de seguridad Controles	Técnico Impactos	Negocio Impactos
Por entorno, dinámica por imagen de la situación	Por exposición de la aplicación (por entorno)	Exploit ponderado promedio	Controles faltantes \ por tasa de incidencia promedio \ Ponderado por cobertura	Impacto ponderado promedio	Por negocios

En palabras de OWASP: nuestra Calificación de Riesgo hemos tomado en cuenta los parámetros universales de explotabilidad, probabilidad promedio de falta de controles de seguridad para una debilidad y sus impactos técnicos.

Cada organización es única, al igual que los agentes de amenazas que la atacan, sus objetivos y el impacto de cualquier vulneración. Si una organización de interés público utiliza un sistema de gestión de contenido (CMS) para información pública y un sistema de salud utiliza el mismo CMS para historiales médicos confidenciales, los agentes de amenazas y el impacto empresarial pueden ser muy diferentes para el mismo software. Es fundamental comprender el riesgo para su organización en función de la exposición de la aplicación, los agentes de amenazas aplicables según la situación (para ataques dirigidos e indirectos por empresa y ubicación) y los impactos empresariales individuales.

OWASP TOP 10 – 2025 (Explicado de forma didáctica)

La edición 2025 introduce dos categorías nuevas y consolida otras, con un enfoque más fuerte en causas raíz en lugar de síntomas. Si bien sigue siendo un Top 10, OWASP reconoce que la complejidad del software hace imposible evitar cierto grado de superposición entre categorías.

🔸 A01:2025 – Broken Access Control (Control de acceso deficiente)

Continúa siendo la vulnerabilidad más crítica por séptima edición consecutiva.

✔ Presente en 3,73 % de las aplicaciones analizadas

✔ Contiene 40 CWEs

✔ Incluye ahora SSRF, que deja de ser categoría propia

Los fallos de control de acceso permiten que usuarios actúen fuera de su rol: ver datos ajenos, modificar recursos, acceder a funciones administrativas, etc. SSRF se incorpora porque su causa raíz está directamente relacionada con el mal control de qué recursos puede acceder un componente del sistema.

🔸 A02:2025 – Security Misconfiguration (Configuración errónea de seguridad)

Sube del puesto #5 al #2.

✔ Presente en 3 % de las aplicaciones

✔ Contiene 16 CWEs

La complejidad del software moderno aumenta el número de configuraciones, y por ende, las posibilidades de error: servicios expuestos, CORS abiertos, headers faltantes, puertos no protegidos, frameworks mal configurados, etc.

🔸 A03:2025 – Software Supply Chain Failures (Fallos en la cadena de suministro de software)

Nueva categoría consolidada a partir de A06:2021.

✔ Cubre dependencias, build systems, repositorios, pipelines CI/CD, paquetes comprometidos, etc.

✔ Solo 5 CWEs, pero con impacto crítico en CVEs reales

✔ Baja presencia en datos → difícil de detectar automáticamente

Es una de las preocupaciones más votadas por la comunidad. Representa ataques tipo SolarWinds, paquete NPM malicioso, dependencias con malware o librerías manipuladas.

🔸 A04:2025 – Cryptographic Failures (Fallos criptográficos)

Baja del #2 al #4.

✔ Presente en 3,80 % de las aplicaciones

✔ Contiene 32 CWEs

Agrupa errores como:

– Datos sensibles sin cifrar

– Algoritmos obsoletos

– Gestión incorrecta de claves

– TLS débil

– Falta de hashing seguro

Suele ocasionar filtraciones, pérdida de integridad y vulneración total del sistema.

🔸 A05:2025 – Injection (Inyección de vulnerabilidades)

Desciende al puesto #5.

✔ Contiene 38 CWEs

✔ Categoría con más CVEs históricas

Incluye desde SQLi de alto impacto hasta XSS de impacto menor pero muy frecuente. A pesar de décadas de concienciación, sigue siendo una de las vulnerabilidades más explotadas.

🔸 A06:2025 – Insecure Design (Diseño inseguro)

Baja al #6.

A pesar de su bajada, la industria ha mejorado en:

✔ modelado de amenazas

✔ patrones de arquitectura segura

✔ validación temprana de requisitos de seguridad

Se centra en fallos conceptuales, no en bugs de código.

🔸 A07:2025 – Authentication Failures (Fallos de autenticación)

Se mantiene en el #7, con un nombre más preciso.

✔ Contiene 36 CWEs

✔ Mejoras gracias al uso de protocolos estándar (OAuth2, OIDC, SAML)

Agrupa errores como:

– contraseñas débiles

– sesiones inseguras

– MFA ausente

– rate-limiting inexistente

– recuperaciones de cuenta vulnerables

🔸 A08:2025 – Software and Data Integrity Failures (Fallos en la integridad del software o los datos)

Permanece en el #8.

Se enfoca en mantener límites de confianza y verificar integridad:

– Validación de integridad de datos

– Deserialización insegura

– Actualizaciones sin firma

– Scripts externos sin verificación

Menos amplio que la categoría A03, pero complementario.

🔸 A09:2025 – Logging and Alerting Failures (Fallos en el registro y las alertas)

Conserva el #9, con nuevo nombre.

✔ Destaca ahora la importancia de alertas, no solo de logs

✔ Históricamente infrarrepresentada en datos automáticos

✔ Elegida recurrentemente por la comunidad

Sin alertas, los incidentes pueden pasar desapercibidos durante meses.

🔸 A10:2025 – Improper Error Handling (Manejo inadecuado de condiciones excepcionales)

Nueva categoría 2025.

✔ Contiene 24 CWEs

✔ Se enfoca en:

– errores lógicos

– fallos abiertos

– manejo inseguro de errores

– mensajes de error con información sensible

– comportamientos inesperados bajo condiciones anómalas

Los errores mal gestionados suelen abrir puertas para ataques de enumeración, evasión, DoS o revelación de información crítica.

¡Excelente trabajo al completar este capítulo!

En este capítulo aprendiste cuáles son las 10 principales vulnerabilidades OWASP para el 2025, cómo han evolucionado desde años anteriores y por qué representan un riesgo para las aplicaciones modernas. Ahora comprendes mejor las causas raíz, el impacto de cada categoría y las tendencias actuales en ciberseguridad. Esta base te permitirá analizar aplicaciones con un enfoque más crítico y aplicar prácticas más seguras en tus futuros proyectos.