iOS Pentesting

Utiliza Trickest para construir y automatizar flujos de trabajo fácilmente, impulsados por las herramientas comunitarias más avanzadas del mundo. Obtén acceso hoy:

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)

Apoya a HackTricks

• Revisa los planes de suscripción!

• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.

• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.

iOS Basics

iOS Basics

Testing Environment

En esta página puedes encontrar información sobre el simulador de iOS, emuladores y jailbreaking:

iOS Testing Environment

Initial Analysis

Basic iOS Testing Operations

Durante la prueba se van a sugerir varias operaciones (conectar al dispositivo, leer/escribir/subir/bajar archivos, usar algunas herramientas...). Por lo tanto, si no sabes cómo realizar alguna de estas acciones, por favor, comienza a leer la página:

iOS Basic Testing Operations

Para los siguientes pasos la aplicación debe estar instalada en el dispositivo y ya debe haber obtenido el archivo IPA de la aplicación. Lee la página Basic iOS Testing Operations para aprender cómo hacer esto.

Basic Static Analysis

Se recomienda usar la herramienta MobSF para realizar un Análisis Estático automático al archivo IPA.

Identificación de protecciones presentes en el binario:

• PIE (Position Independent Executable): Cuando está habilitado, la aplicación se carga en una dirección de memoria aleatoria cada vez que se inicia, lo que dificulta predecir su dirección de memoria inicial.

otool -hv <app-binary> | grep PIE   # Debe incluir la bandera PIE

• Stack Canaries: Para validar la integridad de la pila, se coloca un valor de ‘canario’ en la pila antes de llamar a una función y se valida nuevamente una vez que la función termina.

otool -I -v <app-binary> | grep stack_chk   # Debe incluir los símbolos: stack_chk_guard y stack_chk_fail

• ARC (Automatic Reference Counting): Para prevenir fallos comunes de corrupción de memoria

otool -I -v <app-binary> | grep objc_release   # Debe incluir el símbolo _objc_release

• Binary Encriptado: El binario debe estar encriptado

otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # El cryptid debe ser 1

Identificación de Funciones Sensibles/Inseguras

• Algoritmos de Hashing Débiles

# En el dispositivo iOS
otool -Iv <app> | grep -w "_CC_MD5"
otool -Iv <app> | grep -w "_CC_SHA1"

# En linux
grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"

• Funciones Aleatorias Inseguras

# En el dispositivo iOS
otool -Iv <app> | grep -w "_random"
otool -Iv <app> | grep -w "_srand"
otool -Iv <app> | grep -w "_rand"

# En linux
grep -iER "_random"
grep -iER "_srand"
grep -iER "_rand"

• Función ‘Malloc’ Insegura

# En el dispositivo iOS
otool -Iv <app> | grep -w "_malloc"

# En linux
grep -iER "_malloc"

• Funciones Inseguras y Vulnerables

# En el dispositivo iOS
otool -Iv <app> | grep -w "_gets"
otool -Iv <app> | grep -w "_memcpy"
otool -Iv <app> | grep -w "_strncpy"
otool -Iv <app> | grep -w "_strlen"
otool -Iv <app> | grep -w "_vsnprintf"
otool -Iv <app> | grep -w "_sscanf"
otool -Iv <app> | grep -w "_strtok"
otool -Iv <app> | grep -w "_alloca"
otool -Iv <app> | grep -w "_sprintf"
otool -Iv <app> | grep -w "_printf"
otool -Iv <app> | grep -w "_vsprintf"

# En linux
grep -R "_gets"
grep -iER "_memcpy"
grep -iER "_strncpy"
grep -iER "_strlen"
grep -iER "_vsnprintf"
grep -iER "_sscanf"
grep -iER "_strtok"
grep -iER "_alloca"
grep -iER "_sprintf"
grep -iER "_printf"
grep -iER "_vsprintf"

Basic Dynamic Analysis

Revisa el análisis dinámico que realiza MobSF. Necesitarás navegar a través de las diferentes vistas e interactuar con ellas, pero estará enganchando varias clases al hacer otras cosas y preparará un informe una vez que hayas terminado.

Listing Installed Apps

Utiliza el comando frida-ps -Uai para determinar el identificador de paquete de las aplicaciones instaladas:

$ frida-ps -Uai
PID  Name                 Identifier
----  -------------------  -----------------------------------------
6847  Calendar             com.apple.mobilecal
6815  Mail                 com.apple.mobilemail
-  App Store            com.apple.AppStore
-  Apple Store          com.apple.store.Jolly
-  Calculator           com.apple.calculator
-  Camera               com.apple.camera
-  iGoat-Swift          OWASP.iGoat-Swift

Enumeración Básica y Hooking

Aprende a enumerar los componentes de la aplicación y cómo hookear métodos y clases con objection:

iOS Hooking With Objection

Estructura de IPA

La estructura de un archivo IPA es esencialmente la de un paquete comprimido. Al renombrar su extensión a .zip, se puede descomprimir para revelar su contenido. Dentro de esta estructura, un Bundle representa una aplicación completamente empaquetada lista para la instalación. Dentro, encontrarás un directorio llamado <NAME>.app, que encapsula los recursos de la aplicación.

• Info.plist: Este archivo contiene detalles de configuración específicos de la aplicación.

• _CodeSignature/: Este directorio incluye un archivo plist que contiene una firma, asegurando la integridad de todos los archivos en el bundle.

• Assets.car: Un archivo comprimido que almacena archivos de recursos como íconos.

• Frameworks/: Esta carpeta alberga las bibliotecas nativas de la aplicación, que pueden estar en forma de archivos .dylib o .framework.

• PlugIns/: Esto puede incluir extensiones a la aplicación, conocidas como archivos .appex, aunque no siempre están presentes. * Core Data: Se utiliza para guardar los datos permanentes de tu aplicación para uso offline, para almacenar datos temporales en caché y para agregar funcionalidad de deshacer a tu aplicación en un solo dispositivo. Para sincronizar datos en múltiples dispositivos en una sola cuenta de iCloud, Core Data refleja automáticamente tu esquema a un contenedor de CloudKit.

• PkgInfo: El archivo PkgInfo es una forma alternativa de especificar los códigos de tipo y creador de tu aplicación o bundle.

• en.lproj, fr.proj, Base.lproj: Son los paquetes de idioma que contienen recursos para esos idiomas específicos, y un recurso predeterminado en caso de que un idioma no esté soportado.

• Seguridad: El directorio _CodeSignature/ juega un papel crítico en la seguridad de la aplicación al verificar la integridad de todos los archivos empaquetados a través de firmas digitales.

• Gestión de Activos: El archivo Assets.car utiliza compresión para gestionar de manera eficiente los activos gráficos, crucial para optimizar el rendimiento de la aplicación y reducir su tamaño total.

• Frameworks y PlugIns: Estos directorios subrayan la modularidad de las aplicaciones iOS, permitiendo a los desarrolladores incluir bibliotecas de código reutilizables (Frameworks/) y extender la funcionalidad de la aplicación (PlugIns/).

• Localización: La estructura soporta múltiples idiomas, facilitando el alcance global de la aplicación al incluir recursos para paquetes de idiomas específicos.

Info.plist

El Info.plist sirve como una piedra angular para las aplicaciones iOS, encapsulando datos de configuración clave en forma de pares clave-valor. Este archivo es un requisito no solo para aplicaciones, sino también para extensiones de aplicaciones y frameworks empaquetados dentro. Está estructurado en formato XML o binario y contiene información crítica que abarca desde permisos de la aplicación hasta configuraciones de seguridad. Para una exploración detallada de las claves disponibles, se puede consultar la Documentación para Desarrolladores de Apple.

Para aquellos que buscan trabajar con este archivo en un formato más accesible, la conversión a XML se puede lograr fácilmente mediante el uso de plutil en macOS (disponible de forma nativa en versiones 10.2 y posteriores) o plistutil en Linux. Los comandos para la conversión son los siguientes:

• Para macOS:

$ plutil -convert xml1 Info.plist

• Para Linux:

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Entre la miríada de información que el archivo Info.plist puede revelar, las entradas notables incluyen cadenas de permisos de la aplicación (UsageDescription), esquemas de URL personalizados (CFBundleURLTypes), y configuraciones para la seguridad del transporte de aplicaciones (NSAppTransportSecurity). Estas entradas, junto con otras como tipos de documentos personalizados exportados/importados (UTExportedTypeDeclarations / UTImportedTypeDeclarations), pueden ser localizadas fácilmente inspeccionando el archivo o empleando un simple comando grep:

$ grep -i <keyword> Info.plist

Rutas de Datos

En el entorno de iOS, los directorios están designados específicamente para aplicaciones del sistema y aplicaciones instaladas por el usuario. Las aplicaciones del sistema residen en el directorio /Applications, mientras que las aplicaciones instaladas por el usuario se colocan en /var/mobile/containers/Data/Application/. Estas aplicaciones se asignan un identificador único conocido como UUID de 128 bits, lo que hace que la tarea de localizar manualmente la carpeta de una aplicación sea un desafío debido a la aleatoriedad de los nombres de los directorios.

Como las aplicaciones en iOS deben estar en un entorno aislado, cada aplicación también tendrá una carpeta dentro de $HOME/Library/Containers con el CFBundleIdentifier de la aplicación como nombre de la carpeta.

Sin embargo, ambas carpetas (carpetas de datos y de contenedores) tienen el archivo .com.apple.mobile_container_manager.metadata.plist que vincula ambos archivos en la clave MCMetadataIdentifier).

Para facilitar el descubrimiento del directorio de instalación de una aplicación instalada por el usuario, la herramienta objection proporciona un comando útil, env. Este comando revela información detallada del directorio para la aplicación en cuestión. A continuación se muestra un ejemplo de cómo usar este comando:

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # env

Name               Path
-----------------  -------------------------------------------------------------------------------------------
BundlePath         /var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app
CachesDirectory    /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library/Caches
DocumentDirectory  /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Documents
LibraryDirectory   /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library

Alternativamente, el nombre de la aplicación se puede buscar dentro de /private/var/containers utilizando el comando find:

find /private/var/containers -name "Progname*"

Los comandos como ps y lsof también se pueden utilizar para identificar el proceso de la aplicación y listar los archivos abiertos, respectivamente, proporcionando información sobre las rutas de directorio activas de la aplicación:

ps -ef | grep -i <app-name>
lsof -p <pid> | grep -i "/containers" | head -n 1

Directorio del paquete:

• AppName.app

• Este es el Paquete de Aplicación como se vio antes en el IPA, contiene datos esenciales de la aplicación, contenido estático así como el binario compilado de la aplicación.

• Este directorio es visible para los usuarios, pero los usuarios no pueden escribir en él.

• El contenido en este directorio no se respalda.

• Los contenidos de esta carpeta se utilizan para validar la firma del código.

Directorio de datos:

• Documents/

• Contiene todos los datos generados por el usuario. El usuario final de la aplicación inicia la creación de estos datos.

• Visible para los usuarios y los usuarios pueden escribir en él.

• El contenido en este directorio se respalda.

• La aplicación puede deshabilitar rutas configurando NSURLIsExcludedFromBackupKey.

• Library/

• Contiene todos los archivos que no son específicos del usuario, como cachés, preferencias, cookies y archivos de configuración de lista de propiedades (plist).

• Las aplicaciones de iOS suelen usar los subdirectorios Application Support y Caches, pero la aplicación puede crear subdirectorios personalizados.

• Library/Caches/

• Contiene archivos en caché semi-persistentes.

• Invisible para los usuarios y los usuarios no pueden escribir en él.

• El contenido en este directorio no se respalda.

• El sistema operativo puede eliminar automáticamente los archivos de este directorio cuando la aplicación no está en ejecución y el espacio de almacenamiento es bajo.

• Library/Application Support/

• Contiene archivos persistentes necesarios para ejecutar la aplicación.

• Invisible para los usuarios y los usuarios no pueden escribir en él.

• El contenido en este directorio se respalda.

• La aplicación puede deshabilitar rutas configurando NSURLIsExcludedFromBackupKey.

• Library/Preferences/

• Se utiliza para almacenar propiedades que pueden persistir incluso después de que se reinicie una aplicación.

• La información se guarda, sin cifrar, dentro del sandbox de la aplicación en un archivo plist llamado [BUNDLE_ID].plist.

• Todos los pares clave/valor almacenados usando NSUserDefaults se pueden encontrar en este archivo.

• tmp/

• Utiliza este directorio para escribir archivos temporales que no necesitan persistir entre lanzamientos de la aplicación.

• Contiene archivos en caché no persistentes.

• Invisible para los usuarios.

• El contenido en este directorio no se respalda.

• El sistema operativo puede eliminar automáticamente los archivos de este directorio cuando la aplicación no está en ejecución y el espacio de almacenamiento es bajo.

Veamos más de cerca el Paquete de Aplicación de iGoat-Swift (.app) dentro del directorio del Paquete (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app):

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # ls
NSFileType      Perms  NSFileProtection    ...  Name
------------  -------  ------------------  ...  --------------------------------------
Regular           420  None                ...  rutger.html
Regular           420  None                ...  mansi.html
Regular           420  None                ...  splash.html
Regular           420  None                ...  about.html

Regular           420  None                ...  LICENSE.txt
Regular           420  None                ...  Sentinel.txt
Regular           420  None                ...  README.txt

Binary Reversing

Dentro de la carpeta <application-name>.app encontrarás un archivo binario llamado <application-name>. Este es el archivo que será ejecutado. Puedes realizar una inspección básica del binario con la herramienta otool:

otool -Vh DVIA-v2 #Check some compilation attributes
magic  cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64    ARM64        ALL  0x00     EXECUTE    65       7112   NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE

otool -L DVIA-v2 #Get third party libraries
DVIA-v2:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.1)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 274.6.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
@rpath/Bolts.framework/Bolts (compatibility version 1.0.0, current version 1.0.0)
[...]

Verifica si la aplicación está encriptada

Mira si hay alguna salida para:

otool -l <app-binary> | grep -A 4 LC_ENCRYPTION_INFO

Desensamblando el binario

Desensamblar la sección de texto:

otool -tV DVIA-v2
DVIA-v2:
(__TEXT,__text) section
+[DDLog initialize]:
0000000100004ab8    sub    sp, sp, #0x60
0000000100004abc    stp    x29, x30, [sp, #0x50]   ; Latency: 6
0000000100004ac0    add    x29, sp, #0x50
0000000100004ac4    sub    x8, x29, #0x10
0000000100004ac8    mov    x9, #0x0
0000000100004acc    adrp    x10, 1098 ; 0x10044e000
0000000100004ad0    add    x10, x10, #0x268

Para imprimir el segmento de Objective-C de la aplicación de muestra se puede usar:

otool -oV DVIA-v2
DVIA-v2:
Contents of (__DATA,__objc_classlist) section
00000001003dd5b8 0x1004423d0 _OBJC_CLASS_$_DDLog
isa        0x1004423a8 _OBJC_METACLASS_$_DDLog
superclass 0x0 _OBJC_CLASS_$_NSObject
cache      0x0 __objc_empty_cache
vtable     0x0
data       0x1003de748
flags          0x80
instanceStart  8

Para obtener un código Objective-C más compacto, puedes usar class-dump:

class-dump some-app
//
//     Generated by class-dump 3.5 (64 bit).
//
//     class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2013 by Steve Nygard.
//

#pragma mark Named Structures

struct CGPoint {
double _field1;
double _field2;
};

struct CGRect {
struct CGPoint _field1;
struct CGSize _field2;
};

struct CGSize {
double _field1;
double _field2;
};

Sin embargo, las mejores opciones para desensamblar el binario son: Hopper y IDA.

Usa Trickest para construir y automatizar flujos de trabajo fácilmente, impulsados por las herramientas comunitarias más avanzadas del mundo. Obtén acceso hoy:

Almacenamiento de Datos

Para aprender sobre cómo iOS almacena datos en el dispositivo, lee esta página:

iOS Basics

Los siguientes lugares para almacenar información deben ser revisados justo después de instalar la aplicación, después de verificar todas las funcionalidades de la aplicación e incluso después de cerrar sesión de un usuario y entrar en uno diferente. El objetivo es encontrar información sensible no protegida de la aplicación (contraseñas, tokens), del usuario actual y de usuarios que han iniciado sesión anteriormente.

Plist

Los archivos plist son archivos XML estructurados que contienen pares clave-valor. Es una forma de almacenar datos persistentes, por lo que a veces puedes encontrar información sensible en estos archivos. Se recomienda revisar estos archivos después de instalar la aplicación y después de usarla intensivamente para ver si se escriben nuevos datos.

La forma más común de persistir datos en archivos plist es a través del uso de NSUserDefaults. Este archivo plist se guarda dentro del sandbox de la aplicación en Library/Preferences/<appBundleID>.plist

La clase NSUserDefaults proporciona una interfaz programática para interactuar con el sistema predeterminado. El sistema predeterminado permite que una aplicación personalice su comportamiento de acuerdo con las preferencias del usuario. Los datos guardados por NSUserDefaults pueden ser vistos en el paquete de la aplicación. Esta clase almacena datos en un archivo plist, pero está destinada a ser utilizada con pequeñas cantidades de datos.

Estos datos no pueden ser accedidos directamente a través de una computadora de confianza, pero pueden ser accedidos realizando una copia de seguridad.

Puedes volcar la información guardada usando NSUserDefaults utilizando ios nsuserdefaults get de objection.

Para encontrar todos los plist utilizados por la aplicación, puedes acceder a /private/var/mobile/Containers/Data/Application/{APPID} y ejecutar:

find ./ -name "*.plist"

Para convertir archivos de formato XML o binario (bplist) a XML, hay varios métodos disponibles según su sistema operativo:

Para usuarios de macOS: Utilice el comando plutil. Es una herramienta integrada en macOS (10.2+), diseñada para este propósito:

$ plutil -convert xml1 Info.plist

Para usuarios de Linux: Instala libplist-utils primero, luego usa plistutil para convertir tu archivo:

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Dentro de una sesión de Objection: Para analizar aplicaciones móviles, un comando específico te permite convertir archivos plist directamente:

ios plist cat /private/var/mobile/Containers/Data/Application/<Application-UUID>/Library/Preferences/com.some.package.app.plist

Core Data

Core Data es un marco para gestionar la capa de modelo de objetos en tu aplicación. Core Data puede usar SQLite como su almacenamiento persistente, pero el marco en sí no es una base de datos. CoreData no cifra sus datos por defecto. Sin embargo, se puede agregar una capa de cifrado adicional a CoreData. Consulta el GitHub Repo para más detalles.

Puedes encontrar la información de SQLite Core Data de una aplicación en la ruta /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support

Si puedes abrir el SQLite y acceder a información sensible, entonces encontraste una mala configuración.

Code from iGoat

-(void)storeDetails {
AppDelegate * appDelegate = (AppDelegate *)(UIApplication.sharedApplication.delegate);

NSManagedObjectContext *context =[appDelegate managedObjectContext];

User *user = [self fetchUser];
if (user) {
return;
}
user = [NSEntityDescription insertNewObjectForEntityForName:@"User"
inManagedObjectContext:context];
user.email = CoreDataEmail;
user.password = CoreDataPassword;
NSError *error;
if (![context save:&error]) {
NSLog(@"Error in saving data: %@", [error localizedDescription]);

}else{
NSLog(@"data stored in core data");
}
}

YapDatabase

YapDatabase es un almacén de clave/valor construido sobre SQLite. Como las bases de datos Yap son bases de datos sqlite, puedes encontrarlas utilizando el comando propuesto en la sección anterior.

Otras Bases de Datos SQLite

Es común que las aplicaciones creen su propia base de datos sqlite. Pueden estar almacenando datos sensibles en ellas y dejándolos sin cifrar. Por lo tanto, siempre es interesante revisar cada base de datos dentro del directorio de las aplicaciones. Por lo tanto, ve al directorio de la aplicación donde se guardan los datos (/private/var/mobile/Containers/Data/Application/{APPID})

find ./ -name "*.sqlite" -or -name "*.db"

Firebase Real-Time Databases

Los desarrolladores pueden almacenar y sincronizar datos dentro de una base de datos NoSQL alojada en la nube a través de Firebase Real-Time Databases. Almacenados en formato JSON, los datos se sincronizan con todos los clientes conectados en tiempo real.

Puedes encontrar cómo verificar bases de datos de Firebase mal configuradas aquí:

Firebase Database

Realm databases

Realm Objective-C y Realm Swift ofrecen una alternativa poderosa para el almacenamiento de datos, no proporcionada por Apple. Por defecto, almacenan datos sin cifrar, con cifrado disponible a través de una configuración específica.

Las bases de datos se encuentran en: /private/var/mobile/Containers/Data/Application/{APPID}. Para explorar estos archivos, se pueden utilizar comandos como:

iPhone:/private/var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Documents root# ls
default.realm  default.realm.lock  default.realm.management/  default.realm.note|

$ find ./ -name "*.realm*"

Para ver estos archivos de base de datos, se recomienda la herramienta Realm Studio.

Para implementar la encriptación dentro de una base de datos Realm, se puede usar el siguiente fragmento de código:

// Open the encrypted Realm file where getKey() is a method to obtain a key from the Keychain or a server
let config = Realm.Configuration(encryptionKey: getKey())
do {
let realm = try Realm(configuration: config)
// Use the Realm as normal
} catch let error as NSError {
// If the encryption key is wrong, `error` will say that it's an invalid database
fatalError("Error opening realm: \(error)")
}

Bases de datos de Couchbase Lite

Couchbase Lite se describe como un motor de base de datos liviano y embebido que sigue el enfoque orientado a documentos (NoSQL). Diseñado para ser nativo de iOS y macOS, ofrece la capacidad de sincronizar datos sin problemas.

Para identificar posibles bases de datos de Couchbase en un dispositivo, se debe inspeccionar el siguiente directorio:

ls /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support/

Cookies

iOS almacena las cookies de las aplicaciones en Library/Cookies/cookies.binarycookies dentro de la carpeta de cada aplicación. Sin embargo, los desarrolladores a veces deciden guardarlas en el keychain ya que el mencionado archivo de cookies puede ser accedido en copias de seguridad.

Para inspeccionar el archivo de cookies, puedes usar este script de python o usar ios cookies get de objection. También puedes usar objection para convertir estos archivos a un formato JSON e inspeccionar los datos.

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
[
{
"domain": "highaltitudehacks.com",
"expiresDate": "2051-09-15 07:46:43 +0000",
"isHTTPOnly": "false",
"isSecure": "false",
"name": "username",
"path": "/",
"value": "admin123",
"version": "0"
}
]

Cache

Por defecto, NSURLSession almacena datos, como solicitudes y respuestas HTTP en la base de datos Cache.db. Esta base de datos puede contener datos sensibles, si se han almacenado en caché tokens, nombres de usuario u otra información sensible. Para encontrar la información en caché, abre el directorio de datos de la aplicación (/var/mobile/Containers/Data/Application/<UUID>) y ve a /Library/Caches/<Bundle Identifier>. La caché de WebKit también se almacena en el archivo Cache.db. Objection puede abrir e interactuar con la base de datos con el comando sqlite connect Cache.db, ya que es una base de datos SQLite normal.

Se recomienda deshabilitar el almacenamiento en caché de estos datos, ya que puede contener información sensible en la solicitud o respuesta. La siguiente lista muestra diferentes formas de lograr esto:

1. Se recomienda eliminar las respuestas en caché después de cerrar sesión. Esto se puede hacer con el método proporcionado por Apple llamado removeAllCachedResponses. Puedes llamar a este método de la siguiente manera:

URLCache.shared.removeAllCachedResponses()

Este método eliminará todas las solicitudes y respuestas en caché del archivo Cache.db. 2. Si no necesitas aprovechar las cookies, se recomienda simplemente usar la propiedad de configuración .ephemeral de URLSession, que deshabilitará el guardado de cookies y cachés.

Documentación de Apple:

Un objeto de configuración de sesión efímera es similar a una configuración de sesión predeterminada (ver predeterminado), excepto que el objeto de sesión correspondiente no almacena cachés, almacenes de credenciales ni ningún dato relacionado con la sesión en el disco. En su lugar, los datos relacionados con la sesión se almacenan en RAM. La única vez que una sesión efímera escribe datos en el disco es cuando le indicas que escriba el contenido de una URL en un archivo. 3. La caché también se puede deshabilitar configurando la política de caché a .notAllowed. Esto deshabilitará el almacenamiento de caché de cualquier manera, ya sea en memoria o en disco.

Snapshots

Cada vez que presionas el botón de inicio, iOS toma una instantánea de la pantalla actual para poder hacer la transición a la aplicación de una manera mucho más fluida. Sin embargo, si hay datos sensibles presentes en la pantalla actual, se guardarán en la imagen (que persiste a través de reinicios). Estas son las instantáneas a las que también puedes acceder tocando dos veces la pantalla de inicio para cambiar entre aplicaciones.

A menos que el iPhone esté jailbroken, el atacante necesita tener acceso al dispositivo desbloqueado para ver estas capturas de pantalla. Por defecto, la última instantánea se almacena en el sandbox de la aplicación en la carpeta Library/Caches/Snapshots/ o Library/SplashBoard/Snapshots (los ordenadores de confianza no pueden acceder al sistema de archivos desde iOS 7.0).

Una forma de prevenir este mal comportamiento es poner una pantalla en blanco o eliminar los datos sensibles antes de tomar la instantánea utilizando la función ApplicationDidEnterBackground().

El siguiente es un método de remediación de ejemplo que establecerá una captura de pantalla predeterminada.

Swift:

private var backgroundImage: UIImageView?

func applicationDidEnterBackground(_ application: UIApplication) {
let myBanner = UIImageView(image: #imageLiteral(resourceName: "overlayImage"))
myBanner.frame = UIScreen.main.bounds
backgroundImage = myBanner
window?.addSubview(myBanner)
}

func applicationWillEnterForeground(_ application: UIApplication) {
backgroundImage?.removeFromSuperview()
}

Objetivo-C:

@property (UIImageView *)backgroundImage;

- (void)applicationDidEnterBackground:(UIApplication *)application {
UIImageView *myBanner = [[UIImageView alloc] initWithImage:@"overlayImage.png"];
self.backgroundImage = myBanner;
self.backgroundImage.bounds = UIScreen.mainScreen.bounds;