Насколько хорошо пользовательский интерфейс Cocoa и общие элементы инфраструктуры защищены от злонамеренных атак? - PullRequest
Новая
       44

Насколько хорошо пользовательский интерфейс Cocoa и общие элементы инфраструктуры защищены от злонамеренных атак?

6 голосов
/ 23 мая 2011

До сих пор меня мало волновали общие соображения безопасности, потому что я разрабатывал только рекламные и некритические приложения для iPhone.

В настоящее время, однако, я работаю над приложением Mac, которое требует еще нескольких размышлений по этому вопросу, потому что оно имеет дело с конфиденциальной информацией пользователя.

Хотя я знаю, что должен позаботиться о защите данных в их физической форме (на диске), например, зашифровав их, мне интересно, насколько они безопасны, когда они хранятся в памяти при обычном использовании приложения. .

Таким образом, я хотел бы знать:
Насколько безопасно мое приложение, если оно построено только на таких элементах инфраструктуры, как NSTextField и Core Data?

Насколько чувствительны элементы ввода Какао к вредоносным атакам? Каков наилучший способ защитить сохраненные данные, которые хранятся с использованием базовых данных?

Ответы [ 2 ]

6 голосов
/ 23 мая 2011

Objective-C - это динамический язык, который означает, что можно заменить классы и конкретные методы классов во время выполнения. Например, вот как плагин 1Password находит свой путь в Safari, а Dropbox находит его в Finder. В настоящее время злоумышленник может использовать низкоуровневый API mach_inject или ряд других более высокоуровневых методов, таких как внедрение SIMBL или OSAX, для загрузки кода в ваше приложение. Как только код загружен в ваше приложение, динамическая природа Objective-C теоретически позволяет заменить NSTextField подклассом по выбору злоумышленника или специальными методами в классе, включая прослушивание и сохранение пользовательского ввода. Безопасная версия NSTextField, разработанная для паролей, может иметь некоторые средства защиты от этого, хотя я не нашел конкретной документации на этот счет. Security.framework и API цепочки для ключей в целом имеют защиту для ваших данных в памяти, и они не основаны на Objective-C, поэтому значительно труднее (хотя, возможно, все еще возможно) мешать им.

0 голосов
/ 24 мая 2011

Чтобы добавить ответ mgorbach выше (что очень хорошо), Core Data может хранить данные в четырех формах:

  1. База данных SQLite3 (наиболее распространенная)
  2. .plist Файл (например, XML)
  3. Двоичный файл
  4. In-Memory (непостоянное хранилище)

.plist, Binary File или SQLite не являются безопасными. Файлы .plist легко читаются. Двоичный файл будет сложнее, но AFAIK не использует никакого шифрования, и любой кодировщик Objective-C легко сможет извлечь его содержимое. SQLite тоже небезопасен. Такие инструменты, как SQLite Manager для FireFox или Base для Mac, упрощают чтение данных Core Data SQLite.

Поскольку основные методы хранения данных не являются безопасными, лучше всего шифровать данные перед их записью на диск.

Это не учитывает любые атаки в памяти. Конечно, для того, чтобы это было успешным, система, как правило, должна быть уже взломана.

Если у конечного пользователя включено FileVault (шифруется вся его домашняя папка), включена защищенная виртуальная память, включен брандмауэр и надежный пароль, они достаточно защищены от многих атак.

...