Cabeceras de metadatos de la petición del navegador

4 tareas · 35 min · Principiante

Los navegadores actuales añaden a cada petición unas cabeceras que cuentan su contexto: si viene del mismo origen o de otro sitio, si es una navegación o una carga de recurso, y si la provocó la persona. Con ellas el servidor puede rechazar lo que no tiene sentido antes de tocar la sesión. El Fondo Pescadero dejó una política basada en esas cabeceras una semana en modo informe; se lee lo que habría bloqueado antes de activarla.

0 de 4 · 0%

Objetivo de la sala

Las cabeceras de metadatos (Fetch Metadata, especificación del W3C) son cuatro: Sec-Fetch-Site (relación entre quien inicia y el destino: same-origin, same-site, cross-site o none si la persona escribió la dirección o usó un marcador), Sec-Fetch-Mode (navigate, cors, no-cors, same-origin o websocket), Sec-Fetch-Dest (documento, imagen, script…) y Sec-Fetch-User (solo en navegaciones activadas por la persona).

El prefijo Sec- las convierte en nombres prohibidos para el código de las páginas: las pone el navegador y ningún script puede cambiarlas. Solo se envían en conexiones seguras, y un cliente que no es navegador no las manda.

Responde para continuar

¿Por qué el servidor puede fiarse del valor de Sec-Fetch-Site que envía un navegador actual?

Porque el servidor lo genera en la respuesta anterior y el navegador lo devuelve Porque viaja firmado con el certificado TLS del sitio que inició la petición Porque lo fija el navegador y el código de una página no puede modificarlo

Ver pista de ayuda

Piensa en lo que significa el prefijo Sec- para los scripts de una página.

Una política de aislamiento bien hecha rechaza las peticiones cross-site que cambian estado, pero deja pasar las navegaciones de nivel superior por GET: si no, cualquier enlace al portal desde un correo o un buscador dejaría de funcionar. Abre politica_metadatos.py y registro-informe.txt, y busca una fila legítima que la política habría bloqueado.

Responde para continuar

¿Qué petición legítima habría bloqueado la política tal como está escrita? Escribe su identificador.

Ver pista de ayuda

Busca una navegación por GET que la persona inició desde fuera del portal.

Las integraciones de servidor a servidor, las herramientas de línea de órdenes y los navegadores antiguos no envían estas cabeceras. Por eso una política así deja pasar la ausencia y se apoya, para esos clientes, en las otras defensas (token, comprobación de origen o una credencial que no viaje sola). Lo que se revisa es que esa puerta abierta esté inventariada.

Responde para continuar

¿Qué cliente del registro llega sin ninguna cabecera Sec-Fetch? Escribe su nombre tal como aparece.

Ver pista de ayuda

Busca la fila con (sin) en las columnas de metadatos.

El borrador acepta todo lo same-site con el comentario «son hosts nuestros». Ya viste con SameSite que el mismo sitio incluye a todos los hosts del dominio registrable, también los que opera un tercero. Para las acciones que cambian estado en el portal, lo más estricto que no rompe nada es aceptar solo same-origin, y abrir same-site host por host si algún servicio propio lo necesita. Cruza la fila MD-307 con dominios.txt.

Responde para continuar

¿Qué cambio propones para la regla de same-site del borrador?

Aplicarla solo a las peticiones GET y dejar que los POST sigan como están Aceptar solo same-origin en acciones que cambian estado y abrir excepciones con nombre Mantenerla, porque todos los hosts de pescadero.example pertenecen al fondo y los administra él

Ver pista de ayuda

MD-307 llegó desde un host que publica páginas de terceros.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 Cabeceras que la página no puede fingir

2 Lo que la política rompería Lab

3 El cliente sin cabeceras Lab

4 same-site no es «nuestro» Lab

Whoami-Labs Pro utiliza cookies