Redirecciones que cambian el destino

Un cliente HTTP con redirecciones activadas hace tantas peticiones como haga falta hasta llegar a una respuesta final. La aplicación solo vio la primera dirección: las demás las eligió el servidor que respondió, que es exactamente la parte que no controlamos.

Por eso la recomendación de la entrada API7 del Top 10 de APIs de OWASP y la de su guía de prevención es la misma y es poco elegante: desactivar el seguimiento automático de redirecciones en las funciones que piden direcciones de fuera. Si el negocio necesita seguirlas —algunos servicios de archivos responden con un salto antes de servir el contenido—, entonces cada salto pasa por la misma comprobación que el primero, y se cuenta.

Abre el laboratorio y lee traza-VP-4471.txt. Son cuatro saltos: el primero sale hacia el dominio que pegó quien publicó, y el último acaba en una dirección que el mapa de red marca como interna. cliente-http.php explica por qué el cliente los siguió sin preguntar.

registro-vistaprevia.log trae, por cada vista previa de la semana, el servidor que se pidió y el servidor en el que terminó. Cuenta las que no coinciden: son las que siguieron una cadena hasta otro sitio, y son la medida del hallazgo. Las que terminan donde empezaron no cuentan, responda lo que responda el servidor.

El equipo propone subir el filtro de la lista negada con más entradas para los destinos a los que llegaron esas tres vistas previas. Es la reacción natural y es la que deja el problema abierto: la cadena la escribe otro, y el filtro solo mira el primer eslabón.