¿Cuáles son los riesgos de seguridad de habilitar Cors en localhost?

7

Tengo una aplicación móvil basada en Cordova que está llegando a alguna API a través de un servidor local en el móvil. La aplicación móvil establece el origen como Localhost. Aquí surge el corsé y no puedo hacer la solicitud. Ahora estas API se pueden utilizar a través de un terminal, un cartero y otros entornos que no sean de navegador sin activar CORS.

Ahora, en este escenario, ¿cuáles son los riesgos de habilitar los cors en localhost? Solo para aclarar quiero hacer una lista blanca de locals en producción local.

    
pregunta aWebDeveloper 06.04.2017 - 20:51
fuente

2 respuestas

4

La respuesta realmente depende de la API que creó y de cómo funciona. Este Sitio ofrece una muy buena explicación sobre los bienes y males de CORS. En resumen, el autor crea una API ficticia que se utiliza para enviar correos electrónicos desde otro dominio. Él declara:

  

Si está utilizando la autenticación basada en cookies de sesión, probablemente no debería permitir que CORS realice las solicitudes de todos. Un sitio web malicioso puede emitir solicitudes de envío de correo electrónico a api.yoursebsite.com a través de una solicitud AJAX sin el permiso específico de su usuario.

Esta es (en su caso hipotético) la respuesta a la pregunta "¿cuáles son los riesgos de habilitar los corsés"? En ese caso, también da más información sobre cómo pensar en la mitigación:

  

Si el usuario tiene cookies de sesión válidas en su navegador, se usarán para autenticarse en api.yoursebsite.com y eso podría llevar a un envío no deseado de correo electrónico. En la mayoría de los casos, las solicitudes peligrosas serán "pre-iluminadas", lo que significa que el dominio debe ser aprobado antes de que puedan enviar una solicitud. Esto evitará que ocurran actividades maliciosas.

Esto declara (de una manera un poco oculta) lo que dandavis ya dijo: CORS no tiene mucho que ver con la seguridad. La seguridad se realiza en el lado del servidor. El SOP no será obedecido por los hackers de todos modos.

En su caso, por lo que entiendo, ¿desea habilitar localhost como un dominio a través de CORS para que las solicitudes se puedan realizar a través de algún dominio diferente? Si eso es correcto, creo que no tendrás ningún problema de seguridad real . Bajo la condición previa de que abra un socket vinculado únicamente a la dirección de bucle de retorno (localhost), la única forma en que alguien podría acceder a eso (de forma maliciosa o de otra manera) sería: Ya tiene acceso a la dirección de bucle de retroceso. Eso significa que: ya obtuvo acceso al dispositivo.

Basado en el comentario bastante correcto de Conor Mancone: CORS protege principalmente contra solicitudes de lectura no autorizadas. No protege al servidor de escrituras ni desencadena acciones no autorizadas. Esto tiene que ser implementado por un concepto de autorización.

    
respondido por el Ben 16.11.2017 - 12:55
fuente
3

No, esto no es NOT (necesariamente) seguro. Las otras respuestas son en su mayoría correctas, excepto que hacen dos suposiciones (comunes, pero incorrectas): que localhost siempre es 127.0.0.1, y que un servidor web que se ejecuta en su máquina es uno que usted quería ejecutar. ESTAS NO SON ASUNCIONES SEGURAS .

Algunas máquinas, debido a una modificación deliberada para algún propósito o simplemente porque el archivo HOSTS es mínimo (o falta), no definen localhost como 127.0.0.1 (o :: 1 para IPv6) y, por lo tanto, realizan una búsqueda de DNS ese nombre. Por supuesto, el DNS generalmente no es seguro; un atacante en la misma red (o en cualquier lugar entre usted y un servidor DNS dispuesto a declarar con autoridad a qué dirección IP se asigna el "localhost") puede inyectar una respuesta DNS que especifique su propia dirección IP. Su aplicación carga el contenido web del servidor web del atacante. El atacante puede enviar a la víctima el contenido web malintencionado que roba las credenciales a su servicio, roba el contenido de su cuenta, utiliza maliciosamente su cuenta, utiliza los puentes de API de JS a nativo para atacar su dispositivo (o al menos accede maliciosamente a los datos desde el dispositivo móvil la aplicación puede ver), y así sucesivamente.

Bien, ¿y si usó "127.0.0.1" en lugar de "localhost"? Las direcciones IP nunca tienen que pasar por DNS, 127.0.0.1 siempre se enruta a su propia máquina, y debería estar bien, ¿no?

¡Todavía es una mala idea! Los sockets TCP no respetan el aislamiento de privilegios entre usuarios (o entre aplicaciones de espacio aislado). Si su usuario móvil tiene una aplicación incompleta que ejecuta un servidor web en ese puerto, su aplicación se conectará al servidor malicioso en lugar de al que su aplicación intentó iniciar (que no habrá podido vincular el socket, ya que ya está en uso ). Es casi seguro que también puedes incluir eso en la tienda de aplicaciones; no está utilizando ninguna API no permitida ni nada, solo sirve contenido web en un socket de bucle de retorno enlazado a un puerto en particular (igual que usted). De manera similar, en servidores / computadoras de escritorio / computadoras portátiles, si su máquina permite que usuarios que no son administradores accedan de forma remota (a través de SSH, escritorio remoto, etc.), uno de esos usuarios podría activar un servidor web malintencionado en el puerto que utiliza y esperar su aplicación para conectarse a ella.

Por supuesto, incluso sin ningún intento malicioso, toda esta idea es simplemente frágil . Como mencioné anteriormente, no hay garantía de que ningún otro proceso esté ejecutando un servidor web en el mismo puerto que ha elegido. Solo hay 2 ^ 16 de ellos para elegir, y para algunos rangos, el sistema operativo en sí puede vincular aleatoriamente las conexiones salientes a ese puerto, por lo que podría estar en uso por una aplicación cliente (como un navegador web) en lugar de que un servidor De cualquier manera, el servidor utilizado para ofrecer su contenido web no podrá vincular el puerto, su aplicación no podrá comunicarse con el servidor que espera y su usuario tendrá una mala experiencia.

Tenga en cuenta que esto no tiene nada que ver con CORS. A CUALQUIER origen desde el que cargue el contenido, su servidor deberá permitir que ese origen vea las respuestas de la web.

El punto importante es asegurarse de que el contenido web esté cargado de forma segura , y HTTP sobre TCP normal, es decir, sin TLS u otras formas de autenticar y proteger la conexión. ¡No es seguro!

Solución: simplemente cargue el contenido (a través de HTTPS) desde sus servidores web orientados a Internet. Entonces, su aplicación no necesita cargar nada a través de HTTP, su servicio web no necesita permitir ninguna solicitud de ninguna página web cargada a través de HTTP, y la aplicación puede estar segura de que está cargando contenido desde el servidor correcto.

Incluso puede servir el contenido desde el mismo dominio, por lo que las solicitudes de origen cruzado (es decir, CORS) ni siquiera son necesarias. Simplemente use XMLHttpRequests (o Fetch, sin CORS) de la vieja escuela y extraiga todo lo relacionado con CORS del servicio web.

Hora de la historia:

La empresa anterior para la que trabajé tenía un producto que hacía algo como lo que estás describiendo: cargar datos desde un servidor web de localhost en una vista web - y nos encontramos con un problema realmente divertido donde algunas personas informaban que la vista web estaba solo ... vacío Sin contenido. El servidor local se estaba ejecutando, el contenido se empaquetó e instaló correctamente, la vista web intentaba realizar las solicitudes web ... pero parecía que el servidor no estaba respondiendo. En pocas palabras, finalmente lo rastreamos hasta que "localhost" quedara indefinido en esas máquinas. Esto fue solo unos pocos usuarios de aproximadamente 10,000 (en Mac, ya que era la única plataforma que ejecutaba nuestra aplicación), pero fue un problema suficiente que dejamos de usar "localhost". Por supuesto, "127.0.0.1" tampoco resultó ser seguro, como expliqué anteriormente, pero esa decisión se tomó antes de que hubiera una persona de seguridad en el equipo.

    
respondido por el CBHacking 18.11.2017 - 05:04
fuente

Lea otras preguntas en las etiquetas