Del cliente al servidor: la API es la superficie de verdad

La aplicación de Colibrí muestra tus pedidos pidiéndolos a la API por su identificador. En el proxy cambias ese identificador por otro y el servidor te devuelve el pedido de otro cliente —con su nombre, su dirección y lo que compró—. La aplicación nunca te habría dejado pedir ese identificador, pero la aplicación no es la frontera: el servidor respondió sin comprobar que el pedido fuera tuyo. Es un control de acceso roto, y el impacto se mide por el alcance: si los identificadores son correlativos, se podrían recorrer todos.

El arreglo está en el servidor: en cada petición, comprobar que el recurso pedido pertenece a quien lo pide, con la identidad que sale de la sesión. Cambiar la aplicación para que «no deje» pedir otro identificador no cierra nada, porque el atacante no usa la aplicación.

Al comprar en Colibrí, la aplicación manda a la API el artículo y también el precio que mostró en pantalla. En el proxy cambias ese precio a la mitad y el pedido se registra con el precio que tú enviaste. El servidor confió en un dato que el cliente controla. La pantalla puede mostrar el precio, pero el importe que se cobra tiene que decidirlo el servidor consultando su propio catálogo, ignorando lo que el cliente diga que vale.

El arreglo: el servidor calcula el precio a partir del identificador del artículo y su catálogo; el precio enviado por el cliente se descarta. Lo mismo vale para cantidades, descuentos y cualquier número con consecuencia económica.

En el módulo anterior abriste, enganchando la app, la pantalla de administración de Colibrí. Ahora lo compruebas contra la API: llamas directamente a la ruta de administración /interno/usuarios que encontraste en el análisis estático, con tu sesión de cliente normal. Si el servidor responde con la lista de usuarios, el control de acceso vivía únicamente en el cliente —en el botón que no se dibujaba— y no existía en el servidor. Si el servidor responde «no autorizado», el control estaba donde debía y la pantalla vacía era la prueba.

En Colibrí el servidor responde con los datos: confirmado, el «solo administradores» era interfaz. El arreglo es que cada ruta sensible verifique el rol en el servidor, derivado de la sesión, con la regla de denegar por defecto.

Es tentador cerrar estos hallazgos endureciendo la aplicación: quitar la ruta del código, ofuscar, reforzar la detección de root. Ninguna de esas medidas cierra los fallos de esta sala, porque todas asumen que el atacante usa la aplicación tal como se distribuye. El atacante habla directamente con la API, con el proxy, sin pasar por la interfaz. Mientras el servidor confíe en identificadores ajenos, en precios del cliente o en un rol enviado, el fallo sigue abierto aunque la aplicación sea impecable. La corrección de toda la ruta se concentra en una idea: validar en el servidor todo lo que tenga consecuencia, tratando cada petición como potencialmente manipulada.

En el informe de Colibrí las remediaciones van al servidor —propiedad del recurso, precio desde catálogo, rol desde la sesión—; las mejoras del cliente se anotan aparte como lo que son: fricción útil, no cierre del fallo.

Abre el laboratorio y repite contra la API de Colibrí la petición de un pedido con un identificador que no es el tuyo. El servidor te devuelve el pedido de otro cliente: en la revisión de esa respuesta hay un código de la sala. Escríbelo tal cual.