¿Cómo se correlaciona CSRF con la política del mismo origen?

Comencemos por definir el término origen. El origen de una página se decide por tres factores únicos: nombre de host, protocolo y número de puerto. Por ejemplo, http://test.com y https://test.com tienen orígenes diferentes ya que el protocolo es diferente. De manera similar, http://one.test.com y http://two.test.com tienen orígenes diferentes, ya que los nombres de host son diferentes. La propiedad de origen también es diferente para dos servicios que se ejecutan en el mismo host con diferentes números de puerto, por ejemplo. http://test.com:8081 y http://test.com:8082 se consideran diferentes orígenes.

Same Origin Policy (SOP) es un control de seguridad a nivel de navegador que determina cómo un documento o script que pertenece a un origen puede interactuar con recursos de otro origen. Básicamente, evita que los scripts que se ejecutan en un origen puedan leer datos de otro origen .

Las solicitudes de dominios cruzados y los envíos de formularios todavía están permitidos, pero no se permite la lectura de datos de otro origen. Esto significa que si está realizando un ataque CSRF en un sitio vulnerable que provoca un cambio de estado en el lado del servidor (por ejemplo, la creación de un usuario, la eliminación de documentos, etc.), el ataque tendrá éxito pero no podrá leer la respuesta.

En resumen, el SOP solo impide leer datos que se sirvieron desde un origen diferente. No cubre los envíos de formularios de dominios cruzados que se utilizan para llevar a cabo un ataque CSRF.

En lo que respecta a la realización de comunicación entre dominios utilizando AJAX, existen algunos otros controles de seguridad que dictan la comunicación. Consulte Intercambio de recursos de origen cruzado . CORS permite que diferentes orígenes se comuniquen y compartan datos de una manera controlada y una mala configuración de CORS también puede dar como resultado vulnerabilidades de seguridad .

Tenga en cuenta que SOP no impide que los recursos alojados en diferentes dominios se incrusten en una página mediante el uso de etiquetas de script, CSS y etiquetas de imagen. Si bien esto podría no permitir una lectura directa de los contenidos, los efectos secundarios de la carga y la representación se pueden usar para determinar (partes de) el contenido. Tenga en cuenta también que los SOPs web no están cubiertos por SOP en absoluto y, por lo tanto, es posible la lectura entre sitios.

P.S. Tomado de mi blog .

  

Same Origin Policy (SOP) conserva los datos de otros dominios ...

Hay dos partes en el SOP:

1. Impide que los scripts en el origen A lean datos del origen B.
2. Evita que los sitios en el origen A envíen cualquier solicitud, excepto las llamadas solicitudes "simples" al origen B. Las solicitudes simples se limitan a GET y POST, y solo se pueden modificar algunos encabezados.

  

... y, por lo tanto, anula el uso de CSRF.

El SOP no protege contra CSRF. ¿Por qué?

1. Un ataque CSRF se realiza enviando una solicitud y no leyendo nada de la respuesta. De hecho, no puede ni necesita leer la respuesta.
2. Normalmente utilizarías solicitudes simples en un ataque CSRF.

Como puede ver, las limitaciones mencionadas anteriormente que implementa el SOP no evitan los ataques CSRF.

  

Ahora, considerando que la misma política de origen solo se aplica a XMLHTTPRequest ...

No, no lo hace. Se aplica a todos los datos que maneja un navegador. Si usa XMLHTTPRequest, una forma ordinaria o la API de recuperación es irrelevante. Se aplican las mismas restricciones.

  

... así que con una forma ingeniosamente diseñada, puedo hacer una solicitud POST que anule el SOP y, por lo tanto, la necesidad de tokens CSRF.

Con un formulario diseñado de forma inteligente, puede realizar una solicitud POST que ejecute un ataque CSRF, sí. Y es por eso que necesita protección especial, como los tokens CSRF.

  

Ahora, con todo esto, ¿CSRF trabaja alrededor del SOP o trabaja a través de él?

No estoy seguro de lo que significaría "trabajar alrededor" o "trabajar a través de" el SOP. En cambio, permítame decir esto: CSRF es posible porque los navegadores le permiten enviar solicitudes POST de origen cruzado.

Un sitio A puede provocar una solicitud al sitio B diferente de varias maneras, por ejemplo, al incluir una imagen del sitio B dentro del HTML del sitio A (es decir, <img src=http://B/... >) o hacer cosas similares con formularios o Javascript o redirecciones HTTP. Las solicitudes que se inician desde un sitio pero se dirigen a otro sitio se denominan solicitudes entre sitios.

Falsificación de solicitudes entre sitios (CSRF) significa que una solicitud entre sitios puede ser mal utilizada. Este suele ser el caso porque una cookie de sesión existente de una conexión anterior al sitio B se envía a cada solicitud en este sitio, incluso si la solicitud se inicia desde el sitio A, es decir, entre sitios. Esto significa que la solicitud se ejecuta con la identidad del usuario registrado en el lado B. Un ataque CSRF exitoso significa que dicha solicitud entre sitios puede causar daño, por ejemplo, por cambiando la configuración de DNS en un enrutador vulnerable a CSRF .

La Política del mismo origen (SOP) no hace que CSRF sea imposible, pero de alguna manera limita el impacto de CSRF en que la solicitud se envía al sitio B, pero el atacante no puede ver el resultado devuelto por el servidor del sitio B. Por lo tanto, SOP hace que CSRF sea de solo escritura, es decir, CSRF se puede usar para ejecutar acciones no deseadas, pero no se puede usar solo para exfiltrar datos del sitio B. Por ejemplo, un atacante externo podría usar una vulnerabilidad CSRF en una empresa interna Wiki para crear una nueva publicar en el nombre de un usuario existente o eliminar una publicación, pero debido a SOP no puede leer el contenido de la Wiki interna y enviarlo de vuelta al atacante externo.

Tenga en cuenta que no todas las comunicaciones entre sitios están restringidas por el SOP. Notablemente Los websockets no están restringidos y, por lo tanto, es posible que un atacante en el sitio A use un navegador como trampolín para comunicarse completamente con un Websocket en el sitio B con los permisos del usuario registrado, es decir, tanto escribir como leer datos.