(Не)безопасность iOS-приложений (Часть 3)

4.7. SQL-инъекции

Обычно приложениям iOS нужно хранить некоторое количество данных на стороне клиента. Один из простейших способов – использовать базу данных SQLite. Как и в веб-приложениях, если выражение SQL сформировано некорректно, это может привести к SQL-инъекции. В большинстве случаев это не будет иметь больших последствий, так как данные хранятся на стороне клиента. Тем не менее, если недоверенные данные, сформированные злоумышленником, получаются с сервера, возникает возможность эксплоита. Чтобы обращаться к базам данных SQLite на стороне клиента, iOS предоставляет встроенную библиотеку. Использующее SQLite приложение будет слинковано с библиотекой "libsqlite3.dylib".

Как и в традиционных веб-приложениях, SQL-инъекции в приложениях iOS случаются, когда для динамического построения SQL-оператора используются необработанные данные, введенные пользователем. Чтобы скомпилировать SQL-оператор, его нужно представить в виде неизменяемого массива символов и передать одному из подготовительных методов SQLite.

Рассмотрим следующий пример приложения для социальных сетей, которое считывает множество сообщений о статусах пользователей и хранит результаты в базе данных SQLite, чтобы их можно было просматривать оффлайн. Приложение считывает информацию от множества пользователей и заносит в базу ссылки на профили пользователей и их отображаемые имена Следующий пример кода показывает динамически создаваемый SQL-оператор, который запускается при прочтении сообщения пользователя:

sqlite3 *database;
sqlite3_stmt *statement;
if(sqlite3_open([databasePath UTF8String], &database) == SQLITE_OK)
{
NSString *sql = [NSString stringWithFormat:@"INSERT INTO messages VALUES('1',
'%@','%@','%@')", msg, user, displayname];
const char *insert_stmt = [sql UTF8String];
sqlite3_prepare_v2(database, insert_stmt, -1, &statement, NULL);
if (sqlite3_step(statement) == SQLITE_DONE)

В показанном выше фрагменте кода разработчик сначала открывает базу данных SQLite, путь к которой хранится в переменной "databasePath". Если база данных успешно открывается, то инициализируется объект NSString для создания динамического SQL-оператора с использованием необработанных, контролируемых атакующим переменных "msg", "user" и "displayname". Получившийся SQL-запрос затем преобразуется в неизменяемый массив символов и компилируется как SQL-оператор с помощью метода "sqlite3_prepare_v2". Наконец, данный SQL-оператор запускается с помощью метода "sqlite3_step".

Поскольку параметры, используемые для построения оператора, исходят от пользователя, пользователь может контролировать результирующий оператор. Например, пусть злоумышленник составил следующее сообщение о статусе:

Check out my cool site http://mdattacker.net', 'Goodguy', 'Good guy');/*

Это приведет к выполнению следующего SQL-запроса:

INSERT INTO messages VALUES('1', 'Check out my cool site http://mdattacker.net',
'Goodguy', 'Good guy');/*','originaluser','Original User');

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

Решение данной проблемы похоже на решение проблемы SQL-инъекций в традиционных приложениях. Нужно определять структуру запроса с помощью связанных переменных и параметризованных запросов. SQLite предоставляет функцию sqlite3_bind_text для привязки текстовых значений к заготовленным шаблонам операторов. Проблему предыдущего примера можно решить следующим образом:

const char *insert_stmt = "INSERT INTO messages VALUES(‘1’, ?,
?, ?)"; sqlite3_prepare_v2(database, insert_stmt, -1, &statement, NULL);
sqlite3_bind_text(&insert_stmt, 1, [msg UTF8String], -1, SQLITE_TRANSIENT);
sqlite3_bind_text(&insert_stmt, 2, [user UTF8String], -1, SQLITE_TRANSIENT);
sqlite3_bind_text(&insert_stmt, 3, [displayname UTF8String], -1,
SQLITE_TRANSIENT);
if (sqlite3_step(statement) == SQLITE_DONE)

С помощью параметризованного запроса переменная msg будет ограничена в скомпилированном запросе связанной переменной и не сможет выйти за ее границы.

4.8. Взаимодействие с файловой системой

Взаимодействие с файловой системой в iOS может осуществляться через классы NSFileManager или NSFileHandle. В то время как класс NSFileManager явно используется для работы с файловой системой, NSFileHandle также позволяет обращаться к сокетам, каналам (pipe) и устройствам.

Класс NSFileManager предлагает устойчивое взаимодействие с файловой системой с большим числом методов для выполнения файловых операций, включая:

Методы	Описание
fileExistsAtPath	Определяет наличие файла.
contentsEqualAtPath	<Сравнивает содержимое двух файлов. /td>
isReadableFileAtPath, isWritableFileAtPath, isExecutableFileAtPath, isDeletableFileAtPath	Определяют возможность чтения, записи, выполнения и удаления файла соответственно.
moveItemAtPath	Переименовывает указанный файл.
copyItemAtPath	Копирует файл в заданное место.
removeItemAtPath	Удаляет указанный файл.
createSymbolicLinkAtPath	Создает символическую ссылку на указанный файл.

Класс NSFileHandle предоставляет более продвинутые средства взаимодействия с файловым дескриптором. Этот класс ближе к традиционным файловым операциям языка C, предоставляет средства для перемещения по файлу и оставляет закрытие файлового хэндла на совести разработчика.

Оба класса NSFileManager и NSFileHandle уязвимы к выходу за пределы директории (directory traversal) в сценарии, где атакующий может контролировать часть имени файла.

Рассмотрим следующую реализацию считывания содержимого файла c вариантами для обоих классов.

- (NSData*) readContents:(NSString*)location
{
NSFileManager *filemgr;
NSData *buffer;
filemgr = [NSFileManager defaultManager];
buffer = [filemgr contentsAtPath:location];
return buffer;
}

- (NSData*) readContentsFH:(NSString*)location
{
NSFileHandle *file;
NSData *buffer;
file = [NSFileHandle fileHandleForReadingAtPath:location];
buffer = [file readDataToEndOfFile];
[file closeFile];
return buffer;
}

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

NSString *fname = @"../Documents/secret.txt";
NSString *sourcePath = [[NSString alloc] initWithFormat:@"%@/%@",
[[NSBundle
mainBundle] resourcePath], fname];
NSLog(@"####### PATH = %@", sourcePath);
NSString *contents = [[NSString alloc] initWithData:[fm
readContentsFH:sourcePath] encoding:NSUTF8StringEncoding];
NSLog(@"####### File contents: %@", contents);

В вышеприведенном примере переменная fname получается из контролируемой пользователем строки и делает возможной атаку по выходу за пределы директории ресурсов в директорию документов.

2012-02-11 15:58:18.029 VulnerableiPhoneApp[3291:707] ####### PATH =
/var/mobile/Applications/E84D97BB-79E7-4603-93D3-
09A88CB4FA71/VulnerableiPhoneApp.app/../Documents/secret.txt
2012-02-11 15:58:18.040 VulnerableiPhoneApp[3291:707] ####### File contents:
Password=abc123

Разработчикам также следует знать о риске смешивания языков Objective-C и C, особенно при выполнении операций с файлами. Objective-C не использует в объекте NSString нулевых байтов для завершения строки. Если разработчик использует объект NSString, содержащий контролируемый пользователем путь к файлу, а последующие операции записаны на языке C, атакующий сможет обрубить строку. Рассмотрим следующий пример:

NSString *fname = @"../Documents/secret.txt\0";
NSString *sourcePath = [[NSString alloc] initWithFormat:@"%@/%@.jpg",
[[NSBundle
mainBundle] resourcePath], fname];
char line[1024];
FILE *fp = fopen([sourcePath UTF8String], "r");
fread(line, sizeof(line), 1024, fp);
NSString *contents = [[NSString alloc] initWithCString:line];
fclose(fp);

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

4.9 Геолокация

Apple предоставляет средства доступа к геолокационным возможностям устройства с помощью фреймворка Core Location. Координаты устройства можно определить с помощью GPS, триангуляции сотовых вышек или по близости WiFi-сети. При использовании геолокационных данных разработчикам следует учитывать две главных проблемы приватности: первая – как и где логируются данные, вторая – запрошенная точность координат.

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

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

При использовании ClocationManager приложение может запрашивать требуемую точность с помощью класса CLLocationAccuracy и следующих его констант:

• kCLLocationAccuracyBestForNavigation
• kCLLocationAccuracyBest
• kCLLocationAccuracyNearestTenMeters
• kCLLocationAccuracyHundredMeters
• kCLLocationAccuracyKilometer
• kCLLocationAccuracyThreeKilometers

4.10. Логирование

Логирование может оказаться ценным ресурсом для отладки в ходе разработки, однако в некоторых случаях оно может привести к утечке конфиденциальной информации, которая затем кэшируется на устройстве до следующей перезагрузки. Логирование в Objective-C обычно выполняется посредством метода NSLog, который посылает сообщение в системный лог Apple. Данные консольные логи доступны средствами библиотеки ASL не только органайзеру Xcode, но и любому установленному на устройстве приложению.

В некоторых случаях применение к устройству джейлбрейка может привести к перенаправлению вывода NSLog в syslog. Поэтому разработчикам рекомендуется избегать использования NSLog для логирования конфиденциальной или проприетарной информации.

Самый простой способ для разработчиков избежать попадания NSLog в финальные версии продуктов – переопределить его временным макросом препроцессора вроде "#define NSLog(…)".

4.11 Переход в фоновый режим

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

Если в момент перехода в фоновый режим в приложении открыта какая-нибудь конфиденциальная информация, снимок будет записан в файловую систему открытым текстом. Однако, можно использовать делегированный метод applicationDidEnterBackground объекта UIApplication, чтобы отловить момент перехода в фон и сделать необходимые модификации. Например, поля, содержащие конфиденциальную информацию, приложение может скрывать, используя атрибут "hidden":

- (void)applicationDidEnterBackground:(UIApplication *)application {
viewController.creditcardNumber.hidden = YES;
}

Когда приложение перезапускается, оно может открыть эти поля, выполняя обратное действие в делегате applicationDidBecomeActive:

- (void)applicationDidBecomeActive:(UIApplication *)application {
viewController.creditcardNumber.hidden = NO;
}

5. Проблемы повреждения памяти

Введение

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

5.1. Строки формата

Уязвимости строк формата являются классом багов повреждения памяти, которые возникают при неправильном использовании методов Objective-C, принимающих спецификатор формата. Уязвимые методы Objective-C включают:

• NSLog
• [NSString stringWithFormat]
• [NSString stringByAppendingFormat]
• [NSString initWithFormat]
• [NSMutableString appendFormat]
• [NSAlert alertWithMessageText]
• [NSAlert informativeTextWithFormat]
• [NSException format]
• [NSMutableString appendFormat]
• [NSPredicate predicateWithFormat]

Уязвимости строк формата возникают, когда атакующий может частично или целиком предоставить спецификатор формата подходящему методу. Рассмотрим следующий пример:

NSString *myURL=@"http://10.0.2.1/test";
NSURLRequest *theRequest = [NSURLRequest requestWithURL:[NSURL
URLWithString:myURL]];
NSURLResponse *resp = nil;
NSError *err = nil;
NSData *response = [NSURLConnection sendSynchronousRequest: theRequest
returningResponse:&resp error: &err];
NSString * theString = [[NSString alloc] initWithData:response
encoding:NSASCIIStringEncoding];
NSLog(theString);

В данном примере делается запрос к веб-серверу, запущенному по адресу 10.0.2.1. Ответ затем сохраняется в объекте NSData, конвертируется в NSString и логируется с помощью NSLog. Вот документированное использование функции NSLog, которая является оберткой для NSLogv (args представляет переменное число аргументов):

void NSLogv (
NSString *format,
va_list args
);

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

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

bash-3.2# nc -lvp 80
listening on [any] 80 ...
10.0.2.2: inverse host lookup failed: Unknown host
connect to [10.0.2.1] from (UNKNOWN) [10.0.2.2] 52141
GET /test HTTP/1.1
Host: 10.0.2.1
User-Agent: fmtstrtest (unknown version) CFNetwork/548.0.4 Darwin/11.0.0
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 16

aaaa%x%x%x%x%x%x

Тело HTTP-ответа логируется в NSLog и запускает уязвимость формата строки, что приводит к выгрузке содержимого стека в консольный лог, как показано ниже:

(gdb) r
Starting program: /private/var/root/fmtstrtest
objc[8008]: Object 0x11f0b0 of class NSURL autoreleased with no pool in place -
just leaking - break on objc_autoreleaseNoPool() to debug
objc[8008]: Object 0x11e310 of class NSURLRequest autoreleased with no pool in
place - just leaking - break on objc_autoreleaseNoPool() to debug
objc[8008]: Object 0x11f540 of class NSThread autoreleased with no pool in place
- just leaking - break on objc_autoreleaseNoPool() to debug
2012-02-29 17:02:36.304 fmtstrtest[8008:303] aaaa124a600782fe5b84411f0b00
Program exited normally.
(gdb)

Эксплуатировать традиционные уязвимости строк формата можно путем использования спецификатора формата "%n", позволяющего атакующему записывать информацию по произвольному адресу памяти, взятому из стека. Однако, данный спецификатор формата не доступен в Objective-C. Вместо этого уязвимости строк формата iOS могут эксплуатироваться с помощью спецификатора "%@", который соответствует объекту Objective-C. Данный спецификатор можно использовать для вызова произвольного указателя на функцию.

Рассмотрим следующий пример (взятый из [7]), который просто передает значение из argv[1] в NSLog:

int main(int argc, const char* argv[])
{
NSAutoreleasePool *pool =[[NSAutoreleasePool alloc] init];
NSString *n = [[NSString alloc] initWithCString:argv[1]];
NSLog(n);
[pool drain];
return 0;
}

Вытолкнув из стека достаточное количество данных для достижения части стека, контролируемой пользователем, мы увидим, как спецификатор %@ вызовет аварийное завершение при разыменовывании указателя:

(gdb) r
bbbbbbbbbbbbbbbb%x%x%x%x%x%x%x%%x%x%x%x%x%x%x%%x%x%x%x%x%x%x%%x%
x%x%x%x%x%x%%x%x%
x%x%x%x%x%%x%x%x%x%x%x%x%%x%x%x%x%x%x%x%%x%x%x%x%x%x%x%%x%x%x%x%
x%x%x%x%x%x%@
Starting program: /private/var/root/fmtstrtest
bbbbbbbbbbbbbbbb%x%x%x%x%x%x%x%%x%x%x%x%x%x%x%%x%x%x%x%x%x%x%%x%
x%x%x%x%x%x%%x%x%
x%x%x%x%x%%x%x%x%x%x%x%x%%x%x%x%x%x%x%x%%x%x%x%x%x%x%x%%x%x%x%x%
x%x%x%x%x%x%@

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x62626262
0x320f8fb6 in ?? ()
(gdb)

Однако, в большинстве ситуаций Objective-C будет использовать для хранения объектов кучу, а, значит, на практике эксплуатация рассмотренной уязвимости маловероятна. Дальнейшая информация по эксплуатированию уязвимостей строк формата может быть найдена в [7].

5.2. Использование объекта после освобождения

Уязвимости, связанные с использованием объекта после освобождения, возникают, когда ссылка на объект продолжает существовать после освобождения объекта. Если данная освобожденная память используется повторно, атакующий может повлиять на нее и, в некоторых случаях, даже выполнить произвольный код. Эксплуатация подобных уязвимостей в Objective-C подробно задокументирована в [21]. Рассмотрим следующий пример:

MDSec *mdsec = [[MDSec alloc] init];
[mdsec release];
[mdsec echo: @"MDSec!"];

В вышеприведенном примере экземпляр класса MDSec сначала создается, а затем освобождается, используя release. Однако, после освобождения объекта вызывается метод echo, которому передается ранее освобожденный указатель. В данном случае аварийное завершение, вероятно, не случится, поскольку память не была повреждена перевыделением или деконструкцией.

Тем не менее, рассмотрим пример, в котором происходит распыление контролируемых пользователем данных по куче:

MDSec *mdsec = [[MDSec alloc] init];
[mdsec release];
for(int i=0; i<=50000; i++) {
char *buf = strdup(argv[1]);
}
[mdsec echo: @"MDSec!"];

Запуск этого примера приведет к нарушению доступа (access violation) в том месте, где вызывается метод echo, из-за повторного использования памяти кучи, использованной ранее освобожденным экземпляром объекта:

(gdb) r AAAA
Starting program: /private/var/root/objuse AAAA

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x41414149
0x320f8fbc in ?? ()
(gdb)

В iOS 5 был введен автоматический подсчет ссылок (Automatic Reference Counting, ARC, см. раздел 3.4), который перекладывает ответственность за управление памятью с разработчика на компилятор. Поэтому для приложений, использующих ARC, характерно значительное уменьшение проблем, связанных с использованием после освобождения: разработчик более не несет ответственности за особождение или сохранение объектов.

6. Заключение

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

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

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

Хотя уязвимости мобильных устройств вряд ли исчезнут в ближайшем будущем, появление таких проектов, посвященных мобильной безопасности, как OWASP [22], увеличит осведомленность о проблемах мобильной безопасности и, надеюсь, поможет поднять планку в разработке приложений для мобильных устройств. Организациям, которые хотят производить безопасные мобильные приложения, следует интегрировать аудит безопасности по всему жизненному циклу разработки и убедиться, что разработчики и QA-команды получают достаточное образование в области безопасности.

7. Список проверки соответствия iOS-приложения требованиям безопасности

В ходе проверки iOS-приложений полезно иметь список базовых требований, которым должно соответствовать приложение. Это обеспечивает руководящими принципами не только аудиторов безопасности, но и разработчиков. Ниже MDSec представляет возможную основу для ведения оценок безопасности в iOS:

Требование	Соответствие
Защита на уровне компилятора
Приложение скомпилировано с PIE	PASS/FAIL
Приложение скомпилировано со стековыми канарейками	PASS/FAIL
Приложение использует автоматический подсчет ссылок	PASS/FAIL
Безопасность передачи данных
Приложение отвергает самоподписанные сертификаты: allowsAnyHTTPSCertificateForHost / continueWithoutCredentialForAuthenticationChallenge	PASS/FAIL
Приложение отвергает просроченные сертификаты: kCFStreamSSLAllowsExpiredCertificates	PASS/FAIL
Приложение проверяет корневые сертификаты: kCFStreamSSLAllowsAnyRoot	PASS/FAIL
Приложение проверяет цепочку сертификатов:	PASS/FAIL
Межпроцессное взаимодействие
Приложение проверяет source bundle: handleOpenURL	PASS/FAIL
Приложение проверяет содержимое IPC-параметров	PASS/FAIL
Хранение данных
Приложение шифрует данные, записываемые с помощью NSData	PASS/FAIL
Приложение шифрует данные, записанные с помощью NSFileManager	PASS/FAIL
Связка ключей
Элементы связки ключей защищены Data Protection API : SecItemAdd / SecItemUpdate	PASS/FAIL
UIWebViews
Приложение не загружает UIWebView из локального ресурса	PASS/FAIL
Приложение проверяет контролируемое пользователем содержимое, передаваемое в UIWebView:stringByEvaluatingJavaScriptFromString	PASS/FAIL
Обработка XML
Приложение отключает внешние сущности с помощью NSXMLParser:setShouldResolveExternalEntities	PASS/FAIL
Приложение отключает внешние сущности с помощью LibXML2	PASS/FAIL
Приложение строит XML с управляемыми пользователем строками	PASS/FAIL
SQL
Приложение использует параметризованные запросы для доступа к данным: sqlite3_prepare_v2	PASS/FAIL
Файловая система
Приложение очищает путь от символов обхода дерева папок	PASS/FAIL
Приложение проверяет пути, хранящиеся в NSString на наличие нулевого байта	PASS/FAIL
Геолокация
Приложение использует подходящий уровень точности данных: CLLocationAccuracy	PASS/FAIL
Приложение не логирует данные о местоположении на стороне клиента	PASS/FAIL
Логирование
NSLog отключен в финальных сборках	PASS/FAIL
Специально созданные логи не содержат конфиденциальной информации	PASS/FAIL
Фоновое выполнение
Приложение делает конфиденциальную информацию недоступной для просмотра при переходе в фон: applicationDidEnterBackground	PASS/FAIL
Повреждение памяти
Приложение использует корректные спецификаторы формата для уязвимых функций	PASS/FAIL
Приложение не ссылается на освобожденные объекты	PASS/FAIL

8. О MDSec

MDSec, компания, создавшая справочник хакера по веб-приложениям (Web Application Hacker’s Handbook),– это всемирный авторитет со страстью к информационной безопасности. Это помогло добиться нашей роли в определении, формализации и расширении информационной безопасности через публикации, инструменты и проводимые по всему миру тренинги. Как нейтральная относительно вендоров организация без внешних вложений, мы можем использовать полученный нашей командой за годы работы смешанный опыт, чтобы дать совет по техническим и нетехническим вопросам.

Компания была основана в 2011 году и показала взрывной рост своей базы клиентов, которая включает престижные компании с различными видами деятельности по всему миру. Если вы хотите понять, как MDSec может помочь безопасности вашей организации, пожалуйста, не стесняйтесь писать на почту sales@mdsec.co.uk для дружелюбного и открытого обсуждения вопросов.

9. Благодарности

Автор хотел бы поблагодарить Маркуса Пинто из MDSec, Олли Вайтхауза из Recx и Хьюберта Сейверта за советы и рекомендации в ходе разработки и рецензирования данного документа.

10. Ссылки

[1] Mobile/Tablet Top Operating System Share Trend - NetMarketShare
http://www.netmarketshare.com/operating-system-market-
share.aspx?qprid=9&qpcustomb=1
[2] Apple iOS 4 Security Evaluation – Dino Dai Zovi
https://media.blackhat.com/bh-us-
11/DaiZovi/BH_US_11_DaiZovi_iOS_Security_WP.pdf
[3] iOS Standard Agreement
https://developer.apple.com/programs/terms/ios/standard/ios_standard_agre
ement_20100909.pdf
[4] Address Space Layout Randomization
http://en.wikipedia.org/wiki/Address_space_layout_randomization
[5] Steffan Esser’s ASLR Research
http://antid0te.com/CSW2012_StefanEsser_iOS5_An_Exploitation_Nightmare
_FINAL.pdf
http://www.suspekt.org/
[6] Apple Sandbox - Dionysus Blazakis
http://securityevaluators.com/files/papers/apple-sandbox.pdf
[7] Auditing iPhone and iPad Applications – Ilja van Sprundel
http://cansecwest.com/csw11/iPhone%20and%20iPad%20Hacking%20-
%20van%20Sprundel.ppt
[8] Secure Development on iOS – David Thiel
http://www.isecpartners.com/storage/docs/presentations/iOS_Secure_Develo
pment_SOURCE_Boston_2011.pdf
[9] Crackulous
http://hackulo.us/wiki/Crackulous
[10] Mach-O File Format Reference
https://developer.apple.com/library/mac/#documentation/developertools/conc
eptual/MachORuntime/Reference/reference.html
[11] Class-Dump-Z
http://code.google.com/p/networkpx/wiki/class_dump_z
[12] MobileSubstrate
http://iphonedevwiki.net/index.php/MobileSubstrate iOS Application (In)Security
[13] Cycript: Objective-Javascript
http://www.cycript.org/
[14] iOSOpenDev
http://www.iosopendev.com/
[15] Insecure Handling of URL Schemes in Apple’s iOS – Nitesh Dhanjani
http://software-security.sans.org/blog/2010/11/08/insecure-handling-url-
schemes-apples-ios/
[16] Citigroup iPhone Data Storage Issues
http://www.theregister.co.uk/2010/07/27/citi_iphone_app_weakness/
[17] iPhone data protection in depth
http://esec-lab.sogeti.com/dotclear/public/publications/11-hitbamsterdam-
iphonedataprotection.pdf
[18] Keychain Dumper
https://github.com/ptoomey3/Keychain-Dumper
[19] Skype iOS XSS
https://superevr.com/blog/2011/skype-xss-explained/
[20] Billion Laughs
http://en.wikipedia.org/wiki/Billion_laughs
[21] Abusing the Objective-C Runtime
http://www.phrack.org/issues.html?issue=66&id=4
[22] OWASP Mobile Security Project
https://www.owasp.org/index.php/OWASP_Mobile_Security_Project