El repetidor, una variable a la vez

Si se cambian dos cosas a la vez y la respuesta cambia, no se sabe cuál de las dos fue. Por eso el método del repetidor es siempre el mismo: una petición base, que funciona, y una variación por pestaña. Cada pestaña responde una pregunta concreta: qué pasa si no hay sesión, qué pasa con la sesión de otra cuenta, qué pasa si cambia el formato. El resto de la petición queda idéntico.

Las pestañas de Tamarindo parten de GET /api/reservas/5521 con la sesión de la cuenta A, que es la dueña de esa reserva.

Dos cuentas de prueba permiten comprobar si el servidor verifica a quién pertenece lo que entrega. La cuenta A es dueña de la reserva 5521; la B, de otra. Si la B pide la reserva de la A y la respuesta es un error, el control funciona. Si la respuesta es la misma que recibe la dueña, el servidor está entregando datos ajenos a quien tenga sesión, aunque sea de otra persona.

Lee repetidor-pestanas.txt y compara las respuestas de las cuatro pestañas con la de la petición original. Te interesa la que cambia quién pide, no qué se pide.

La longitud de la respuesta es la forma más rápida de saber si dos pestañas devolvieron lo mismo. Dos pestañas pesan lo mismo y traen el mismo contenido; una es un error corto; la del parámetro de formato, con el parámetro de formato, devuelve una versión reducida. Medir la diferencia de tamaño entre la respuesta completa y la reducida muestra cuánta información extra trae el formato completo, como los identificadores internos del cliente.

Calcula cuánto más pesa la respuesta de la petición original que la de la pestaña con el parámetro de formato.

Lo que se guarda para el informe debe bastar para que el cliente reproduzca el hallazgo, y nada más. Para la pestaña que demuestra el fallo eso significa la petición y la respuesta de las pestañas relevantes, con los datos personales tapados y con una conclusión clara. No se enumeran todas las reservas que se podrían alcanzar cambiando el número: una muestra mínima demuestra que el control falla; el resto solo multiplica los datos personales que se custodian.

Repetir un GET suele ser seguro. Repetir un POST que crea algo no lo es: cada envío es una operación nueva en el sistema del cliente. En Tamarindo, reenviar la creación de la reserva para ver si respondía igual dejó reservas reales en producción. No fue un ataque, y aun así hay que limpiarlo. Antes de repetir una petición que cambia datos se mira lo que dicen las reglas de enfrentamiento y se anota cada una en la bitácora; después se avisa al cliente para que las cancele.

Lee bitacora-repeticiones.txt y cuenta cuántas reservas quedaron creadas por las repeticiones.