¿Cuáles son los riesgos de seguridad al usar XMLHttpRequest entre dominios?

Question

En muchos lugares he visto personas que han hablado sobre CrossHealth XMLHttpRequest, que no es posible, debido a algunas razones de seguridad . Sin embargo, no he encontrado una publicación que indique cuáles son realmente los motivos de seguridad ?

Las personas han mencionado que JSONP es una de las buenas alternativas. Otra alternativa sería usar los encabezados Origin y Access-Control-Allow-Origin.

Sin embargo, solo quiero saber qué problemas de seguridad pueden surgir debido al uso de uso de XMLHttpRequest entre dominios.

Answer 1

Creo que sería mejor responder a su pregunta de un ejemplo de por qué sería horrendamente malo.

Usted va a mi sitio web (example.org). Cargué un script que hace una solicitud AJAX del lado del cliente a facebook.com/messages/from/yourgirlfriend. Por casualidad, usted inició sesión en Facebook, y su navegador le dice a Facebook que mi pedido es en realidad usted. Facebook felizmente le da a mi pedido ese mensaje sobre las extrañas cosas sexuales que quieres probar. Ahora sé cosas sobre ti que probablemente no querías que yo supiera.

Esto, por supuesto, es una exageración salvaje, y afortunadamente no es posible gracias a la misma política de origen.

¿No te sientes más seguro ahora?

Answer 2

Si se permite, un atacante que logre inyectar Javascript en su página (a través de exploit/social-engineering) puede enviar datos (generalmente sensibles) que son adquiridos de sus clientes sin que lo sepan (ya que XMLHttpRequests no requieren las acciones del usuario que se producen y están en silencio). Es una medida de seguridad del navegador.

JSONP es solo un trabajo en torno a esta medida de seguridad, donde le das una devolución de llamada al destino y les confías todo lo que te devolverán a través de esta devolución de llamada.

EDITAR: Ejemplos de un riesgo de seguridad: inicia sesión en su cuenta de correo electrónico a través de la web (como gmail o yahoo). Continúa navegando (en otra pestaña o incluso en la pestaña actual) a otro sitio malicioso. Este sitio malicioso intenta hacer XHR en el mismo sitio web de su cuenta de correo electrónico. Dado que el XHR está en su comportamiento, y dado que es una solicitud del cliente/del lado del navegador, esta solicitud tendrá la misma sesión que usó para iniciar sesión, y por lo tanto, este sitio web puede hacer lo que quiera con su cuenta (envíe un correo no deseado su cuenta, descargue sus contactos, ... etc.). Otro ejemplo: en un foro, alguien logra inyectar Javascript con XHR a otro sitio web. Ahora puede robar la lista de contactos (y tal vez luego eliminarlos) de todas las personas que visitan su publicación en el foro (usando la misma sesión de su correo electrónico web). Sin mencionar que puede compartir la sesión de los miembros del foro visitando su publicación para obtener cualquier información que tengan en el foro (mensajes privados/amigos, etc.). Luego puede enviar estos datos a su servidor para guardarlos.

Answer 3

Sin estas "razones de seguridad", toda la Internet como la conoce no podría existir. De hecho, voy a salir en una extremidad y decir que es ninguna regla que es más importante para la seguridad de Internet que la política de origen mismo.

Ninguna página web podría tener autenticación sin estas reglas, google, cuentas de correo web, SO, nada de esto podría existir. Sería como si tuviera XSS en cada dominio. Puede realizar un XHR contra gmail.com y leer el correo electrónico de cualquier persona. Los tokens CSRF no funcionarían porque podría leer cualquier página y falsificar la solicitud.

No existe una política de origen único, pero las reglas están claramente establecidas en el Google Browser Security handbook. Estos son muy lógicos, y las reglas para las diversas plataformas son muy similares, porque así es como debe funcionar en Internet.

Al hacer un Access-Control-Allow-Origin: * usted está renunciando a los derechos que le otorgan los navegadores web para esa página. Esto tiene principales implicaciones de seguridad. No podrá protegerse del CSRF utilizando tokens. Un capthca podría mitigar este problema, también verificando que el referer también podría ayudar (estará en blanco si el origen es HTTPS). Deberías leer el CSRF prevention cheat sheet.