A10:2025 Manejo Inadecuado de Condiciones Excepcionales

Antecedentes

El Manejo Inadecuado de Condiciones Excepcionales es una categoría nueva para 2025. Esta categoría contiene 24 CWE y se centra en el manejo inadecuado de errores, errores lógicos, fallas de forma abierta (failing open) y otros escenarios relacionados derivados de condiciones anormales que los sistemas pueden encontrar. Esta categoría incluye algunas CWE que anteriormente se asociaban con una mala calidad del código. Aquello era demasiado general para nosotros; en nuestra opinión, esta categoría más específica proporciona una mejor orientación.

CWE notables incluidas en esta categoría: CWE-209: Generación de mensajes de error que contienen información sensible, CWE-234: Omisión del manejo de parámetros faltantes, CWE-274: Manejo inadecuado de privilegios insuficientes, CWE-476: Desreferencia de puntero NULL, y CWE-636: No fallar de forma segura ('Fallar de forma abierta' / 'Failing Open').

Tabla de puntuación

CWEs Mapeadas	Tasa Máxima de Incidencia	Tasa Promedio de Incidencia	Cobertura Máxima	Cobertura Promedio	Promedio Ponderado de Explotación	Promedio Ponderado de Impacto	Ocurrencias Totales	CVEs Totales
24	20.67%	2.95%	100.00%	37.95%	7.11	3.81	769,581	3,416

Descripción

El manejo inadecuado de condiciones excepcionales en el software ocurre cuando los programas no logran prevenir, detectar y responder a situaciones inusuales e impredecibles, lo que provoca caídas (crashes), comportamientos inesperados y, a veces, vulnerabilidades. Esto puede implicar uno o más de los siguientes tres fallas: la aplicación no previene que ocurra una situación inusual, no identifica la situación mientras está ocurriendo y/o responde de forma deficiente o no responde en absoluto a la situación posteriormente.

Las condiciones excepcionales pueden ser causadas por una validación de entradas ausente, deficiente o incompleta; por un manejo de errores de alto nivel tardío en lugar de realizarse en las funciones donde ocurren; por estados ambientales inesperados como problemas de memoria, privilegios o red; por un manejo de excepciones inconsistente o por excepciones que no se manejan en absoluto, permitiendo 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 inadecuadamente 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 manejamos inadecuadamente las condiciones excepcionales, como errores de lógica, desbordamientos (overflows), condiciones de carrera (race conditions), transacciones fraudulentas o problemas de memoria, estado, recursos, tiempos (timing), autenticación y autorización. Estos tipos de vulnerabilidades pueden afectar negativamente la confidencialidad, disponibilidad y/o integridad de un sistema o de sus datos. Los atacantes manipulan el manejo de errores defectuoso de una aplicación para atacar esta vulnerabilidad.

Cómo prevenir

Para manejar adecuadamente una condición excepcional, debemos planificar para tales situaciones (esperar lo peor). Debemos "capturar" (catch) cada posible error del sistema directamente en el lugar donde ocurre y luego manejarlo (lo que significa hacer algo significativo para resolver el problema y asegurar que nos recuperamos del mismo). Como parte del manejo, debemos incluir el lanzamiento de un error (para informar al usuario de forma comprensible), el registro (logging) del evento, así como la emisión de una alerta (alerting) si consideramos que está justificado. También deberíamos tener un manejador de excepciones global por si acaso algo se nos ha pasado por alto. Idealmente, también tendríamos herramientas o funcionalidades de monitoreo y/u observabilidad que vigilen errores repetidos o patrones que indiquen un ataque en curso, que pudieran 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 de manejo de errores.

Capturar y manejar las condiciones excepcionales garantiza que la infraestructura subyacente de nuestros programas no se deje a merced de situaciones impredecibles. Si se encuentra a mitad de una transacción de cualquier tipo, es extremadamente importante que revierta (roll back) cada parte de la transacción y comience de nuevo (lo que también se conoce como fallar de forma segura o "fail closed"). Intentar recuperar una transacción a medias es a menudo donde creamos errores irrecuperables.

Siempre que sea posible, añada limitación de tasa (rate limiting), cuotas de recursos, regulación (throttling) y otros límites para prevenir las condiciones excepcionales en primer lugar. Nada en la tecnología de la información debería ser ilimitado, ya que esto conduce a una falta de resiliencia de la aplicación, denegación de servicio, ataques exitosos de fuerza bruta y facturas extraordinarias en la nube.

Considere si errores idénticos repetidos, por encima de una cierta tasa, deberían mostrarse únicamente como estadísticas que indiquen con qué frecuencia han ocurrido y en qué intervalo de tiempo. Esta información debería añadirse al mensaje original para no interferir con el registro y monitoreo automatizados, consulte A09:2025-Fallas en el Registro, Alerta y Monitoreo de Seguridad.

Además de esto, querríamos incluir una validación de entradas estricta (con saneamiento o escape para los caracteres potencialmente peligrosos que debamos aceptar), un manejo de errores, registro, monitoreo y alertas centralizados, y un manejador de excepciones global. Una aplicación no debería tener múltiples funciones para manejar condiciones excepcionales; debería realizarse en un solo lugar, de la misma manera cada vez. También deberíamos crear requisitos de seguridad del proyecto para todos los consejos de esta sección, realizar actividades de modelado de amenazas y/o 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 ejecutar pruebas de estrés, rendimiento y penetración del sistema final.

Si es posible, toda su 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 en busca de errores en este importante control de seguridad.

Ejemplos de escenarios de ataque

Escenario #1: El agotamiento de recursos mediante el manejo inadecuado de condiciones excepcionales (Denegación de Servicio) podría producirse si la aplicación captura excepciones cuando se suben archivos, pero no libera adecuadamente los recursos después. Cada nueva excepción deja los recursos bloqueados o no disponibles de otro modo, hasta que se agotan todos los recursos.

Escenario #2: Exposición de datos sensibles mediante un manejo inadecuado o errores de base de datos que revelan el error completo del sistema al usuario. El atacante continúa forzando errores para utilizar la información sensible del sistema para crear un mejor ataque de inyección SQL. Los datos sensibles en los mensajes de error del usuario sirven de reconocimiento (reconnaissance).

Escenario #3: La corrupción de estado en transacciones financieras podría ser causada por un atacante que interrumpe una transacción de varios pasos mediante interrupciones de 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 adecuadamente toda la transacción (fallar de forma segura o "fail closed") cuando hay un error a mitad del proceso, el atacante podría potencialmente vaciar la cuenta del usuario, o posiblemente una condición de carrera podría permitir al atacante enviar dinero al destino varias veces.

Referencias

OWASP MASVS‑RESILIENCE