Entendiendo el SOP en múltiples pestañas

  

No puedo entender cómo puede el dominio malintencionado acceder a la cuenta de Facebook desde una pestaña diferente y cómo protege SOP contra esto.

Las pestañas no son entidades aislantes. Es decir, las cookies se comparten entre todas las ventanas que tiene abierto un navegador, incluidas todas las pestañas de esas ventanas. La única excepción a esto son las ventanas privadas / de incógnito. Por lo tanto, si una pestaña abierta en evil.com hace una solicitud de AJAX a facebook.com , sus cookies de autenticación de facebook.com se enviarán junto con la solicitud. La Política del mismo origen evita que evil.com de leer la respuesta de facebook.com , ya que los dominios no coinciden.

  

El dominio malicioso puede enviar una solicitud GET / POST a facebook.com, y el navegador adjuntará una cookie para facebook, si está disponible. ¿Pero entonces el problema no se debe a la protección del lado del servidor de Facebook (escenario CSRF)? ¿Cómo ayuda SOP en este caso?

La protección CSRF solo debe evitar los métodos inseguros : acciones con efectos secundarios. Es decir:

  

se ha establecido la convención de que los métodos GET y HEAD NO DEBEN tener la importancia de realizar una acción que no sea la recuperación. Estos métodos deben considerarse "seguros". Esto permite que los agentes de usuario representen otros métodos, como POST, PUT y DELETE, de una manera especial, para que el usuario tenga conocimiento del hecho de que se está solicitando una acción insegura.

Entonces, si el sitio se ha implementado con respecto a esta convención, la protección CSRF solo debe estar activa para POST (técnicamente PUT y DELETE también, pero rara vez se utilizan).

Como se dijo, el SOP no impide que se realicen solicitudes, solo se leen las respuestas. Incluso con el SOP, evil.com podría realizar una solicitud POST a la página "Eliminar cuenta" de facebook.com , y si el usuario hubiera iniciado sesión en Facebook, se enviarían cookies.

Sin embargo, si Facebook ha implementado la protección CSRF utilizando tokens en la página Eliminar cuenta, entonces deberá enviarse un token CSRF con este POST. evil.com puede hacer una solicitud GET para facebook.com a la página que contiene el token CSRF. Sin embargo, el SOP evita que la respuesta se lea . El SOP protege los tokens CSRF de Facebook y evita que ocurran ataques CSRF cuando están protegidos por tokens.

El dominio malicioso no puede acceder a la cuenta de Facebook desde una pestaña diferente porque SOP impide que los scripts, que el navegador sabe provienen de evil.com , accedan a las propiedades y métodos de scripts procedentes de victim.com.

El problema es que, dado que HTTP no tiene estado, si un script de evil.com que se ejecuta en su navegador emita una solicitud a un servicio en victim.com, el servicio verá una solicitud proveniente de su navegador (no "a pestaña en su navegador "), y tal vez lo honraría. Para evitar esto, el sitio determina que cumplirá con la solicitud solo si se completa con un token secreto que el sitio mismo envió al navegador y que (debido al SOP) no es accesible a ninguna otra pestaña excepto a la que muestra a la víctima. sitio.

Si había SOP, pero no CSRF, y toda la información necesaria (identificación de usuario, etc.) estaba disponible para el sitio malvado, ya sea directamente o mediante un simple forzado brutal, entonces el sitio malvado podría hacer que el navegador lo enviara al servidor víctima. un comando que se cumpliría (por ejemplo, "agregue [email protected] al grupo de administradores de confianza").

Por lo tanto, podría decir que SOP es lo que hace que CSRF funcione.

Debido a la forma en que se implementa la protección CSRF (por ejemplo, como un valor de formulario oculto que establece el servidor) si un origen malvado puede leer las respuestas que recibe su navegador desde facebook.com, podría enviar un formulario a facebook el token de CSRF correcto, por lo tanto, elude cualquier protección CSRF de Facebook. Como la misma política de origen impide que otros dominios lean las respuestas de su navegador en facebook.com, este ataque no es posible de manera predeterminada.