enable - habilitar cors

La política del mismo origen y CORS: ¿cuál es el punto?

Question

Tengo algunos problemas para entender la política del mismo origen y las diferentes formas de "solucionarlo".

Está claro que la política del mismo origen existe como medida de seguridad, por lo que una secuencia de comandos que proviene de un servidor / dominio no tiene acceso a los datos provenientes de otro servidor / dominio.

También está claro que a veces es útil poder romper esta regla, por lo que, por ejemplo, una aplicación de mashup accede a la información de diferentes servidores para acumular los resultados deseados. Y una de las maneras de hacer esto es CORS.

1) Si no estoy equivocado, CORS permite que el servidor de destino le diga al navegador " está bien que usted tome datos / código de mí mismo " agregando algunos encabezados en la respuesta. Pero, si esto es correcto, esto significa que un servidor malintencionado podría simplemente agregar este encabezado y el navegador permitiría recuperar cualquier dato o código, potencialmente dañino, proveniente de ese servidor.

2) En el otro lado, tenemos JSONP, que nos permite recuperar código o datos arbitrarios de un servidor sin CORS habilitado, evitando así el objetivo principal del SOP. Entonces, de nuevo, un servidor malintencionado capaz de administrar JSONP puede inyectar datos o códigos incluso con el SOP cableado en el navegador.

Así que mis preguntas son:

¿Es correcta la segunda argumentación? ¿Es la decisión del servidor si el navegador debe aceptar los contenidos? ¿Es correcta la segunda argumentación? Es, una vez más, no está en la decisión del navegador si aceptar o no datos?

¿JSONP no hace inútil el SOP?

Gracias por iluminarme !!

Answer 1

Lo importante a tener en cuenta aquí es que si el usuario ha iniciado sesión en un sitio http://example.com/ y la solicitud http://example.com/delete?id=1 elimina una publicación del usuario, entonces el El siguiente código eliminará la publicación del usuario:

<script src="http://example.com/delete?id=1" />

Esto se denomina ataque CSRF / XSRF (falsificación de solicitud entre sitios). Esta es la razón por la que la mayoría de las aplicaciones web del lado del servidor exigen un ticket de transacción: en lugar de http://example.com/delete?id=1 , tiene que hacer http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess

Ahora el siguiente ataque no funcionará:

<script src="http://example.com/delete?id=1" />

... porque no contiene el parámetro txid. Ahora, consideremos qué sucede si se puede acceder al sitio utilizando XmlHttpRequest. La secuencia de comandos que se ejecuta en el navegador del usuario podría detrás del usuario recuperar y analizar http://example.com/pageThatContainsDeleteLink , extraer el txid y luego solicitar http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess

Ahora, si XmlHttpRequest no puede acceder a sitios que tienen un origen diferente, la única manera de intentar recuperar el txid sería intentar hacer algo como:

<script src="http://example.com/pageThatContainsDeleteLink" />

... pero no ayuda porque el resultado es una página HTML, no un fragmento de código JavaScript. Por lo tanto, hay una razón por la cual puede incluir <script>: s de otros sitios pero no acceder a otros sitios a través de XmlHttpRequest.

Quizás te interese leer esto: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/

Este ataque funcionó contra Gmail en el pasado y le permitió recuperar los correos del usuario del código JavaScript que se ejecuta en otro sitio. Todo esto demuestra que el modelo de seguridad de WWW es muy sutil y no está bien pensado. Ha evolucionado en lugar de estar bien diseñado.

En cuanto a su pregunta: parece pensar que el servidor http://example.com/ es el malicioso. Ese no es el caso. Usando las anotaciones de mi respuesta, http://example.com/ es el servidor que es el objetivo del ataque, y http://attacker.com/ es el sitio del atacante. Si http://example.com/ abre la posibilidad de enviar solicitudes utilizando JSONP o CORS, es cierto que puede volverse vulnerable al ataque CSRF / XSRF que acabo de describir. Pero esto no significa que otros sitios se vuelvan vulnerables al ataque. De manera similar, si http://attacker.com/ abre la posibilidad de enviar solicitudes utilizando JSONP o CORS, el sitio del atacante simplemente se volvió vulnerable a un ataque CSRF / XSRF. Por lo tanto, un administrador de servidor mal informado puede abrir un agujero en su propio sitio, pero esto no afecta la seguridad de otros sitios.