A través de la pagina netsparker.com  han publicado un post sobre una vulnerabilidad que afecta el navegador popular de Windows 10. A continuación dejarte parte del post y su referencias sobre la vulnerabilidad encontrada.

En 2015, Microsoft lanzó el navegador Edge. Cuando se desarrolló por primera vez, se llamó Proyecto Spartan . A diferencia de Internet Explorer, Edge admite una amplia gama de medidas de seguridad modernas, como la Política de seguridad de contenido (CSP) , así como funciones modernas de JavaScript y CSS. Abandonar el desarrollo de Internet Explorer y comenzar de nuevo con un navegador moderno como Edge trajo muchas ventajas de seguridad nuevas, pero también algunos problemas.


Una cosa que a menudo se pasa por alto en proyectos de desarrollo similares nuevos es el conocimiento adquirido a través de años de pequeñas soluciones de seguridad en el producto original. Quienes tengan experiencia en el funcionamiento interno sabrán que su equipo probablemente se equivocará inicialmente más que durante el proceso de desarrollo de un nuevo navegador hoy en día.

La razón de esto es que la seguridad de los navegadores está en constante reordenamiento a medida que surgen nuevos ataques, ya que los piratas informáticos y los profesionales de la seguridad ven a los navegadores como una de las fuentes más ricas de posibles ataques . Los pequeños agujeros de seguridad que solían conducir a la fuga de datos de usuario en los navegadores se han resuelto a lo largo de los años. Algunos fueron más severos que otros, pero la mayoría de ellos no fueron inmediatamente obvios en primer lugar. Son estas soluciones de seguridad y el conocimiento que viene con ella, que pueden perderse al rediseñar un navegador web.

Eso podría explicar por qué Microsoft Edge fue el único navegador que se encontró que era vulnerable a este defecto.





Nota: esta vulnerabilidad ya ha sido corregida por Microsoft.

¿Quién está en riesgo de esta vulnerabilidad de Microsoft Edge?

Se  a probado con éxito en Microsoft Edge 40.15063.0.0.

¿Cómo se puede robar mis archivos locales?

¡Primero pensemos por qué no debería poder robar tus archivos locales!

La misma política de origen (SOP) evitará que https://attacker.com lea el archivo: // C: /your/stuff.txt , por ejemplo. La razón es que tienen diferentes orígenes. Para leer datos usando una solicitud emitida por JavaScript, el protocolo, el nombre de host y el puerto deben coincidir. Sin embargo, las URL de los archivos son un poco especiales. El protocolo file: // y el protocolo https: // son obviamente diferentes, por lo que atacante.com no puede leer sus archivos locales.

Pero, ¿qué pasa si tratamos con dos URL de archivo que no tienen un nombre de host ni un puerto? 
Solo tienen el esquema de protocolo de archivo y una ruta. Esto significa que las dos URL de archivo serían automáticamente del mismo origen porque:
El puerto coincide: ninguno tiene puerto
El nombre de host coincide: no hay nombre de host en ambos
El esquema de protocolo coincide: ambos usan el esquema file: //

En otras palabras, si los desarrolladores de los navegadores no tomaran en consideración el formato especial de file: // urls, me sería posible leer el contenido de cualquier archivo local si simplemente abriera un archivo HTML malicioso guardado en su máquina !

Puede concluir que este no es un vector de ataque muy convincente, tal vez porque nunca ha descargado archivos HTML aleatorios. Además, Windows podría bloquear el archivo que acaba de descargar, ya que proviene de otra computadora. Al menos, este fue el caso cuando se probo el ataque.

¿Es esto una amenaza realista? ¿O es un escenario teórico?

¿Crees que un atacante podría de alguna manera convencer a una posible víctima para que descargue un archivo HTML y lo ejecute?

Debido a la existencia de otro vector de ataque, resulta que esto no es simplemente un escenario teórico. Si no puede entregar su archivo HTML a través del navegador, ¿por qué no simplemente enviarlo por correo a su víctima? En los últimos años se han dado cuenta de que puede ser algo muy malo abrir archivos adjuntos desconocidos como archivos .exe, archivos .js e incluso documentos de Word. Pero los archivos HTML? No hay un peligro inmediato obvio. Después de todo, solicitamos muchos archivos HTML en nuestros navegadores todos los días.
"Redacté un correo electrónico desde otra computadora, agregué el archivo como un archivo adjunto y luego abrí el archivo adjunto en la aplicación Correo y Calendario . Para mi sorpresa, funcionó. Esperaba que la aplicación, como el navegador Edge, bloquearía el archivo adjunto. Pero este no fue el caso en absoluto. Cuando envié el correo electrónico como un archivo adjunto y esperé hasta que un usuario lo abriera, inmediatamente enviaba los archivos locales de mi elección a mi servidor, donde podía almacenarlos y leerlos. Probablemente no haya ningún programa antivirus que reconozca mi archivo como malicioso, y podría extraer los archivos a través de una conexión segura HTTPS. ¡Esto es lo que hace que este ataque sea tan sigiloso! La versión de Windows Mail and Calendar donde probé mi exploit fue la versión 17.8600.40445.0 (también se informó este error)."

Pero hay otras maneras de entregar el archivo, dependiendo de los programas instalados del objetivo.




¿Cómo puedo proteger mis archivos?

La única forma de protegerse es actualizando las últimas versiones del navegador Edge y las aplicaciones de Windows Mail y Calendar . Y, por supuesto, es mejor nunca abrir archivos adjuntos de remitentes desconocidos, incluso si la extensión inicialmente no parece ser maliciosa.

Pero esta fue una publicación muy teórica. Si desea ver el exploit en acción, puede ver la prueba de exploit en video.
Código para aprovechar la vulnerabilidad de borde

A continuación se muestra también el código que el hacker puede usar en el archivo HTML para aprovechar esta vulnerabilidad de Edge.
<html>
<head>
<script>
let resultDiv = document.getElementById("result");
    let xhr= new XMLHttpRequest();
    let user = document.location.href.match(/file:\/\/\/C:\/Users\/([a-z0-9\-]*)\//i)[1];
    xhr.open("GET",'file://C:/Users/${user}/Desktop/secret.txt");
    xhr.onreadystatechange = ()=> {
     if(xhr.readyState==4) {
     resultDiv.innerText = xhr.responseText;
     }
    }
    xhr.send();
</script>
</head>
<body>
</body>
<div id="result"></div>
</html>