XUT_ / COURSES / PENETRATION TESTER

Understanding CORS

Courses/Penetration Tester/web application pentesting/advanced client side attacks/cors sop

Compartición de Recursos Cross-Origin

Cross-Origin Resource Sharing (CORS) es un mecanismo definido por headers HTTP que permite a los servidores especificar cómo los recursos pueden ser pedidos desde diferentes orígenes. Mientras que SOP restringe las páginas por defecto para que sólo puedan hacer peticiones desde el mismo dominio, CORS permite a los servidores declarar excepciones a esta política.

CORS opera a través de headers HTTP configurados que el servidor manda como parte de su respuesta al navegador. Estos headers informan al navegador sobre la política CORS del servidor, como qué orígenes son permitidos para acceder a los recursos, qué métodos HTTP están permitidos y si las credenciales deben ser incluidas en la petición. Es importante tener en cuenta que el servidor no bloquea o permite basado en CORS, sino que procesa la petición e incluye dichos headers CORS en la respuesta. El navegador lo interpreta y fuerza la política dando o denegando acceso al JavaScript de la página para acceder a la respuesta.

Diferentes Headers HTTP Involucrados en CORS

  1. Access-Control-Allow-Origin: Este header especifica los dominios que tienen permitido acceder a recursos. Por ejemplo: Access-Control-Allow-Origin: example.com permite sólo peticiones de example.com.
  2. Access-Control-Allow-Methods: Especifica los métodos HTTP (GET, POST, etc.) que pueden ser usados durante la petición.
  3. Access-Control-Allow-Headers: Indica qué headers HTTP pueden ser usados durante la petición real.
  4. Access-Control-Max-Age: Define cuánto tiempo los resultados de una petición preflight pueden ser cacheados.
  5. Access-Control-Allow-Credentials: Este header le indica al navegador si exponer la respuesta al código JavaScript del frontend cuando hay credenciales como cookies, autentificación HTTP o certificados SSL en la petición. No se puede configurar como * y hay que especificar el dominio exacto por seguridad.

Escenarios Comunes Donde se Aplica CORS

CORS suele aplicarse en escenarios como:

  1. APIs y Servicios Web: Cuando una aplicación web de un dominio necesita acceder a una API hosteada en un dominio diferente, CORS permite esta interacción.
  2. Redes de Entrega de Contenido (CDNs): Muchos sitios web usan CDNs para cargar librerías como jQuery o fuentes.
  3. Web Fonts: Para que las fuentes web sean usadas a lo largo de diferentes dominios, los headers CORS deben estar configurados, permitiendo a las webs cargar fuentes de una localización centralizada.
  4. Plugins/Widgets de Terceros: Para permitir funcionalidades como botones de redes sociales o chatbots de terceros en una página web.
  5. Autentificación de Usuario Multi-Dominio: Servicios que ofrecen single sign-on (SSO) o usan tokens (como OAuth) para autentificar a usuarios a lo largo de varios dominios.

Peticiones Simple vs Peticiones Preflight

Hay dos tipos principales de peticiones en CORS: peticiones simple y peticiones preflight.

  1. Simple Requests: Estas peticiones cumplen ciertos criterios configurados por CORS que las hacen "simple". Son tratados de forma similar a las peticiones same-origin, con algunas restricciones. Una petición es considerada simple si usa GET, HEAD o POST y el header Content-Type de la petición POST es uno de application/x-www-form-urlencoded, multipart/form-data o text/plain. Además, la petición no debería incluir headers personalizados que no sean CORS-safe. Estas peticiones se mandan directamente al servidor con el header Origin y la respuesta está sujeta a la política CORS basada en el header Access-Control-Allow-Origin. Además, cookies y autentificación HTTP son incluidas en estas peticiones si la página ya las ha configurado aunque el header Access-Control-Allow-Credentials sea true.
  2. Preflight Requests: Estas son peticiones CORS que el navegador pre-manda con OPTIONS antes de mandar la petición real para asegurar que el servidor aceptará la petición basado en su política CORS. Se dispara cuando una petición no se califica como simple, como cuando usamos métodos HTTP distintos de GET, HEAD o POST o cuando las peticiones POST están hechas con header Content-Type diferente que el valor permitido para peticiones simples o cuando se incluyen headers personalizados. La petición preflight incluye headers como Allow-Control-Request-Method o Access-Control-Request-Headers, indicando el método y headers personalizados de la petición real. El servidor debe responder con headers CORS apropiados, como Access-Control-Allow-Methods, Access-Control-Allow-Headers y Access-Control-Allow-Origin para indicar que se permite la petición real. Si la petición preflight resulta exitosa, el navegador mandará la petición real con las credenciales incluidas si Access-Control-Allow-Credentials está en true.

Procesado de una Petición CORS

Understanding CORS

La tabla de flujo superior muestra el procesado básico de una petición CORS.

  1. El navegador manda una petición HTTP al servidor.
  2. El servidor comprueba si el header Origin está en la lista de orígenes permitidos.
  3. Si el origen está permitido, el servidor responde con el header Access-Control-Allow-Origin apropiado.
  4. El navegador bloqueará la petición cross-origin si el origen no está permitido.