iOS. Приемы программирования

• NSFileProtectionComplete — это наиболее высокий уровень защиты, который вы можете задать для ваших файлов. При наличии данного ключа приложение сможет считывать такой файл и записывать в него информацию, пока устройство разблокировано. Если устройство заблокировано, считывать файл и записывать в него какие-либо данные невозможно. При применении такого уровня защиты коммерческие файловые менеджеры не могут читать содержимое файла, даже если пользовательское устройство разблокировано.

• NSFileProtectionCompleteUnlessOpen — значение очень похоже на NSFileProtectionComplete. Разница понятна уже из названия: вы сможете получить доступ к файлу, если уже открыли его, даже если впоследствии пользователь заблокирует устройство. Итак, открыв файл впервые, вы получаете к нему гарантированный доступ до тех пор, пока существует ваше приложение.

• NSFileProtectionCompleteUntilFirstUserAuthentication — при таком значении ваше приложение сможет считывать файл и заносить в него информацию, как только пользователь в первый раз разблокирует свое устройство. После этого вы можете и далее обращаться к файлу, даже если впоследствии пользователь вновь заблокирует устройство.

Вот пример:

— (NSString *) filePath{
NSFileManager *fileManager = [[NSFileManager alloc] init];

NSError *error = nil;
NSURL *documentFolderUrl = [fileManager URLForDirectory: NSDocumentDirectory
inDomain: NSUserDomainMask
appropriateForURL: nil
create: YES
error:&error];

if (error == nil && documentFolderUrl!= nil){
NSString *fileName = @"MyFile.txt";
NSString *filePath = [documentFolderUrl.path
stringByAppendingPathComponent: fileName];
return filePath;
}

return nil;
}

— (BOOL) application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

/*
Предпосылки:
1) подписать приложение валидным профилем инициализации;
2) в вашем профиле должна быть активизирована полная защита файла;
3) добавить в проект разрешения на подписывание кода.
*/

NSFileManager *fileManager = [[NSFileManager alloc] init];

if ([self filePath]!= nil){

NSData *dataToWrite = [@"Hello, World"
dataUsingEncoding: NSUTF8StringEncoding];

NSDictionary *fileAttributes = @{
NSFileProtectionKey: NSFileProtectionComplete
};

BOOL wrote = [fileManager createFileAtPath: [self filePath]
contents: dataToWrite
attributes: fileAttributes];

if (wrote){
NSLog(@"Successfully and securely stored the file");
} else {
NSLog(@"Failed to write the file");
}
}

self.window = [[UIWindow alloc]
initWithFrame: [[UIScreen mainScreen] bounds]];

self.window.backgroundColor = [UIColor whiteColor];
[self.window makeKeyAndVisible];
return YES;
}

Обсуждение

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

Предположим, вы пишете приложение для редактирования фотографий. Работая с этим приложением, пользователь может подключить камеру к своему устройству с iOS, импортировать свои фотографии в ваше приложение, а потом пользоваться им для редактирования, сохранения фотографий и раздачи их друзьям. Вы могли бы поступить так, как делают очень многие разработчики приложений: импортировать эти фотографии в папку Documents (Документы), где они сразу будут готовы к редактированию. Но с таким подходом связана одна проблема: любой файловый менеджер для iOS, который можно свободно скачать в Интернете, может считывать содержимое папки Documents (Документы) в любом приложении, даже если устройство заблокировано. Чтобы защитить пользовательские данные, следует активизировать защиту тех файлов, которые вы храните в песочнице приложения. Защита файлов — неотъемлемая часть безопасности пользовательского устройства, в частности, пароля к этому устройству. Допустим, пользователь установил на устройстве пароль, без которого устройство нельзя разблокировать (пусть даже этот пароль совсем простой), и такая блокировка произошла. В таком случае после того, как устройство будет заблокировано, все файлы, сохраненные в песочнице вашего приложения и обладающие ключом NSFileProtectionComplete, будут недоступны для посторонних. Прочитать такие файлы не сможет даже файловый менеджер.

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

См. также

Разделы 8.0 и 8.6.

8.9. Защита пользовательского интерфейса

Постановка задачи

Необходимо гарантировать, что пользовательский интерфейс соответствует наиболее распространенным правилам безопасности, действующим в iOS.

Решение

Следуйте приведенным далее указаниям.

• Обеспечьте, чтобы вся информация, вводимая пользователем в поля паролей и другие защищенные поля, попадала в экземпляры UITextField, чьим свойствам secureTextEntry присвоено значение YES.

• Если пользователь находится на экране, содержащем персональную информацию, например номер кредитной карточки или домашний адрес, присвойте свойству hidden главного окна вашего приложения значение YES (в методе applicationWillResignActive: делегата вашего приложения). Чтобы само окно отображалось на экране, тому же самому свойству нужно присвоить значение NO в методе applicationDidBecomeActive: делегата приложения. Так вы гарантируете, что на скриншоте пользовательского интерфейса (iOS снимает такой скриншот, когда приложение переходит в фоновый режим) не будет отражаться никакое содержимое вашего окна. Apple рекомендует действовать именно так.

• Обязательно валидируйте пользовательский ввод в текстовых полях/видах перед отправкой этой информации на сервер.

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

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