Escalada horizontal y vertical, y los parámetros ocultos

En la escalada horizontal, una persona accede a recursos de otra del mismo nivel: un cliente que ve el pedido de otro cliente. En la escalada vertical, una persona accede a funciones o datos reservados a un nivel superior: un cliente que usa una función de administración. La guía de pruebas de OWASP las trata en WSTG-ATHZ-03, «Testing for Privilege Escalation», y el IDOR de la sala anterior es el caso típico de la horizontal.

La diferencia importa por la gravedad y por la corrección. Una escalada vertical suele abrir el control de todos los usuarios y de la configuración; la horizontal expone datos de iguales. En el informe se nombra cuál es, porque cambia la prioridad y la prueba que el cliente debe repetir.

Muchas API construyen el objeto del perfil a partir de todo lo que llega en la petición. El formulario de la web solo envía nombre, teléfono y correo, pero el servidor tiene más campos en ese objeto: los puntos, el identificador y el que decide el nivel de acceso de la cuenta. Si no se limita explícitamente qué campos se pueden modificar, quien incluya uno más en la petición lo cambia. La debilidad se llama asignación masiva y su entrada en el catálogo de debilidades es la CWE-915, «Improperly Controlled Modification of Dynamically-Determined Object Attributes».

La señal de reconocimiento es una comparación: los campos que la API devuelve al leer el perfil, frente a los que el formulario envía. Todo lo que está en la primera lista y no en la segunda es candidato, y la prueba autorizada dice si el servidor aceptó un cambio. Abre el laboratorio y compara.

Con el campo identificado, la prueba registró el cambio de rol de la cuenta del equipo y la lectura posterior de una ruta de administración. Es la evidencia que convierte una sospecha en un hallazgo: el antes, el después y lo que la cuenta pudo abrir con su nuevo rol. Sin esa lectura de comprobación, «el campo se aceptó» queda como una observación; con ella, es el impacto demostrado.

Revisa en el laboratorio la tabla de cambios de rol y clasifica lo que ocurrió: de qué rol a cuál y a través de qué función.

El control de acceso se evalúa por función, y una misma dirección puede alojar varias: leer, crear, modificar, borrar. Es frecuente que alguien proteja el GET que lista usuarios y olvide el PATCH que cambia su estado, o que el control viva solo en el menú de la interfaz: si el botón no aparece, se da por hecho que la función no existe. El servidor, sin embargo, responde a lo que llega, aparezca o no el botón.

Por eso la prueba se repite con cada método que la API admite y con la sesión de cada rol. Abre el laboratorio y mira qué respondió la función de usuarios a la sesión de cliente en cada método.

La recomendación para la asignación masiva no es «validar la entrada»: es que el servidor trabaje con una lista explícita de campos que cada función admite modificar (en el caso del perfil, nombre, teléfono y correo) y descarte el resto. El rol, los puntos y el identificador se cambian solo por funciones internas con su propio permiso.

Para la función de estado de usuarios, la corrección es de otra naturaleza: una comprobación de rol en el servidor, aplicada a todos los métodos de la función, no solo al GET. Ocultar el botón en la interfaz no es un control. Un informe claro entrega las dos recomendaciones por separado, porque se arreglan en sitios distintos.