iOS WebViews
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
The code of this page was extracted from here. Check the page for further details.
Las WebViews se utilizan dentro de las aplicaciones para mostrar contenido web de manera interactiva. Varios tipos de WebViews ofrecen diferentes funcionalidades y características de seguridad para aplicaciones iOS. Aquí hay un breve resumen:
UIWebView, que ya no se recomienda a partir de iOS 12 debido a su falta de soporte para deshabilitar JavaScript, lo que la hace susceptible a inyecciones de scripts y ataques de Cross-Site Scripting (XSS).
WKWebView es la opción preferida para incorporar contenido web en aplicaciones, ofreciendo un control mejorado sobre el contenido y características de seguridad. JavaScript está habilitado por defecto, pero se puede deshabilitar si es necesario. También admite características para evitar que JavaScript abra ventanas automáticamente y asegura que todo el contenido se cargue de manera segura. Además, la arquitectura de WKWebView minimiza el riesgo de corrupción de memoria que afecte al proceso principal de la aplicación.
SFSafariViewController ofrece una experiencia de navegación web estandarizada dentro de las aplicaciones, reconocible por su diseño específico que incluye un campo de dirección de solo lectura, botones de compartir y navegación, y un enlace directo para abrir contenido en Safari. A diferencia de WKWebView, JavaScript no se puede deshabilitar en SFSafariViewController, que también comparte cookies y datos con Safari, manteniendo la privacidad del usuario desde la aplicación. Debe mostrarse de manera prominente de acuerdo con las pautas de la App Store.
En el proceso de examinar las configuraciones de WebViews, se enfocan en dos tipos principales: UIWebView y WKWebView. Para identificar estos WebViews dentro de un binario, se utilizan comandos, buscando referencias de clase específicas y métodos de inicialización.
Identificación de UIWebView
Este comando ayuda a localizar instancias de UIWebView buscando cadenas de texto relacionadas con él en el binario.
Identificación de WKWebView
De manera similar, para WKWebView, este comando busca en el binario cadenas de texto indicativas de su uso.
Además, para encontrar cómo se inicializa un WKWebView, se ejecuta el siguiente comando, dirigido a la firma del método relacionada con su inicialización:
Para WKWebView, se destaca que deshabilitar JavaScript es una buena práctica a menos que sea necesario. Se busca en el binario compilado para confirmar que la propiedad javaScriptEnabled
está configurada en false
, asegurando que JavaScript esté deshabilitado:
WKWebView ofrece la capacidad de identificar problemas de contenido mixto, a diferencia de UIWebView. Esto se verifica utilizando la propiedad hasOnlySecureContent
para asegurar que todos los recursos de la página se carguen a través de conexiones seguras. La búsqueda en el binario compilado se realiza de la siguiente manera:
El análisis dinámico implica inspeccionar el heap en busca de instancias de WebView y sus propiedades. Se utiliza un script llamado webviews_inspector.js
para este propósito, dirigido a instancias de UIWebView
, WKWebView
y SFSafariViewController
. Registra información sobre las instancias encontradas, incluyendo URLs y configuraciones relacionadas con JavaScript y contenido seguro.
La inspección del heap se puede realizar utilizando ObjC.choose()
para identificar instancias de WebView y verificar las propiedades javaScriptEnabled
y hasonlysecurecontent
.
El script se ejecuta con:
Resultados Clave:
Se localizan e inspeccionan con éxito las instancias de WebViews.
Se verifica la habilitación de JavaScript y la configuración de contenido seguro.
Este resumen encapsula los pasos y comandos críticos involucrados en el análisis de configuraciones de WebView a través de enfoques estáticos y dinámicos, centrándose en características de seguridad como la habilitación de JavaScript y la detección de contenido mixto.
Manejar contenido en WebViews es un aspecto crítico, especialmente al tratar con varios protocolos como http(s)://
, file://
y tel://
. Estos protocolos permiten la carga de contenido remoto y local dentro de las aplicaciones. Se enfatiza que al cargar contenido local, se deben tomar precauciones para evitar que los usuarios influyan en el nombre o la ruta del archivo y en la edición del contenido mismo.
WebViews ofrecen diferentes métodos para la carga de contenido. Para UIWebView, ahora obsoleto, se utilizan métodos como loadHTMLString:baseURL:
y loadData:MIMEType:textEncodingName:baseURL:
. WKWebView, por otro lado, emplea loadHTMLString:baseURL:
, loadData:MIMEType:textEncodingName:baseURL:
y loadRequest:
para contenido web. Métodos como pathForResource:ofType:
, URLForResource:withExtension:
y init(contentsOf:encoding:)
se utilizan típicamente para cargar archivos locales. El método loadFileURL:allowingReadAccessToURL:
es particularmente notable por su capacidad para cargar una URL o directorio específico en el WebView, exponiendo potencialmente datos sensibles si se especifica un directorio.
Para encontrar estos métodos en el código fuente o binario compilado, se pueden usar comandos como los siguientes:
En cuanto al acceso a archivos, UIWebView lo permite de manera universal, mientras que WKWebView introduce configuraciones allowFileAccessFromFileURLs
y allowUniversalAccessFromFileURLs
para gestionar el acceso desde URL de archivos, siendo ambas falsas por defecto.
Se proporciona un ejemplo de script de Frida para inspeccionar las configuraciones de WKWebView para ajustes de seguridad:
Por último, un ejemplo de una carga útil de JavaScript destinada a exfiltrar archivos locales demuestra el potencial riesgo de seguridad asociado con WebViews mal configurados. Esta carga útil codifica el contenido de los archivos en formato hex antes de transmitirlos a un servidor, destacando la importancia de medidas de seguridad estrictas en las implementaciones de WebView.
Desde iOS 7 en adelante, Apple proporcionó APIs para la comunicación entre JavaScript en un WebView y objetos nativos de Swift u Objective-C. Esta integración se facilita principalmente a través de dos métodos:
JSContext: Una función de JavaScript se crea automáticamente cuando un bloque de Swift u Objective-C se vincula a un identificador dentro de un JSContext
. Esto permite una integración y comunicación sin problemas entre JavaScript y el código nativo.
JSExport Protocol: Al heredar el protocolo JSExport
, se pueden exponer propiedades nativas, métodos de instancia y métodos de clase a JavaScript. Esto significa que cualquier cambio realizado en el entorno de JavaScript se refleja en el entorno nativo, y viceversa. Sin embargo, es esencial asegurarse de que los datos sensibles no se expongan inadvertidamente a través de este método.
JSContext
en Objective-CEn Objective-C, el JSContext
para un UIWebView
se puede recuperar con la siguiente línea de código:
WKWebView
Para WKWebView
, el acceso directo a JSContext
no está disponible. En su lugar, se utiliza el paso de mensajes a través de la función postMessage
, lo que permite la comunicación de JavaScript a nativo. Los controladores para estos mensajes se configuran de la siguiente manera, lo que permite que JavaScript interactúe con la aplicación nativa de manera segura:
JavaScript puede interactuar con la capa nativa definiendo un controlador de mensajes de script. Esto permite operaciones como invocar funciones nativas desde una página web:
Para capturar y manipular el resultado de una llamada a una función nativa, se puede anular la función de callback dentro del HTML:
El lado nativo maneja la llamada de JavaScript como se muestra en la clase JavaScriptBridgeMessageHandler
, donde el resultado de operaciones como multiplicar números se procesa y se envía de vuelta a JavaScript para su visualización o manipulación adicional:
(Tutorial basado en el de https://blog.vuplex.com/debugging-webviews)
Para depurar eficazmente el contenido web dentro de los webviews de iOS, se requiere una configuración específica que involucra las herramientas de desarrollador de Safari, debido a que los mensajes enviados a console.log()
no se muestran en los registros de Xcode. Aquí hay una guía simplificada, enfatizando los pasos y requisitos clave:
Preparación en el dispositivo iOS: El Inspector Web de Safari debe ser activado en tu dispositivo iOS. Esto se hace yendo a Configuración > Safari > Avanzado, y habilitando el Inspector Web.
Preparación en el dispositivo macOS: En tu máquina de desarrollo macOS, debes habilitar las herramientas de desarrollador dentro de Safari. Inicia Safari, accede a Safari > Preferencias > Avanzado, y selecciona la opción para Mostrar menú de Desarrollo.
Conexión y depuración: Después de conectar tu dispositivo iOS a tu computadora macOS y lanzar tu aplicación, usa Safari en tu dispositivo macOS para seleccionar el webview que deseas depurar. Navega a Desarrollar en la barra de menú de Safari, pasa el cursor sobre el nombre de tu dispositivo iOS para ver una lista de instancias de webview, y selecciona la instancia que deseas inspeccionar. Se abrirá una nueva ventana del Inspector Web de Safari para este propósito.
Sin embargo, ten en cuenta las limitaciones:
La depuración con este método requiere un dispositivo macOS ya que se basa en Safari.
Solo los webviews en aplicaciones cargadas en tu dispositivo a través de Xcode son elegibles para la depuración. Los webviews en aplicaciones instaladas a través de la App Store o Apple Configurator no pueden ser depurados de esta manera.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)