Evite las fugas de información CSRF, XSSI y de origen cruzado.
Actualizado
Seguro y a salvo
¿Por qué debería preocuparse por aislar sus recursos web?
Muchas aplicaciones web son vulnerables a ataques de origen cruzado como falsificación de solicitud entre sitios (CSRF), inclusión de secuencias de comandos entre sitios (XSSI), ataques de tiempo, fugas de información de origen cruzado o canal lateral de ejecución especulativa (Espectro) ataques.
Obtener metadatos Los encabezados de solicitud le permiten implementar un sólido mecanismo de defensa en profundidad, una política de aislamiento de recursos, para proteger su aplicación contra estos ataques comunes de origen cruzado.
Es común que los recursos expuestos por una determinada aplicación web solo los cargue la propia aplicación y no otros sitios web. En tales casos, la implementación de una política de aislamiento de recursos basada en los encabezados de solicitud de obtención de metadatos requiere poco esfuerzo y, al mismo tiempo, protege la aplicación de ataques entre sitios.
Compatibilidad del navegador
Los encabezados de solicitud de obtención de metadatos se admiten a partir de Chrome 76 y en otros navegadores basados en Chromium, y están en desarrollo en Firefox. Ver Compatibilidad del navegador para obtener información actualizada sobre compatibilidad con el navegador.
Antecedentes
Muchos ataques entre sitios son posibles porque la web está abierta de forma predeterminada y su servidor de aplicaciones no puede protegerse fácilmente de la comunicación que se origina en aplicaciones externas. Un ataque típico de origen cruzado es la falsificación de solicitudes entre sitios (CSRF), en la que un atacante atrae a un usuario a un sitio que controla y luego envía un formulario al servidor en el que el usuario está conectado. Dado que el servidor no puede saber si la solicitud se originó en otro dominio (entre sitios) y el navegador adjunta automáticamente cookies a las solicitudes entre sitios, el servidor ejecutará la acción solicitada por el atacante en nombre del usuario.
Otros ataques entre sitios, como la inclusión de scripts entre sitios (XSSI) o las fugas de información de origen cruzado, son de naturaleza similar a CSRF y dependen de la carga de recursos de una aplicación de la víctima en un documento controlado por el atacante y de la filtración de información sobre las aplicaciones de la víctima. Dado que las aplicaciones no pueden distinguir fácilmente las solicitudes confiables de las no confiables, no pueden descartar el tráfico malicioso entre sitios.
Aparte de los ataques a los recursos descritos anteriormente, referencias de ventana también puede provocar fugas de información de origen cruzado y ataques Spectre. Puede prevenirlos configurando el Cross-Origin-Opener-Policy encabezado de respuesta a same-origin.
Presentación de Fetch Metadata
Los encabezados de solicitud de Fetch Metadata son una nueva característica de seguridad de la plataforma web diseñada para ayudar a los servidores a defenderse contra ataques de origen cruzado. Al proporcionar información sobre el contexto de una solicitud HTTP en un conjunto de Sec-Fetch-* encabezados, permiten al servidor que responde aplicar políticas de seguridad antes de procesar la solicitud. Esto permite a los desarrolladores decidir si aceptan o rechazan una solicitud en función de la forma en que se realizó y el contexto en el que se utilizará, lo que permite responder solo a solicitudes legítimas realizadas por su propia aplicación.
Mismo origen
Las solicitudes que se originen en sitios atendidos por su propio servidor (mismo origen) seguirán funcionando.
Cross-site
El servidor puede rechazar solicitudes maliciosas entre sitios debido al contexto adicional en la solicitud HTTP proporcionada por Sec-Fetch-* encabezados.
Sec-Fetch-Site
Sec-Fetch-Site le dice al servidor qué sitio envió la solicitud. El navegador establece este valor en uno de los siguientes:
same-origin, si la solicitud la realizó su propia aplicación (p. ej.site.example)same-site, si la solicitud fue realizada por un subdominio de su sitio (p. ej.bar.site.example)none, si la solicitud fue causada explícitamente por la interacción de un usuario con el agente de usuario (por ejemplo, al hacer clic en un marcador)cross-site, si la solicitud fue enviada por otro sitio web (p. ej.evil.example)
Sec-Fetch-Mode
Sec-Fetch-Mode indica el modo de la solicitud. Esto corresponde aproximadamente al tipo de solicitud y le permite distinguir las cargas de recursos de las solicitudes de navegación. Por ejemplo, un destino de navigate indica una solicitud de navegación de nivel superior mientras no-cors indica solicitudes de recursos como cargar una imagen.
Sec-Fetch-Dest
Sec-Fetch-Dest expone una solicitud destino (por ejemplo, si un script o un img provocó que el navegador solicitara un recurso).
La información adicional que brindan estos encabezados de solicitud es bastante simple, pero el contexto adicional le permite construir una lógica de seguridad poderosa en el lado del servidor, también conocida como Política de Aislamiento de Recursos, con solo unas pocas líneas de código.
Implementar una política de aislamiento de recursos
Una política de aislamiento de recursos evita que sus recursos sean solicitados por sitios web externos. El bloqueo de dicho tráfico mitiga las vulnerabilidades web comunes entre sitios, como CSRF, XSSI, ataques de tiempo y fugas de información de origen cruzado. Esta política se puede habilitar para todos los puntos finales de su aplicación y permitirá todas las solicitudes de recursos provenientes de su propia aplicación, así como navegaciones directas (a través de un HTTP GET solicitud). Los puntos finales que se supone deben cargarse en un contexto entre sitios (por ejemplo, puntos finales cargados mediante CORS) pueden excluirse de esta lógica.
Paso 1: Permitir solicitudes de navegadores que no envían Fetch Metadata
Dado que no todos los navegadores admiten la obtención de metadatos, debe permitir solicitudes que no se establezcan Sec-Fetch-* encabezados comprobando la presencia de sec-fetch-site.
Todos los siguientes ejemplos son código python.
if not req['sec-fetch-site']:
return True Precaución:
Dado que Fetch Metadata solo es compatible con los navegadores modernos, debe usarse como un protección de defensa en profundidad y no como su principal línea de defensa.
Paso 2: Permitir solicitudes iniciadas en el mismo sitio y en el navegador
Cualquier solicitud que no se origine en un contexto de origen cruzado (como evil.example) será permitido. En particular, se trata de solicitudes que:
- Procede de su propia aplicación (por ejemplo, una solicitud del mismo origen donde
site.examplepeticionessite.example/foo.jsonsiempre se permitirá). - Procede de tus subdominios.
- Son causados explícitamente por la interacción de un usuario con el agente de usuario (por ejemplo, navegación directa o al hacer clic en un marcador, etc.).
if req['sec-fetch-site'] in ('same-origin', 'same-site', 'none'):
return True En caso de que sus subdominios no sean completamente confiables, puede hacer que la política sea más estricta bloqueando las solicitudes de los subdominios eliminando el same-site valor.
Paso 3: Permita la navegación e iframing de nivel superior simples
Para asegurarse de que su sitio aún pueda estar vinculado desde otros sitios, debe permitir simples (HTTP GET) navegación de nivel superior.
if req['sec-fetch-mode'] == 'navigate' and req.method == 'GET'
and req['sec-fetch-dest'] not in ('object', 'embed'):
return True La lógica anterior protege los puntos finales de su aplicación para que no sean utilizados como recursos por otros sitios web, pero permitirá la navegación e incrustación de nivel superior (por ejemplo, cargar en un
