Cocoa UI 和通用框架元素抵御恶意攻击的能力如何？
到目前为止，我不太关心整体安全考虑，因为我一直在开发促销性和非批判性的 iPhone 应用程序。
然而，目前我正在开发一个 Mac 应用程序，该应用程序需要对此事进行更多思考，因为它处理敏感的用户信息。
虽然我知道我必须注意保护物理形式（在磁盘上）的数据，例如通过对其进行加密，但我想知道在正常使用应用程序的过程中数据驻留在内存中的安全性如何。
因此我想知道：
只要我的应用程序仅基于 NSTextField 和 Core Data 等框架元素构建，它的安全性如何？
Cocoa 输入元素对恶意攻击有多敏感？保护使用 Core Data 存储的已保存数据的最佳方法是什么？
So far I had little concern about overall security considerations, because I have been developing only promotional and uncritical iPhone apps.
Currently, however, I'm working on a Mac application which requires a few more thougts about the matter, because it deals with sensitive user information.
While I know that I must take care to protect the data in its physical form (on disk), for example by encrypting it, I wonder how safe it is while it resides in memory in the course of normal use of the application.
Thus I'd like to know:
How safe is my application as long as it is built only upon framework elements such as NSTextField and Core Data?
How sensitive are Cocoa input elements to malicious attacks? What would be the best way to protect saved data which is stored using Core Data?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Objective-C 是一种动态语言，这意味着可以在运行时替换类和类的特定方法。例如，1Password 插件就是这样进入 Safari 的，Dropbox 就是这样进入 Finder 的。目前，恶意攻击者可以使用低级别的 mach_inject API 或许多其他级别稍高的方法（例如 SIMBL 或 OSAX 注入）将代码加载到您的应用程序中。一旦代码加载到您的应用程序中，Objective-C 的动态特性理论上可以用攻击者选择的子类或类中的特定方法（包括侦听和存储用户输入）替换 NSTextField。 NSTextField 的安全版本是为密码设计的，可能对此有一些保护措施，尽管我还没有找到这方面的具体文档。 Security.framework 和钥匙串 API 通常确实可以保护内存中的数据，并且它们不是基于 Objective-C，因此干扰它们要困难得多（尽管可能仍然有可能）。
Objective-C is a dynamic language, which means that it is possible to replace classes and specific methods of classes at runtime. For example, this is how the 1Password plugin finds its way into Safari, and Dropbox finds it way into the Finder. It is currently possible for a malicious attacker to use the low level mach_inject API, or a number of other slightly higher-level methods, such as SIMBL or OSAX injection, to load code into your app. Once code is loaded into your app, the dynamic nature of Objective-C makes it possible in theory to replace NSTextField with a subclass of the attacker's choice, or specific methods in the class, including listening and storing user input. The secure version of NSTextField, which is designed for passwords, may have some protections against this, though I haven't found specific documentation to that effect. Security.framework and the keychain APIs in general do have protection for your data in memory, and they are not based on Objective-C, so it is significantly harder (although maybe still possible) to interfere with them.
为了补充上面 mgorbach 的答案（非常好），Core Data 可以以四种形式存储数据：
两者都不是 .plist，二进制文件或 SQLite 是安全的。 .plist 文件可以轻松读取。二进制文件会比较棘手，但据我所知，它没有使用任何加密，任何 Objective-C 编码器都应该能够轻松提取其内容。 SQLite 也不安全。 FireFox 的 SQLite Manager 等工具，或 Base for Mac，让读取 Core Data SQLite 数据变得轻而易举。
由于没有任何核心数据存储方法是安全的，因此最好的选择是在将数据提交到磁盘之前对其进行加密。
这没有考虑任何内存中攻击。当然，要成功，系统通常必须已经受到某种程度的损害。
如果最终用户启用了 FileVault（加密其整个主文件夹）、启用了安全虚拟内存、打开了防火墙并设置了强密码，那么他们就可以相当安全地抵御许多攻击。
To add to mgorbach's answer above (which is very good), Core Data can store data in four forms:
Neither .plist, Binary File, or SQLite are secure. .plist files can be easily read. A Binary file will be trickier, but AFAIK it's not using any encryption, and any Objective-C coder should easily be able to extract its contents. SQLite isn't secure either. Tools like SQLite Manager for FireFox, or Base for Mac, make it trivial to read Core Data SQLite data.
Since no Core Data storage methods are secure, your best bet is to encrypt data before committing it to disk.
This doesn't take into consideration any in-memory attacks. Of course, for this to be successful, a system typically has to already be compromised somehow.
If an end-user has FileVault enabled (encrypts their entire home folder), secure virtual memory enabled, their Firewall on, and a strong password, they're reasonably safe against many attacks.