En la capa de aplicación, su navegador no tiene noción de direcciones IP internas y externas. Por lo tanto, cualquier sitio web simplemente puede decirle a su navegador que solicite un recurso desde su red interna. Esto no se bloquearía, ya que para el navegador es solo una solicitud ordinaria de origen cruzado. Tenga en cuenta que el sitio que realiza la solicitud no podrá leer nada, simplemente podría concluir que hay algo .
Por ejemplo, un sitio web podría intentar averiguar si su enrutador tiene una interfaz web en 192.168.1.1 utilizando un fragmento de código como este:
<img src="http://192.168.1.1/favicon.ico"onload="alert('Yay')" onerror="alert('No')">'
De forma similar, un sitio web puede hacer que solicite recursos de direcciones IP internas (y en casi puertos arbitrarios) y mida los tiempos de respuesta para concluir que hay un servicio en ejecución: por ejemplo, si una solicitud a http://localhost:8080 tiene un tiempo de respuesta corto, es posible que esté ejecutando un proxy local o similar.
Si realiza este tipo de solicitudes en cascada, puede hacer que el navegador realice una exploración básica de la red e inferir sobre las IP, nombres de host y servicios existentes.
Esta idea también se usa para ataques reales. Incluso si la interfaz de su enrutador no es accesible desde el exterior, un atacante externo podría ejecutar un ataque como el reciente Explotación de la ejecución del código arbitrario del enrutador de Netgear al engañarlo para que visite un sitio web preparado que hace que usted realice el ataque usted mismo enviando una solicitud especialmente diseñada a la interfaz del enrutador. (Esencialmente un ataque CSRF en la intranet).
Una forma de mitigar el riesgo de acceso a la intranet es el módulo ABE (Application Boundaries Enforcer) de la extensión NoScript que se puede configurar para bloquear hosts particulares.
¿Puede un atacante realmente no leer ningún contenido?
Con frecuencia, pueden leer el contenido de un sitio de intranet realizando un ataque de encuadernación de DNS . Digamos que la interfaz de tu enrutador es accesible en 192.168.1.1/info.cgi . En un ataque de reencuadernación de DNS, el atacante te hace visitar attacker.com , que primero apunta a la IP de su propio servidor, carga un poco de Javascript y luego lo apunta a 192.168.1.1 . Cuando Javascript solicita attacker.com/info.cgi , se resuelve en su interfaz de enrutador y el script puede leer el contenido de la respuesta. Esto no viola la política del mismo origen porque todas las solicitudes están en el mismo origen (el dominio attacker.com ), aunque la entrada de DNS cambia en segundo plano. (Como contramedida, los sitios deben verificar que el encabezado Host contenga la IP o el nombre de la intranet. Pero muchos enrutadores no lo hacen).