¿Qué tan bien están protegidos la Cocoa UI y los elementos del marco general contra ataques maliciosos?

Question

Hasta ahora tenían poca preocupación acerca de las consideraciones generales de seguridad, ya que he estado desarrollando aplicaciones para el iPhone sólo de promoción y no críticas.

Actualmente, sin embargo, estoy trabajando en una aplicación de Mac que requiere unos cuantos más sobre el asunto, ya que trata con información sensible del usuario.

Si bien sé que debo proteger los datos en su forma física (en el disco), por ejemplo encriptando, me pregunto qué tan seguro es mientras se encuentra en la memoria durante el uso normal del solicitud.

Por lo tanto me gustaría saber:
¿Qué tan segura es mi solicitud, siempre y cuando se construye únicamente a los elementos del marco como NSTextField y Datos Core?

¿Qué tan sensibles son los elementos de entrada del cacao a ataques maliciosos? ¿Cuál sería la mejor manera de proteger los datos guardados que se almacenan utilizando Core Data?

Answer 1

Objective-C es un lenguaje dinámico, lo que significa que es posible sustituir las clases y los métodos específicos de clases en tiempo de ejecución. Por ejemplo, así es como el complemento 1Password se abre camino en Safari, y Dropbox lo encuentra en el Buscador. Actualmente es posible que un atacante malintencionado use la API mach_inject de bajo nivel, o una serie de otros métodos de nivel ligeramente superior, como la inyección SIMBL o OSAX, para cargar código en su aplicación. Una vez que el código se carga en su aplicación, la naturaleza dinámica de Objective-C hace que sea posible en teoría para reemplazar NSTextField con una subclase de la elección del atacante, o métodos específicos de la clase, incluyendo la escucha y el almacenamiento de la entrada del usuario. La versión segura de NSTextField, que está diseñada para contraseñas, puede tener algunas protecciones contra esto, aunque no he encontrado documentación específica a tal efecto. Security.framework y las API de keychain en general tienen protección para sus datos en la memoria, y no están basados ​​en Objective-C, por lo que es mucho más difícil (aunque tal vez todavía sea posible) interferir con ellos.

Answer 2

Para añadir a mgorbach de respuesta anterior (que es muy bueno), Núcleo de datos puede almacenar datos en cuatro formas:

1. SQLite3 base de datos (lo más común)
2. Archivo .Plist (por ejemplo, XML)
3. archivo binario
4. en memoria (almacenamiento no persistente)

ni .Plist, archivo binario, o SQLite son seguras. Los archivos .plist se pueden leer fácilmente. Un archivo binario será más complicado, pero AFAIK no está utilizando ningún cifrado, y cualquier codificador de Objective-C debería poder extraer fácilmente su contenido. SQLite tampoco es seguro. Las herramientas como SQLite Manager para Firefox, o Base para Mac, hacen que sea trivial leer datos de Core Data SQLite.

Dado que no hay métodos de almacenamiento de datos básicos seguros, su mejor opción es cifrar los datos antes de enviarlos al disco.

Esto no toma en consideración ningún ataque en memoria. Por supuesto, para que esto sea exitoso, un sistema generalmente ya debe estar comprometido de alguna manera.

Si un usuario final tiene FileVault habilitado (encripta toda su carpeta de inicio), la memoria virtual segura habilitada, su Firewall activado y una contraseña segura, son razonablemente seguros contra muchos ataques.