How well are Cocoa user interfaces and common structural elements protected from malicious attacks?

Question

So far, I have not cared much about general security considerations, because I only developed advertising and non-critical applications for the iPhone.

Currently, however, I am working on a Mac application that requires a few thousand more about this because it deals with user confidential information.

Although I know that I have to take care of protecting data in its physical form (on disk), for example, by encrypting it, I wonder how safe it is while it is in memory during normal use of the application.

So I would like to know:
How safe is my application if it is built only on structural elements such as NSTextField and Core Data?

How sensitive are Cocoa input elements for malicious attacks? What would be the best way to protect stored data that is stored using Core Data?

Answer 1

Objective-C is a dynamic language, which means that you can replace classes and specific class methods at runtime. For example, since the 1Password plugin finds its way in Safari, and Dropbox finds it in Finder. Currently, an attacker can use the low-level API mach_inject or a number of other methods of a slightly higher level, such as SIMBL injection or OSAX, to load code into your application. After loading the code into your application, the dynamic nature of Objective-C allows you to theoretically replace NSTextField with a subclass of attacker selection or specific methods in the class, including listening and saving user input. A secure version of NSTextField designed for passwords may have some protection against this, although I did not find any specific documentation for this. Security.framework and keychain APIs in general have protection for your data in memory, and they are not based on Objective-C, so it is much more difficult (although perhaps still possible) to interfere with them.

Answer 2

To add the answer above (which is very good) to mgorbach, Core Data can store data in four forms:

• SQLite3 Database (most common)
• .plist file (e.g. XML)
• Binary file
• Internal memory (volatile storage)

Neither .plist, Binary File, or SQLite are protected. .Plist files can be easily read. The binary will be more complex, but AFAIK does not use any encryption, and any Objective-C encoder can easily extract its contents. SQLite is also not safe. Tools such as SQLite Manager for FireFox, or Base for Mac, make it trivial to read SQLite SQL Server data.

Since no methods for storing basic data are protected, it is best to encrypt the data before transferring it to disk.

This does not account for attacks within the memory. Of course, for this to be successful, the system, as a rule, should already be compromised.

If the end user has FileVault enabled (encryption of the entire home folder), protected virtual memory, firewall and strong password, they are safe enough for many attacks.