javascript - has - Intercambio de recursos de origen cruzado(CORS): ¿me estoy perdiendo algo aquí?

xmlhttprequest access-control-allow-origin (6)

Pero, ¿qué sucede si el código malicioso en la página quiere POSTAR la información confidencial de un usuario a un sitio extranjero?

Que hay de eso Ya puedes hacer eso sin CORS. Incluso hasta Netscape 2, siempre ha podido transferir información a cualquier sitio de terceros a través de simples solicitudes GET y POST causadas por interfaces tan simples como form.submit() , new Image o configuración window.location .

Si el código malicioso tiene acceso a información confidencial, ya lo ha perdido totalmente.

3) La página desea realizar una solicitud XHR a maliciosas.com: solicitud rechazada localmente

¿Por qué una página intentaría realizar una solicitud XHR a un sitio que aún no ha incluido en la lista blanca?

Si está tratando de protegerse contra las acciones de un script malicioso inyectado debido a las vulnerabilidades de XSS, está intentando corregir el síntoma, no la causa.

Estaba leyendo sobre CORS y creo que la implementación es simple y efectiva.

Sin embargo, a menos que me esté perdiendo algo, creo que hay una gran parte que falta en la especificación. Según tengo entendido, es el sitio extranjero el que decide, en función del origen de la solicitud (y, opcionalmente, incluir las credenciales), si permitir el acceso a sus recursos. Esto esta bien.

Pero, ¿qué sucede si el código malicioso en la página quiere POSTAR la información confidencial de un usuario a un sitio extranjero? El sitio extranjero obviamente va a autenticar la solicitud. Por lo tanto, nuevamente, si no me falta algo, CORS en realidad hace que sea más fácil robar información confidencial.

Creo que tendría mucho más sentido si el sitio original también pudiera proporcionar una lista inmutable de servidores a los que su página tiene acceso.

Entonces la secuencia expandida sería:

Suministre una página con la lista de servidores CORS aceptables (abc.com, xyz.com, etc.)
Page quiere hacer una solicitud de XHR a abc.com: el navegador lo permite porque está en la lista de permitidos y la autenticación se realiza normalmente.
La página desea realizar una solicitud XHR a malicioso.com: solicitud rechazada localmente (es decir, por el navegador) porque el servidor no está en la lista.

Sé que el código malicioso todavía podría usar JSONP para hacer su trabajo sucio, pero habría pensado que una implementación completa de CORS implicaría el cierre de la brecha de múltiples sitios de la etiqueta de script.

También revisé las especificaciones oficiales de CORS ( http://www.w3.org/TR/cors ) y no pude encontrar ninguna mención de este problema.

Comparto las preocupaciones de David. La seguridad se debe construir capa por capa y una lista blanca servida por el servidor de origen parece ser un buen enfoque.

Además, esta lista blanca se puede usar para cerrar las lagunas existentes (formularios, etiquetas de script, etc.), es seguro asumir que un servidor que sirve la lista blanca está diseñado para evitar problemas de compatibilidad.

El problema no es que un sitio pueda acceder a los recursos de otros sitios a los que ya tenía acceso. El problema es uno de los dominios: si estoy usando un navegador en mi empresa y un script ajax decide de forma malintencionada probar 10.0.0.1 (potencialmente mi puerta de enlace), puede tener acceso simplemente porque la solicitud ahora proviene de mi computadora (tal vez 10.0.0.2).

Así que la solución - CORS. No estoy diciendo que sea lo mejor, pero se resuelve este problema.

1) Si la puerta de enlace no puede devolver el encabezado de origen aceptado ''bobthehacker.com'', la solicitud es rechazada por el navegador . Esto maneja servidores viejos o desprevenidos.

2) Si la puerta de enlace solo permite elementos del dominio myinternaldomain.com, rechazará un ORIGEN de ''bobthehacker.com''. En el caso de SIMPLE CORS, todavía devolverá los resultados. Por defecto; Puede configurar el servidor para que ni siquiera haga eso. Luego los resultados se descartan sin ser cargados por el navegador .

3) Finalmente, incluso si aceptara ciertos dominios, tiene cierto control sobre los encabezados que se aceptan y rechazan para hacer que la solicitud de esos sitios se ajuste a cierta forma.

Nota: los encabezados de ORIGEN y OPCIONES son controlados por el solicitante: obviamente, alguien que crea su propia solicitud HTTP puede poner lo que quiera allí. Sin embargo, un moderno navegador compatible con CORS NO hará eso. Es el navegador el que controla la interacción. El navegador está impidiendo que bobthehacker.com acceda a la puerta de enlace. Esa es la parte que te falta.

Me parece que CORS está simplemente expandiendo lo que es posible, y tratando de hacerlo de manera segura. Creo que esto es claramente un movimiento conservador. Hacer una política de dominios cruzados más estricta en otras etiquetas (script / imagen) a la vez que es más seguro, rompería una gran cantidad de código existente y haría mucho más difícil adoptar la nueva tecnología. Con suerte, se hará algo para cerrar ese agujero de seguridad, pero creo que primero deben asegurarse de que sea una transición fácil.

Tus preocupaciones son completamente válidas.

Sin embargo, lo más preocupante es el hecho de que no es necesario que exista ningún código malicioso para que esto pueda aprovecharse. Hay una serie de vulnerabilidades de secuencias de comandos entre sitios basados en DOM que permiten a los atacantes aprovechar el problema que describió e insertar JavaScript malicioso en páginas web vulnerables. El problema es más que simplemente dónde se pueden enviar los datos, pero de dónde se pueden recibir los datos.

Hablo de esto con más detalle aquí:

También revisé las especificaciones oficiales de CORS y no pude encontrar ninguna mención de este problema.

Derecha. La especificación CORS está resolviendo un problema completamente diferente. Se equivoca al pensar que empeora el problema: no mejora ni empeora el problema, ya que una vez que se ejecuta un script malicioso en su página, ya puede enviar los datos a cualquier lugar.

La buena noticia, sin embargo, es que hay una especificación widely-implemented que aborda este problema: la Content-Security-Policy . Le permite indicar al navegador que establezca límites sobre lo que puede hacer su página.

Por ejemplo, puede decirle al navegador que no ejecute ningún script en línea, lo que inmediatamente anulará muchos ataques XSS. O, como lo ha solicitado aquí, puede indicar explícitamente al navegador con qué dominios se puede contactar la página.