Implementación segura de WebView en aplicaciones iOS — Protección | de Wojciech ReguÅ‚a | seguridad

Implementacion segura de WebView en aplicaciones iOS — Proteccion
  • No use UIWebView.
  • Asegúrese de que su Info.plist no contenga excepciones de seguridad de transporte de aplicaciones.
  • Siga el principio del mínimo privilegio.
  • Considere deshabilitar JavaScript.
  • Codifique los puentes JavaScript-ObjC/Swift con cuidado.
  • Siga buenas prácticas de desarrollo de aplicaciones móviles -> vea nuestro Directrices sobre la seguridad de las aplicaciones móviles: edición iOS .

Recientemente tuve la oportunidad de observar muchas aplicaciones WebView nuevas, así que decidí crear este artículo. Hace unos años, si alguien quería crear una aplicación multiplataforma, era casi necesario crear una base de código diferente en cada plataforma. Luego, los marcos multiplataforma ingresaron al mercado que facilitaron la codificación universal. Una forma de codificación universal es usar WebView. La idea era simple: crear una aplicación en tecnologías web (HTML, CSS, JS) y renderizarla dentro de la aplicación nativa. Entonces, WebView es solo un navegador integrado en su aplicación. Tal tecnología introdujo vulnerabilidades características de las aplicaciones web a las aplicaciones nativas. Dado que WebView se puede tratar como un navegador, utiliza los mismos mecanismos de los que también se puede abusar. Al final resultó que, los resultados de la explotación pueden ser aún más dañinos. ¿Qué pasa si la aplicación quiere obtener algunos recursos guardados en su dispositivo como fotos o contactos? Bueno, los desarrolladores necesitan crear puentes JavaScriptObjective-C/Swift que puedan explotarse usando una vulnerabilidad simple de secuencias de comandos entre sitios. En la siguiente subsección, le mostraré cómo crear aplicaciones WebView seguras, incluidas las amenazas más comunes.

Esta subsección podría acortarse a «no usar UIWebViews». UIWebView es la antigua API de Apple presente en iOS desde la versión 2.0, es decir, desde 2008. Si sigues la historia de las vulnerabilidades, probablemente sepas que en 2008 la mayoría de las funciones de seguridad de los navegadores modernos aún no se habían inventado. Tampoco espere que la API creada y lanzada en 2008 implemente esos mecanismos de seguridad. UIWebView quedó obsoleto en iOS 12.0 y ya no debe usarse en su código. Si su aplicación todavía usa UIWebView, la mejor recomendación que puedo darle es que la reescriba a WKWebView. Antes de comenzar a refactorizar, le sugiero que lea la siguiente subsección sobre WKWebViews, ya que su implementación también puede codificarse de manera insegura.

Pero, ¿por qué no recomiendo usar UIWebView? Si necesita argumentos concretos, puede encontrarlos a continuación:

  1. UIWebView no tiene una funcionalidad que permita deshabilitar JavaScript. Entonces, si su aplicación no usa JS y desea seguir el principio de privilegio mínimo, no puede apagarlo.
  2. No hay ninguna característica que maneje contenido mixto. No puede verificar si todo se cargó utilizando el protocolo HTTPS. su funcionalidad no debería ser un caso, porque no deberías agregar ninguna excepción de App Transport Security (excepciones que permiten conexiones HTTP inseguras).
  3. UIWebView no implementa la representación fuera de proceso como lo hace WKWebView. Por lo tanto, si los atacantes encuentran una vulnerabilidad de corrupción de memoria en UIWebView, podrán explotarla en el contexto de su aplicación.
  4. Acceso a archivos a través de expediente:// el esquema siempre está activado. Lo que es aún peor es que acceder a los archivos a través de ese esquema no sigue el mecanismo de la Política del mismo origen. Significa que si los atacantes explotan una vulnerabilidad de Cross-Site Scripting en su WebView, pueden cargar archivos disponibles desde el entorno limitado de la aplicación y luego enviarlos a su servidor.

Como un buen ejemplo de inseguridad UIWebView les mostraré un vulnerabilidad Encontré en Dictionary.app de Apple en macOS:

Implementacion segura de WebView en aplicaciones iOS — Proteccion

La aplicación Dictionary.app permite, por supuesto, la traducción del idioma A al B. Apple no pudo crear todos los diccionarios, por lo que puede crear su diccionario con, por ejemplo, un dialecto étnico. Luego, las palabras traducidas se mostraban en UIWebView sin ninguna validación. Me preguntaba si existe la posibilidad de explotar el expediente:// handler y robar archivos locales, así que creé la siguiente entrada de diccionario:

1659174549 306 Implementacion segura de WebView en aplicaciones iOS — Proteccion

Luego, abrí Dictionary.app, inicié netcat en 127.0.0.1:8000 y el contenido de la /etc/contraseña fueron transferidos:

1659174550 645 Implementacion segura de WebView en aplicaciones iOS — Proteccion

Creo que ahora está convencido de que no se recomienda encarecidamente el uso de UIWebView.

WKWebView es esa API que debe usar para cargar contenido web en su aplicación. El prefijo «WK» proviene de WebKit, el motor del navegador. WKWebView es una API moderna que aplica todos los mecanismos modernos de seguridad web, Apple aún la mantiene y recibe actualizaciones. Lo bueno de WKWebView es que realiza una representación fuera del proceso, por lo que si los atacantes encuentran una vulnerabilidad de corrupción de memoria en él, el proceso de su aplicación aún está aislado.

Empecemos desde el Información.plist configuración. En el artículo sobre redes seguras en iOS, escribí sobre las excepciones de App Transport Security. Las recomendaciones se aplican también a WKWebView. Asegúrese de no permitir conexiones HTTP sin cifrar. El WKWebView se puede tratar como un navegador web, por lo que si el atacante puede realizar un ataque Man-In-The-Middle, puede robar sus cookies/tokens de autorización, ejecutar JavaScript en el contexto de su aplicación y, por lo tanto, llamar a JavaScript. Puentes Objective-C/Swift. Puedes verificar si el contenido se cargó completamente con conexiones encriptadas con el siguiente código:

import UIKitimport WebKitclass ViewController: UIViewController 

Luego, debe cargar de alguna manera el contenido HTML. Hay dos enfoques: el primero carga contenido HTML desde el paquete de la aplicación (local) y el segundo es cargar el contenido HTML desde su sitio web. Asegúrese de cargar contenido que usted controle por completo. Si carga código JavaScript desde los recursos externos, puede verificar que es criptográfico picadillo con integridad atributos Para aplicaciones de alto riesgo, se recomienda aplicar protecciones de ingeniería inversa. En el mundo WebView, puede minimizar los archivos JavaScript o incluso ofuscarlos.

Ahora, hablemos del endurecimiento. los expediente:// El esquema siempre está habilitado en WKWebView, pero no puede (por defecto) acceder a los archivos. Ese mecanismo se puede habilitar, pero tenga en cuenta el principio de privilegio mínimo. Si su WebView no necesariamente tiene que acceder a los archivos, no lo encienda.

Lo contrario es un intérprete de JavaScript que está activado por defecto. Si su sitio web no utiliza JS, se recomienda (nuevamente, el principio de privilegio mínimo) desactivarlo. Puedes usar el siguiente código:

let webPreferences = WKPreferences() webPreferences.javaScriptEnabled = false self.configuration?.preferences = webPreferences

La última característica que quería discutir en este artículo son los puentes. WKWebView permite llamar a código nativo desde JavaScript. Probablemente ahora se dé cuenta de lo dañino que podría ser si no se codifica correctamente. Hace dos años estaba probando una aplicación de iOS que usaba tales puentes para obtener fotos de la biblioteca de fotos del usuario. Como encontré una vulnerabilidad de secuencias de comandos entre sitios almacenados que me permitía ejecutar código JavaScript en cada instancia de esa aplicación, pude robar todas las fotos de las bibliotecas de fotos de los usuarios y enviarlas a mi servidor. El código nativo se llama a través de la API postMessage.

Código nativo:

// first register the controllerself.configuration?.userContentController.add(self, name: "SystemAPI")[...]// and expose native methodsextension ViewController : WKScriptMessageHandler 

Código JavaScript:

<script> 
window.webkit.messageHandlers.SystemAPI.postMessage();
</script>

El ejemplo de código que pegué, por supuesto, no está bien diseñado porque permite cargar cualquier archivo o cualquier contacto. Al codificar puentes, asegúrese de que sus métodos sean lo más limitados posible. Entonces, incluso si los atacantes de alguna manera inyectan código en su WebView, la superficie de ataque será estrecha. Por lo tanto, no exponga métodos excesivos, valide estrictamente los parámetros y limítelos (en este caso, en lugar de cargar el archivo desde la ruta, puede cargar archivos por ID desde el directorio de función especificado). Para prevenir adicionalmente las vulnerabilidades de Cross-Site Scripting, considere también implementar el mecanismo de Política de seguridad de contenido. A pesar de que es solo una capa adicional de seguridad, puede detener a los atacantes bloqueando las vulnerabilidades XSS.

El uso de WebViews en aplicaciones nativas puede impulsar el desarrollo, ya que se puede usar el mismo código HTML/CSS/JS en todas las plataformas que admite la aplicación. Esa tecnología es realmente conveniente, pero conlleva nuevos riesgos. En este artículo, quería mostrarles 2 API presentes en el entorno de Apple. El anterior: UIWebView se considera inseguro y ya no debe usarse. WKWebView es la API adecuada para implementar WebViews. Desafortunadamente, incluso el uso de la API moderna puede generar vulnerabilidades. Los desarrolladores deben asegurarse de que su código no sea vulnerable a los ataques nativos y relacionados con la web. Este artículo presentó cómo implementar vistas web seguras y cómo limitar la superficie de ataque.

Durante el proceso de desarrollo de aplicaciones iOS, también es fundamental seguir las mejores prácticas. Hemos publicado un manual que recopila todo nuestro conocimiento de seguridad de iOS en un solo lugar. Puede acceder a él haciendo clic en el siguiente enlace.

No dude en ponerse en contacto conmigo. Puedes encontrarme en Gorjeo en LinkedIn.

Deja un comentario