Política del mismo origen - Respuesta XHR

  

Si solo evita que la página / script lea la respuesta de otro origen, ¿no podemos simplemente usar un oyente proxy como Burp o un sniffer como wireshark para capturar la respuesta antes de que llegue al navegador (donde se implementa SOP)? ?

Estos son dos tipos diferentes de ataque. La prevención de lecturas de otro origen impide que el sitio de un atacante ( evil.example.com ) que el usuario ha visitado realice una solicitud XHR al sitio en el que el usuario haya iniciado sesión ( webmail.example.com ) y obtenga los datos. En este caso, se impide que otros sitios web lean los mensajes de correo electrónico del usuario.

Si puede configurar la máquina del usuario para usar un proxy interceptor o si puede ubicar la escucha de Wireshark en modo promiscuo en la red del usuario, es probable que, como atacante, no necesite una solicitud XHR entre varios dominios, podría simplemente observar el tráfico normal. Una excepción a esto es en el caso de ataques como POODLE . Por ejemplo, si puede escuchar el tráfico a través de la red, pero la conexión del usuario se realiza al sitio web mediante SSL, es posible que deba inyectar el tráfico XHR como MITM para descifrar un byte a la vez a través del vector de ataque POODLE.

La Política del mismo origen no ayuda aquí, pero si no existiera no habría necesidad del ataque MITM ni del vector POODLE. La Política del mismo origen se defiende contra algunos ataques basados en la web que de otro modo serían posibles, nada más.

  

¿Por qué el servidor incluso responde a tales solicitudes desde otro origen? ¿No deberían responder solo cuando se habilita el Intercambio de recursos de origen cruzado (CORS) en ellos?

Sí, sería mucho más seguro si los servidores solo respondieran a las solicitudes desde sus propios orígenes. Sin embargo, esto interrumpiría la mayor parte de Internet si se implementara como estándar en las nuevas versiones de servidores web. También sería posible crear un navegador que no realizó solicitudes de origen cruzado. Nadie lo usará porque no funcionará en muchos sitios.

De hecho, puede desactivar las cookies de terceros en la mayoría de los navegadores. De hecho, esto haría que las solicitudes AJAX de origen cruzado sean anónimas, ya que nunca se enviarían cookies. Sin duda, Chrome evitará la configuración o lectura de cookies, otros navegadores solo pueden restringir la configuración de dichas cookies. Por supuesto, si se usa otro método de autenticación, como la autenticación HTTP básica, no puede ayudarlo aquí. Sin embargo, si lo intenta, en su mayor parte podrá ver qué funcionalidades se rompen.

  

¿Por qué el servidor incluso responde a tales solicitudes desde otro origen?

El encabezado del navegador Origin no se lee hasta que se analizan los encabezados, y en ese momento el navegador ya ha enviado cookies: cualquier restricción en el origen cruzado se implementaría mejor a nivel del navegador porque un servidor web no podrá bloquear el Solicitud antes de su envío.

Permitir solicitudes de origen cruzado es la forma en que las cosas han funcionado históricamente y la seguridad debe ser equilibrada con la compatibilidad. CORS se ha diseñado de tal manera que si el servidor no opta por CORS, el nivel de seguridad es el mismo que el uso de un navegador pre-CORS. Antes de CORS, era posible que los sitios realizaran solicitudes a otros dominios a través de un script, y es lo mismo ahora. Si lo piensa desde la perspectiva del servidor, una solicitud XHR GET es lo mismo que incluir una imagen de otro dominio con una etiqueta <img /> . Una solicitud XHR POST es lo mismo que crear un formulario que se envía a otro dominio.

Podría configurar su servidor para bloquear estas solicitudes (por ejemplo, usando el encabezado Origin), y esto es en realidad es una forma válida de prevenir ataques CSRF . Sin embargo, esto se debe hacer caso por caso, y se debe tener en cuenta que la presencia de este encabezado puede variar entre los navegadores y las versiones (por ejemplo, no es compatible con un navegador más antiguo).

Tenga en cuenta que esto no ayudaría en su ejemplo, ya que MITM podría, en la mayoría de los casos, simplemente falsificar el Origen.

  

¿No deberían responder solo cuando está habilitado el uso compartido de recursos de origen cruzado (CORS)?

Todos los problemas con las solicitudes de origen cruzado se han resuelto de alguna manera, como los navegadores que siguen la Política de Same Origin y los sitios web que usan tokens para evitar el CSRF. Esta es la web - insegura por defecto. Si un sitio web se desarrolla teniendo en cuenta la seguridad, estos problemas se pueden superar.

  

¿Por qué el servidor incluso responde a tales solicitudes desde otro origen? ¿No deberían responder solo cuando se habilita el Intercambio de recursos de origen cruzado (CORS) en ellos?

Para el servidor, un CORS XHR y una solicitud entre sitios activada por la inclusión del recurso (es decir, <img src= , <script src= ) o un recurso al que se accede mediante un enlace ( <a href= ) tienen un aspecto similar y no pueden ser confiables. distinguido. Esto se debe a la arquitectura existente de la web y no se puede esperar que todos los servidores cambien el comportamiento solo porque a algunas aplicaciones web les gusta usar CORS XHR.

Por lo general, tampoco es un problema si se puede acceder a un recurso de esta manera. El único problema real es si puede engañar al usuario y su navegador para que accedan a un sitio con XHR mientras está conectado a este sitio (es decir, el navegador envía una cookie de sesión), ya que entonces puede usar XHR para extraer información confidencial y reenviarla a agresor. Por lo tanto, se agrega la protección donde comienza el problema: el navegador envía la cookie de sesión al sitio externo en todas las solicitudes y, por lo tanto, el navegador debe asegurarse de que la Política de Same Origin solo se pueda debilitar (es decir, leer desde un sitio externo) si el sitio externo explícitamente aceptó, es decir, es consciente de que esta solicitud es de origen cruzado y se verificó y permitió este origen.

Las reglas de CORS XHR no ven al usuario del navegador como un posible atacante, ya que este usuario puede acceder al recurso de todos modos. En su lugar, ve a un atacante externo como el problema, que intenta extraer información de un sitio donde el usuario ha iniciado sesión. Esto es similar a CSRF, pero CSRF es solo para desencadenar acciones y no leer los resultados. Por lo tanto, no importa si el usuario mismo instaló alguna solución MITM para controlar el tráfico. Si el atacante podría instalar tal cosa, sería un peligro, pero entonces el atacante no necesitaría XHR en absoluto porque las inclusiones clásicas ( <img src= , etc.) ya serían suficientes para activar el acceso al recurso. Por lo tanto, este vector de ataque no necesita ser considerado específicamente para CORS XHR.

  

no podemos usar un oyente proxy como Burp o un sniffer como   wireshark para capturar la respuesta antes de que llegue al navegador

En primer lugar, un ataque de falsificación de solicitud entre sitios (CSRF) definitivamente no supone ni implica que el atacante pueda interceptar (MITM) la conexión de red. Si puede ser su víctima en el medio (MITM), entonces un ataque CSRF es casi redundante porque puede observar datos de autenticación (por ejemplo, cookies de sesión) e iniciar sesión usted mismo, en el mejor de los casos, un CSRF puede ser útil para causarlos. para exponer sus datos de autenticación sin tener que esperar a que visiten su sitio de destino. Sin embargo, en general, si tiene la capacidad de MITM para su víctima, tiene más vectores de ataque disponibles que un CSRF normal.

En segundo lugar, incluso si pudieras MITM a tu víctima y fuera útil observar la respuesta de una solicitud que, de otro modo, sería prevenida por SOP, la mayoría de los objetivos valiosos emplearían SSL / TLS. Esto evitará que puedas observar la respuesta, y si puedes comprometer SSL / TLS (por ejemplo, instalando un certificado de CA malicioso en su máquina), es probable que también tengas mejores vectores de ataque disponibles.

  

¿Por qué el servidor incluso responde a solicitudes de otro origen?

No es responsabilidad de los servidores web hacer cumplir el SOP y realmente solo tiene sentido en el contexto de un navegador web. Un navegador web puede estar seguro de qué página realiza qué solicitud, pero un servidor no tiene idea de qué página realiza la solicitud más que el encabezado de referencia y no hay garantías sobre la integridad de esos datos.

En cuanto a por qué un navegador permite que se realice la solicitud en primer lugar, asumo que es porque el navegador no puede evaluar el Access-Control-Allow-Origin hasta que recibe la respuesta.