¿Política del mismo origen para el archivo: URL en el navegador de Android?

7

Cuando carga una URL file:// en una vista web de Android o en el navegador de Android, ¿qué trata como origen? ¿A qué puede acceder el Javascript en esa página? ¿Puede acceder a otros archivos en el mismo directorio? ¿Otros archivos en otro lugar en el dispositivo?

Antecedentes: sé que, en los navegadores de escritorio, la política del mismo origen para file:// URL ha variado con el tiempo y de un navegador a otro. Por ejemplo, algunos navegadores solían tratar a todas las URL file:// como si estuvieran dentro del mismo origen, por lo que cualquier página podría escribir todas las páginas con el protocolo file . Hoy, creo que algunos navegadores de escritorio usan el directorio como origen (por ejemplo, file://a/b/c.html está en el mismo origen que file://a/b/d.html y se pueden escribir entre sí, pero están en un origen diferente a file://a/y/z.html y no pueden hacerlo) ), aunque creo que otros navegadores usan la ruta completa como el origen (es decir, file://a/b/c.html tiene un origen diferente a file://a/b/d.html y no puede realizar una secuencia de comandos o cualquier otra URL file ). ¿Cuál es la situación del navegador de Android / el procesador utilizado por las vistas web de Android?

    
pregunta D.W. 07.12.2012 - 19:49
fuente

1 respuesta

6

Cuando ejecutas un archivo .html con el URI file:// , el script se ejecuta en la zona "archivo". Lo que significa que puede leer archivos en el sistema de archivos local utilizando un XHR. (Esto está sujeto a cambios, y también es fácil de verificar)

Como con la mayoría de los "estándares", depende del navegador que estés usando. Si está utilizando Firefox en cualquier sistema, incluido Android, JavaScript solo puede acceder a los archivos en su propio directorio y en todos los subdirectorios. Pero este es un cambio reciente SOP de FireFox (1 de mayo de 2012).

WebKit es una historia diferente. Si tiene un script ejecutándose en la zona file:// , entonces puede leer cualquier archivo en el sistema de archivos local, siempre que el navegador se ejecute como usuario con los permisos de archivo necesarios ( /etc/passwd siempre debe ser legible para todo el mundo).

Debe tenerse en cuenta que la mayoría de los navegadores no le permitirán redirigir desde una zona web (http, https) a la zona de archivos. Érase una vez que podía hacer esto, pero era una característica que estaba madura para el abuso. Entonces, si hubiera una vulnerabilidad XSS basada en DOM en un archivo .html local, sería difícil de explotar (no tengo conocimiento de un método para hacer esto y este método probablemente sería una vulnerabilidad). Aunque esta vulnerabilidad teórica puede ser un "script de zona cruzada" que permitiría a un atacante eliminar archivos del sistema de archivos local, sería muy difícil de explotar debido a las restricciones de redirección.

    
respondido por el rook 07.12.2012 - 20:04
fuente

Lea otras preguntas en las etiquetas