Nueva categoría de riesgo en el OWASP Top Ten: Esperar lo inesperado

Con el lanzamiento del Top Ten 2025 de OWASP, las empresas tienen un par de nuevas categorías de riesgo a las que prestar especial atención, incluida una categoría totalmente nueva que demuestra, de una vez por todas, que lo que no sabes sí puede hacerte daño.

La nueva categoría, Gestión incorrecta de condiciones excepcionales, describe lo que puede salir mal cuando las organizaciones no están preparadas para prevenir, detectar y responder a situaciones inusuales o impredecibles. Según OWASP, esta vulnerabilidad puede activarse cuando una aplicación no impide que ocurra algo inusual, no identifica un problema cuando surge y/o responde de forma deficiente o nula cuando aparece una situación inesperada.

La idea de que las empresas deben estar preparadas para lo imprevisto refleja la realidad de los sistemas altamente distribuidos e interconectados de hoy en día. Y no es que OWASP hable de problemas desconocidos: la Gestión incorrecta de condiciones excepcionales abarca 24 Enumeraciones de Debilidades Comunes (CWE). Es solo que esas CWE, que implican un manejo inadecuado de errores, fallos al abrir eventos, errores lógicos y otros escenarios, pueden ocurrir bajo condiciones anormales. Esto puede resultar, por ejemplo, de una validación de entrada inadecuada, errores de alto nivel en las funciones de manejo y el tratamiento inconsistente (o inexistente) de las excepciones. Como afirma OWASP: "Cada vez que una aplicación no está segura de su siguiente instrucción, se ha gestionado mal una condición excepcional".

Esas circunstancias excepcionales pueden hacer que los sistemas caigan en un estado impredecible, provocando bloqueos del sistema, comportamientos inesperados y vulnerabilidades de seguridad duraderas. La clave para prevenir este tipo de interrupción es, esencialmente, esperar lo peor y planificar estar preparado para cuando ocurra lo inesperado.

[VER VIDEO]

Circunstancias excepcionales y la evolución del Top Ten

La composición de la lista cuatrienal del Top Ten de los riesgos más graves para la seguridad de las aplicaciones web se ha mantenido bastante estable a lo largo de los años, con algunas categorías moviéndose en la lista y quizás una o dos incorporaciones cada cuatro años. La edición de 2025 tiene dos nuevas entradas, incluida la Gestión incorrecta de condiciones excepcionales en el puesto número 10. La otra, Fallos en la cadena de suministro de software, que ocupa el puesto número 3, es una expansión de una categoría anterior, Componentes vulnerables y obsoletos (número 6 en 2021), que ahora incluye una amplia gama de compromisos de software. (Para quienes llevan la cuenta, Control de acceso roto sigue siendo el riesgo número 1).

Las condiciones excepcionales que constituyen la categoría más reciente pueden crear una multitud de vulnerabilidades, desde errores lógicos hasta desbordamientos, y desde transacciones fraudulentas hasta problemas con la memoria, el tiempo, la autenticación, la autorización y otros factores. Estos tipos de vulnerabilidades pueden afectar la confidencialidad, disponibilidad e integridad de un sistema o sus datos. Permiten que un atacante manipule el manejo defectuoso de errores de una aplicación, por ejemplo, para explotar la vulnerabilidad, señaló OWASP.

Un ejemplo de fallo al manejar condiciones inesperadas es cuando una aplicación identifica excepciones mientras se cargan archivos durante un ataque de denegación de servicio, pero luego no libera los recursos posteriormente. Cuando eso sucede, los recursos permanecen bloqueados o no disponibles, lo que resulta en el agotamiento de los recursos. Si un atacante interviene en una transacción financiera de varios pasos, un sistema que no revierte la transacción una vez detectado un error podría permitir al atacante vaciar la cuenta del usuario. Si se detecta un error a mitad de una transacción, es muy importante "bloquear ante fallos" (fail closed); es decir, revertir toda la transacción y empezar de nuevo. Intentar recuperar una transacción a mitad de camino puede crear errores irreparables.

Bloqueo ante fallos (Fail Closed) vs. Apertura ante fallos (Fail Open)

Entonces, ¿cuál es la diferencia entre estas dos acciones? Vamos a aclararlo:

Apertura ante fallos (Fail Open): Si un sistema se "abre ante fallos", continúa operando o permanece "abierto" cuando algo sale mal. Esto es útil cuando mantener las cosas en funcionamiento es muy importante, pero puede ser arriesgado para la seguridad.

Bloqueo ante fallos (Fail Closed): Si un sistema se "bloquea ante fallos", se apaga automáticamente o se vuelve seguro cuando hay un problema. Esto es más seguro desde una perspectiva de seguridad porque ayuda a prevenir el acceso no autorizado.

Manejo de errores imprevistos

Prevenir este tipo de riesgo comienza con la planificación para lo desconocido. Y eso implica ser capaz de detectar cualquier posible error del sistema cuando ocurre y tomar medidas para resolver el problema. Debe ser capaz de informar adecuadamente al usuario (sin revelar información crítica al atacante), registrar el evento y, si es necesario, emitir una alerta.

Aquí hay un ejemplo de la divulgación de un error de consulta SQL, junto con la ruta de instalación del sitio, que puede usarse para identificar un punto de inyección:

Advertencia: odbc_fetch_array() espera que el parámetro /1 sea un recurso, pero se recibió un booleano en D:\app\index_new.php en la línea 188

Lo ideal es que un sistema cuente con un gestor de excepciones global para capturar errores pasados por alto, junto con herramientas de monitorización u observabilidad, o una función que detecte errores repetidos o patrones que puedan indicar un ataque en curso. Esto ayuda a defenderse de ataques destinados a aprovechar cualquier debilidad que la empresa pueda tener en la gestión de errores.

Para una aplicación web Java estándar, por ejemplo, se puede configurar un gestor de errores global en el descriptor de despliegue web.xml; en este caso, una configuración utilizada a partir de la especificación de Servlet versión 2.5 en adelante.

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

ns="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
‍
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

‍‍version="3.0">
...
  <error-page>
     <exception-type>java.lang.Exception</exception-type>
     <location>/error.jsp</location>
</error-page>
...
</web-app>
‍

Este pequeño bloque de código indica a una aplicación web Java qué hacer cuando algo sale mal internamente. En lugar de mostrar a los usuarios un mensaje de error confuso o una pantalla en blanco, captura el problema discretamente y los redirige a una página de error personalizada. En este caso, dicha página sería error.jsp.

Al estar configurado para gestionar los tipos generales java.lang.Exception, actúa como un gestor de errores maestro para toda la aplicación. Esto significa que, independientemente de dónde ocurra un error, los usuarios serán redirigidos a la misma página de error, coherente y amigable, en lugar de ver detalles técnicos sin procesar.

Prevenir lo inesperado

Idealmente, las organizaciones deben trabajar para evitar, en la medida de lo posible, que se produzcan condiciones excepcionales. Implementar limitación de tasa, cuotas de recursos, estrangulamiento y otros límites puede ayudar contra ataques de denegación de servicio y fuerza bruta, por ejemplo. Es recomendable identificar errores repetidos idénticos e incluirlos solo como estadísticas para que no interfieran con el registro y la monitorización automatizados. Un sistema también debe incluir:

Validación estricta de entradas, para garantizar que solo entren al flujo de trabajo datos correctamente formados y saneados. Debe realizarse al inicio del flujo de datos, idealmente tan pronto como se reciban.

Buenas prácticas de gestión de errores, para capturar errores justo donde ocurren. Deben tratarse de forma eficiente: informar claramente a los usuarios, mantener un registro y enviar alertas si es necesario. Un gestor de errores global también es ideal para capturar cualquier cosa que se haya pasado por alto. 

Seguridad general de las transacciones, que también es imprescindible. Aplique siempre el "fallo cerrado": si algo sale mal, revierta toda la transacción. No intente corregir una transacción a medias, ya que puede causar problemas mayores.

Registro, monitorización y alertas centralizados, junto con un gestor de excepciones global, lo que permite una investigación rápida de incidentes y un proceso uniforme de gestión de eventos, facilitando además el cumplimiento de los requisitos normativos.

Modelado de amenazas y/o revisión de diseño seguro, realizados en la fase de diseño de los proyectos.

Revisión de código o análisis estático, así como pruebas de estrés, rendimiento y penetración realizadas en el sistema final.

La gestión incorrecta de condiciones excepcionales puede ser una categoría nueva, pero implica principios básicos de ciberseguridad y subraya por qué las empresas deben estar preparadas para lo que no necesariamente anticipan. Quizás no sepa qué forma tomarán las condiciones excepcionales, pero sabe que ocurrirán. La clave es estar preparado para gestionarlas todas de la misma manera, lo que facilitará detectar y responder a esas condiciones cuando surja lo inevitable.

Nota para los usuarios de SCW Trust Score™:

A medida que actualizamos el contenido de nuestra plataforma de aprendizaje para alinearlo con el estándar OWASP Top 10 2025, es posible que observe ajustes menores en el Trust Score de sus desarrolladores Full Stack. Comuníquese con su representante de Customer Success si tiene preguntas o necesita asistencia.