¿Por qué usar tanto protección CSRF como CORS?

• Al pensar en Cross-Site Request, al principio no quedaba claro por qué hacían falta tanto la protección CSRF como CORS. Pero explicarlo requiere bastantes palabras

CSRF y CORS

• CSRF (Cross-Site Request Forgery)
  • Antes era común, pero hoy casi no representa un problema porque la mayoría de los frameworks web ya incluyen protección por defecto
  • Forma de ataque: hacer que el usuario haga clic en un formulario en un sitio malicioso para inducirlo a enviar una solicitud entre sitios
  • Forma de defensa: verificar que la solicitud no provenga de otro sitio
• CORS (Cross-Origin Resource Sharing)
  • Es parte de la especificación HTTP y define cómo permitir ciertas solicitudes entre sitios
  • Usa solicitudes previas (preflight) y encabezados de respuesta para indicar desde qué orígenes (origin) se pueden enviar solicitudes

Entonces, ¿las solicitudes entre sitios están permitidas por defecto y por eso se necesita protección CSRF, o están bloqueadas por defecto y se necesita CORS para permitirlas? La respuesta es ambas.

Comportamiento básico

• Política del mismo origen (Same-origin policy)
  • Es una política de seguridad impuesta por el navegador
  • En general, permite escritura (Write) entre sitios, pero prohíbe lectura (Read)
  • Por ejemplo, el navegador permite una solicitud POST mediante formulario, pero no deja leer la respuesta
• Política de cookies SameSite
  • En 2019 cambió el comportamiento predeterminado de las cookies
  • Antes, las cookies siempre se enviaban incluso en solicitudes entre sitios
  • Se añadió el nuevo atributo SameSite, y el valor predeterminado cambió a Lax
  • A partir de 2025, 96% de los navegadores admiten el atributo SameSite y 75% admiten el nuevo valor predeterminado (Lax)
  • Sin embargo, Safari no lo aplicó como valor predeterminado y UCBrowser todavía no lo soporta
• Diferencia entre sitio (Site) y origen (Origin)
  • Origen (Origin): combinación de protocolo + nombre de host + puerto
  • Sitio (Site): combinación de protocolo + dominio de nivel superior + 1 (se ignoran subdominios y puertos)

CORS

• CORS es una forma de permitir excepciones a la política del mismo origen para ciertos orígenes (origin)
• Antes de enviar la solicitud, el navegador manda una solicitud previa (preflight request) de tipo OPTIONS
• El servidor define las reglas permitidas mediante encabezados de respuesta (usando encabezados Access-Control-*)
• Tipos de solicitudes a las que se aplica CORS:
  • fetch y XMLHttpRequest
  • fuentes web
  • texturas de WebGL
  • imágenes/cuadros de video dibujados con drawImage en canvas
  • imágenes usadas en la propiedad CSS shape-outside
• Sin embargo, el envío de formularios es una excepción y CORS no se aplica
  • La etiqueta <form> de HTML 4.0 ha permitido solicitudes entre sitios desde hace mucho tiempo
  • Por eso, los servidores existentes ya deberían haber sido diseñados para defenderse de ataques CSRF
  • El servidor debe configurar Access-Control-Allow-Origin si quiere compartir la respuesta, pero la solicitud en sí se acepta incluso sin solicitud previa

Pregunta: ¿Cómo mantiene coherencia este enfoque con la política SameSite?

Métodos de protección CSRF

• Las solicitudes de escritura entre sitios están permitidas, pero la respuesta no se comparte
  • La mayoría de los sitios web no quieren permitir escritura entre sitios
• Método estándar de defensa CSRF
  • Incluir y validar un token CSRF por usuario en la solicitud
  • Método:
    • Envío de formularios: agregar el token en un campo oculto (hidden input)
    • Solicitudes JS: guardarlo en una cookie o en una etiqueta meta, y luego incluirlo en el encabezado o en los parámetros de la solicitud
• Las solicitudes JS originalmente están bloqueadas entre sitios por defecto
  • Pero sí están permitidas en solicitudes del mismo sitio (same-site request)
  • Si se incluye un token CSRF, es posible validar todas las solicitudes del mismo modo
• Ventajas adicionales de seguridad
  • Funciona bajo la premisa de que el navegador debe bloquear por defecto la lectura de la respuesta
  • Es más seguro que revisar el encabezado Origin

Pregunta: En algunos frameworks, los tokens CSRF cambian periódicamente. ¿Por qué?

El papel del navegador

• El punto clave de la seguridad web depende de si se puede confiar en el navegador
• El navegador:
  • aplica la política del mismo origen
  • bloquea la lectura si la respuesta no está permitida
  • decide si aplica el valor predeterminado SameSite=Lax
  • implementa CORS y envía solicitudes previas seguras

Debemos confiar en el navegador que estamos usando.

Conclusión

• Si SameSite=Lax fuera compatible en 100% de los navegadores, la seguridad se reforzaría aún más, pero
  por ahora sigue existiendo la excepción de permitir únicamente solicitudes POST entre sitios
• Por lo tanto, los desarrolladores deben seguir teniendo en cuenta la protección CSRF

"Internet se vuelve cada vez más seguro, pero al mismo tiempo la compatibilidad con el pasado se reduce cada vez más."

Fuente

1. Same-origin policy
2. caniuse SameSite cookie attribute
3. OWASP CSRF cheatsheet
4. CORS wiki with requirements
5. CORS spec
6. CORS on MDN
7. Preflight request
8. Origin request header
9. Origin and Site

[GN⁺]

Opiniones de Hacker News

• CORS es un mecanismo mediante el cual el servidor le indica explícitamente al navegador qué solicitudes de origen cruzado pueden leer la respuesta

  • Por defecto, el navegador bloquea que un script de origen cruzado lea la respuesta
  • A menos que se permita explícitamente, el dominio que hace la solicitud no puede leer la respuesta
  • Por ejemplo, un script en evil.com podría enviar una solicitud a bank.com/transactions para intentar leer el historial de transacciones de la víctima
  • El navegador permite que la solicitud llegue a bank.com, pero bloquea que evil.com lea la respuesta

• La protección CSRF evita que solicitudes maliciosas de origen cruzado realicen acciones no autorizadas en nombre de un usuario autenticado

  • Por ejemplo, un script en evil.com puede enviar una solicitud para ejecutar una acción en bank.com (por ejemplo, transferir dinero a través de bank.com/transfer?from=victim&to=hacker)
  • La protección CSRF del lado del servidor en bank.com la rechaza (probablemente porque la solicitud no incluye un token CSRF secreto)

• La protección CSRF tiene que ver con proteger escrituras, mientras que CORS tiene que ver con proteger lecturas

• Las solicitudes iniciadas por JS no permiten cross-site por defecto

  • Se puede iniciar una solicitud cross-site con fetch() si se usan solo los headers permitidos

• Creo que hay una mejor explicación sobre este tema

  • Se proporciona un enlace a un blog relacionado

• Respuesta a la pregunta de la publicación del blog

  • El elemento <form> de HTML 4.0 puede enviar solicitudes simples a cualquier origen
  • Hubo una pregunta sobre cómo encaja esto con la iniciativa SameSite

• En 2022 se agregó un párrafo al artículo de CORS en MDN para aclarar el origen del término "solicitudes simples"

  • Antes, solo decía que no se mencionaba en la especificación de fetch
  • En 2019 no había ninguna mención a los casos en que las funciones de prevención de CSRF del navegador admiten SameSite=Lax o lo establecen como valor predeterminado

• Es confuso que SameSite se haya agregado de forma independiente al preflight de CORS

  • Me pregunto por qué los fabricantes de navegadores no exigieron preflight para todas las solicitudes POST de origen cruzado

• Se puede pensar que es seguro no usar csrf, pero algunas librerías (por ejemplo, django rest framework) pueden procesar formularios HTML si se establece el header de content type

  • Esto permite publicar un formulario en el sitio del usuario para enviar solicitudes en su nombre

• Pregunta sobre por qué se rotan los tokens CSRF

  • OWASP dice que esto es más seguro, pero no tengo claro el motivo

• Se pide un diagrama de flujo para este tema complejo

  • Quieren una nueva plataforma de aplicaciones y un nuevo conjunto de estándares

• Estas cosas no facilitan el rastreo de diagnóstico

  • He tenido varias veces errores opacos en casos de uso legítimos mal configurados

• No entiendo por qué antes de que existiera CORS se podía enviar una solicitud a un endpoint arbitrario distinto del origen de la página, pero no ver la respuesta

  • Me pregunto si esto quedó en la especificación por accidente, si fue algo intencional anticipando XSS, o si un navegador dominante lo hizo así y los demás simplemente lo siguieron

• Confusión sobre la protección CSRF

  • Se pregunta qué impediría que un atacante obtenga un token CSRF de goodsite.com, lo ponga en badsite.com y engañe a Alice para que envíe desde badsite.com una solicitud a goodsite.com