¿Pueden los sitios web acceder a las computadoras en LAN / Localhost a través del navegador y cómo bloquearlas? [duplicar]

La mayoría de los navegadores no distinguen entre WAN, LAN y host local. Esto significa que aplican las mismas políticas y restricciones para las solicitudes entre sitios de WAN a LAN que entre los diferentes sitios en la WAN o entre diferentes sitios en la misma LAN.

Esto significa especialmente que los ataques entre sitios como CSRF son posibles, y dichos ataques también se usan en la práctica durante muchos años; consulte, por ejemplo, El ataque a gran escala secuestra su enrutador a través de su navegador .

Y mientras que CSRF solo puede causar acciones no deseadas (como cambiar la configuración de DNS de un enrutador) pero no puede ser usado por sí mismo para filtrar datos de otros ataques puede: si tiene un sitio interno que es accesible a través de WebSockets también se puede acceder de forma predeterminada desde el exterior utilizando el navegador como un trampolín ( Cross-Origin WebSocket ). El sitio interno necesitaría explícitamente verificar el Origen de la solicitud para detener este acceso (es decir, abierto e inseguro por defecto). Otros ataques que hacen posible la exfiltración son los ataques XSS contra sitios internos o DNS reenlazado . Además, puede establecer explícitamente la configuración insegura de las Políticas de origen cruzado ( CORS ) en los sitios internos para la exfiltración. Y podría ser más posible utilizando Flash.

La prevención de este acceso es difícil ya que la mayoría de los navegadores no distinguen entre sitios internos y externos. Esto significa que se espera que los sitios internos tengan la misma protección que los sitios externos. Incluso un firewall perimetral que se usa para proteger la LAN interna de ataques externos generalmente no impedirá dicho acceso, ya que estos ataques funcionan en una capa que no es visible para la mayoría de los firewalls.

Una forma de restringir dicho acceso es usar varios navegadores (o perfiles), uno para sitios internos y otro para sitios externos. El acceso podría restringirse permitiendo el acceso a Internet solo a través de un proxy explícito: un navegador tendrá el proxy configurado para todos los sitios y, por lo tanto, solo podrá acceder a sitios externos siempre que el proxy no permita el acceso a sitios internos. El otro navegador no tiene un proxy configurado y, por lo tanto, puede tener sitios internos pero no externos. Esta separación estricta detiene el acceso entre sitios externos e internos a través del navegador. Pero probablemente impacta la usabilidad en la mayoría de los entornos.

  

Mientras navego por Internet, los sitios web pueden ejecutar código a través de mi navegador   que acceden a sitios web o servicios que están alojados en Localhost o LAN?

Hay alguna buena información sobre la reconexión de DNS, CSRF, etc. en otras respuestas. Sin embargo, me sorprende que nadie mencione el escaneo en red. JavaScript se puede usar para escanear toda su red local y puede determinar qué puertos están abiertos en qué hosts.

Aquí hay un sitio web de ejemplo que hace esto: enlace

Tenga en cuenta que un sitio web podría hacer esto sin su permiso o conocimiento.

Además, si está ejecutando algún servicio local (por ejemplo, redis, memcached, elasticsearch), a menudo también pueden ser atacados desde el navegador, como se muestra en esta publicación: enlace

Los datos se pueden escribir en estos servicios, pero CORS impide leerlos, por lo que aquí es donde entran los ataques de nuevo enlace de DNS.

  

También, pueden los datos de los sitios web / servicios de intranet ser   raspado / hackeado / robado a través del código que se ejecuta en un sitio remoto a través de   mi navegador web?

Similar a lo anterior, esto depende de la política CORS establecida por el servidor web de destino. Esto se puede omitir con la reconexión de DNS.

  

¿Los navegadores web modernos se protegen de este tipo de ataques y cómo?

En realidad no; como han dicho otros, el navegador no distingue realmente la WAN de la LAN, ni debe hacerlo necesariamente. Mientras CORS ayuda, hemos visto que se puede omitir con la reconexión de DNS.

  

¿Cómo aislar el acceso de Localhost e Intranet desde el navegador?

La única solución real es deshabilitar todos los JavaScript que no sean de confianza. La extensión NoScript está disponible para los principales navegadores y es bastante configurable.

Supongo que también podría intentar separar su PC del resto de la red, y puede haber una forma (con iptables) para evitar que su navegador acceda a los servicios locales. Sin embargo, sospecho que esto será tedioso.

Sí, se puede acceder a los sitios y servicios desde su LAN o localhost (a veces) a través de un atacante malicioso en el navegador. Además de los errores en el navegador mencionados por cybernard, hay otros ataques (mucho más comunes) que lo hacen posible.

Recuerde que el JavaScript malicioso se ejecuta en el navegador y, por lo tanto, puede atacar cualquier cosa que su navegador pueda alcanzar: esto incluye a localhost y su LAN. Depende de las aplicaciones para rechazar solicitudes elaboradas.

DNS Rebinding Attacks

En un ataque de reencuadernación de DNS , el atacante usa un nombre de host que hará referencia a dos direcciones IP diferentes. Primero, se referirá a su servidor y cargarán una página maliciosa que contenga javascript de ese servidor. El javascript esperará y luego hará la solicitud de otra al mismo nombre de host, pero mientras tanto, el servidor DNS habrá cambiado la dirección IP en uso por ese nombre de host a localhost o una IP en su LAN. Dado que nombre de host sigue siendo igual , el javascript malicioso no tiene problemas para acceder al recurso local y puede leer datos de su host local o LAN.

Esto no es una preocupación teórica: Tavis Ormandy acaba de encontrar una vulnerabilidad en el cliente de Transmission BitTorrent . Se ha utilizado para ataque enrutadores con configuración predeterminada .

Algunos servidores DNS (incluidos los integrados en algunos enrutadores) ofrecen protección contra esto al no aceptar direcciones IP "locales" (RFC1918 & localhost) en las respuestas de Internet.

falsificación de solicitudes en sitios cruzados

Si el atacante solo quiere cambiar de estado en su aplicación web y la aplicación es vulnerable a Cross-Site Solicitar falsificación (CSRF), luego pueden realizar solicitudes a ese sitio sin siquiera poder leer el contenido de las páginas. CSRF se encuentra en el Top 10 de OWASP, por lo que este no es un error poco común.

Configuración incorrecta de CORS

Las aplicaciones que hacen uso de CORS para permitir solicitudes de origen cruzado pueden ser erróneas -configurado y permite solicitudes de origen cruzado de sitios maliciosos que se ejecutan en su navegador. Si bien no son exclusivos de su LAN o localhost, pueden verse afectados.

Pregunta 1: Al navegar por Internet, ¿los sitios web pueden ejecutar código a través de mi navegador que accede a sitios web o servicios que están alojados en Localhost o LAN?

Sí, no fácilmente y solo a través de algún tipo de piratería.

Los hackers son muy inteligentes y trabajan constantemente para explotar vulnerabilidades en los navegadores web. Si golpean su navegador con un día cero, podrían muy bien inyectar código y ejecutarlo. Así aprovechando cada vez más el acceso con cada intento. La mayoría de los piratas informáticos inyectarán un virus de escritorio remoto para que puedan ver e interactuar con el escritorio, pero no siempre.

Pregunta 2: Además, ¿se pueden raspar / hackear / robar los datos de los sitios / servicios de la intranet a través del código que maneja el sitio remoto a través de mi navegador web?

Sí, no fácilmente y solo a través de algún tipo de piratería.

Pregunta 3: ¿Los navegadores web modernos se protegen de este tipo de ataques y cómo?

Cientos, miles o más de horas hombre de prueba. Tener equipos de investigación de seguridad empujan cada navegador de todas las maneras posibles para ver qué se rompe. Luego, pídales que lo informen para que el equipo del navegador pueda solucionarlo. También patrocinan eventos en la convención de piratería en la que se pagan recompensas con dinero real por explotaciones. Si el exploit es lo suficientemente bueno, puede aportar 10.000 o incluso un millón de dólares para el investigador o equipo que traiga el hack.

Incluso tienen fuzzers, lanzando datos aleatorios en el navegador web para ver si algo se rompe o se comporta de una manera inesperada.

Los días de alto nivel cero se están volviendo más raros, pero personas muy inteligentes todavía están trabajando en ellos. Los tesoros de las hazañas del día cero están siendo acaparados por el malvado que hace un grupo de hackers dispuestos a vender si el precio es correcto.

Pregunta 4: ¿Cómo aislar el acceso de Localhost e Intranet del navegador?

• software de caja de arena y máquina virtual
• Usando las últimas versiones de todo.
• firewalls No cargue una extensión no probada ni probada en su navegador.
• detectores de virus y rootkits
• IDS

Termino esta información aterradora con un poco de cordura.

El navegador web principal ha sido probado exhaustivamente y está constantemente parcheando su código. Si bien la respuesta es SÍ, ellos pueden entrar, es increíblemente difícil hoy en día. Por lo general, se necesitan equipos de personas para encontrar y explotar las vulnerabilidades del navegador superior, Firefox, Chrome y Edge. A menudo lleva meses de investigación dedicada incluso para encontrar una debilidad. Incluso entonces puede llevar meses adicionales convertirlo en un exploit operativo. Mientras tanto, los blancos, buenos, se acercan cada vez más a encontrar lo mismo y solucionar el problema. Esto puede anular meses de trabajo duro para los hackers. Ya no es una tarea trivial.