Control de acceso roto

Autenticación —quién eres— y autorización —qué te corresponde— son cosas distintas. El control de acceso roto confunde las dos: la aplicación ve que hay sesión y da por hecho que el recurso pedido es tuyo, sin comprobarlo. El síntoma clásico es una dirección como /pedido?id=1043 que muestra tu pedido, y al cambiar el número muestra el de otro cliente. En Salitre, los pedidos se numeran seguidos y no se comprueba la propiedad.

Iniciar sesión demuestra quién eres, no a qué tienes derecho. Dar lo segundo por lo primero es justo donde se rompe el control de acceso.

Cuando los recursos se numeran seguidos y no se comprueba su dueño, cualquier usuario autenticado lee los de todos cambiando el número en la dirección. No hace falta técnica avanzada: basta sumar uno. En Salitre, una cuenta pidió /pedido?id= con números que no eran suyos y la aplicación se los devolvió. El rastro queda en el registro: la misma cuenta leyendo pedidos de varios dueños distintos.

Lo que hace grave este fallo es su facilidad: no requiere herramientas, solo probar números. Por eso aparece tanto y por eso se explota tan rápido.

La remediación no es esconder los números ni hacerlos aleatorios: eso solo lo disimula. Se arregla comprobando, en cada acceso, que el recurso pedido pertenece a quien lo pide. Ocultar el identificador es seguridad por oscuridad; comprobar la propiedad es control de acceso de verdad. En Salitre, el arreglo es que la aplicación valide el dueño del pedido antes de mostrarlo, tenga el número que tenga.

Esconder el número cambia la dificultad de adivinarlo, no el permiso. El fallo se cierra verificando propiedad, no haciendo el identificador más difícil de teclear.

El acceso a lo ajeno no se supone: se ve en el registro de peticiones. Abre el laboratorio, revisa el registro de /pedido?id=N de Salitre y baja hasta el código de sala al pie.