Мобильные платформы предоставляют множество различных услуг для защиты сетевых коммуникаций от аутентификации до обеспечения безопасного хранения данных. Таким образом если некорректно использовать какую-либо часть платформы, можно выставить данные незащищенными или разрешить соединения с ненадежными хостами. В данном разделе про Android часть 11 мы суммировали все сказанное в предыдущих частях и привели контрольный список Android.
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
Определяющей характеристикой рисков в этой категории является то, что платформа (iOS, Android, Windows Phone и т. д.) предоставляет функцию или возможность, которая документирована и хорошо понята. Приложение вовсе не использует эту возможность или неправильно использует ее.
Существует несколько вариантов, когда мобильные приложения могут столкнуться с этим риском.
Нарушение опубликованных рекомендаций - Контрольный список Android
На всех платформах есть рекомендации по обеспечению безопасности (c.f., ((Android)), ((iOS)), ((Windows Phone))). Если приложение противоречит рекомендациям, которые были указаны производителем, оно будет подвержено этому риску.
Нарушение соглашения или обычной практики
Не все передовые методы кодифицированы в руководстве производителя. В некоторых случаях существуют лучшие практики, которые распространены в мобильных приложениях.
Непреднамеренное злоупотребление - Контрольный список Android
Некоторые приложения намереваются делать правильные вещи, но фактически неправильно их реализовывают. Это может быть простая ошибка, например, установка неправильной отметки в вызове API, или это может быть непонимание того, как работают защитные функции.
Эта категория охватывает неправильное использование функции платформы или отказ использовать средства контроля безопасности платформы. Это может включать в себя задачи Android, права доступа к платформе, неправильное использование Touch ID, Keychain или какого-либо другого элемента управления безопасностью, который является частью мобильной операционной системы. Существует несколько ситуаций, когда мобильные приложения могут столкнуться с этим риском.
Мобильные платформы предоставляют множество различных услуг, от аутентификации, до обеспечения безопасного хранения данных, для защиты сетевых коммуникаций. Таким образом, если некорректно использовать какую-либо часть платформы, можно выставить данные незащищенными или разрешить соединения с ненадежными хостами, а иногда даже позволить проведение мошеннических платежей.
Конфиденциальность и права доступа в мобильных приложениях также являются важной частью платформы. Таким образом, отказ от использования функций платформы может подвергнуть конечного пользователя риску нарушения конфиденциальности.
Название теста и его описание
Чрезвычайный порт, открытый в брандмауэре - Идентифицирует открытый порт на стороне сервера URL/IP адреса
Учетные данные по умолчанию на сервере приложения - Определяет учетные данные по умолчанию на вторичном сервере (например, сервер приложений Tomcat с использованием tomcat / tomcat, admin / tomcat)
Выявление веб-сервисов через документ WSDL - Определение страницы справки webservices (* .asmx), которые показывают методы и структуру
Неверная настройка безопасности на веб-сервере - Определение конфигурации веб-сервера (например, обработка ошибок, баннер ответа HTTP)
Проверка ввода в API - Проверка правильности ввода на API/Web сервисах
Выявление информации через ответное сообщение API - Определение конфиденциальной информации по ответному сообщению / заголовку API
Сенсорный идентификатор и Keychain - Проверяет проходил ли обход локальной аутентификации через изменение локальной проверки во время рабочего цикла. Проверяет, можем ли мы получить пароль или конфиденциальную информацию из Keychain
Небезопасные права доступа файлов - Проверяет, использует ли приложение доступные для доступа к файлам «читаемые» и «перезаписываемые» права доступа файла, которые могут вызвать утечку данных и выявить приложения для злоумышленников, которые могут перезаписать данные приложения.
Скрытый сниффинг (анализатор траффика) - Проверяет, может ли вредоносное приложение Android регистрироваться для получения трансляции или скрытых целей из любого другого приложения.
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
Небезопасное хранение данных и непреднамеренная утечка данных
Небезопасное хранение данных, а также различного рода уязвимости возникают, когда команды разработчиков предполагают, что пользователи или вредоносные программы не будут иметь доступа к файловой системе мобильного устройства и последующей конфиденциальной информации в хранилищах данных на устройстве. Файловые системы довольно легко доступны. Организации должны ожидать, что злоумышленник или вредоносная программа детально обследует конфиденциальные хранилища данных.
Rooting или джейлбрейк мобильного устройства обходит любую защиту от шифрования. Когда данные не защищены должным образом все, что понадобится для просмотра данных приложения, так это всего лишь специализированные инструменты. Непредвиденная утечка данных возникает, когда разработчик непреднамеренно помещает конфиденциальную информацию или данные в местоположение на мобильном устройстве, которое легко доступно для других приложений на устройстве.
Во-первых, код разработчика обрабатывает конфиденциальную информацию, предоставленную пользователем или выходным буфером. Во время этой обработки побочный эффект (неизвестный разработчику) приводит к тому, что эта информация помещается в небезопасное местоположение на мобильном устройстве, к которому также могут иметь доступ другие приложения на мобильном устройстве.
Данные, хранящиеся небезопасно, включают в себя: файлы журналов, файлы plist, SD-карту, хранилища данных XML, базы данных, хранилища двоичных данных, синхронизацию облачных данных, данные кэширования операционной системы, изображения, сочетание клавиш (key-presses), протоколирование и буферы.
Название теста Описание
Жестко кодированные учетные данные в исходном коде - Определяет конфиденциальную информацию в исходном коде
Неограниченный резервный файл - Проверьте атрибут "android: allowBackup", который должен быть установлен на "false" («ложный»)
Незашифрованные файлы базы данных - Проверка шифрования файлов базы данных
Небезопасное общее хранилище - Определение конфиденциальных данных на общем хранилище, шифрования хранилища SD-карт, общих настроек MODE_WORLD_READABLE
Небезопасное хранение данных приложения - Определение конфиденциальных данных в файлах приложений, файлы кэша, файлы cookie)
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
Мобильные приложения часто не защищают сетевой трафик. Они могут использовать SSL / TLS во время аутентификации, но не где-либо еще. Эта несогласованность приводит к риску разоблачения данных и идентификаторов сеанса для перехвата.
Использование безопасности при передаче, не означает, что приложение реализовывает её правильно. Чтобы обнаружить основные недостатки, наблюдайте за сетевым трафиком телефона. Более хитроумные недостатки требуют проверки структуры и конфигурации приложения.
Существуют следующие источники угроз
- Злоумышленник, который разделяет вашу локальную сеть (взломанный или контролируемый Wi-Fi);
- Несущие или сетевые устройства (маршрутизаторы, сотовые башни, прокси и т. Д.);
- Правильно ли шифруются все соединения, а не только одно из них, которым вы владеете?
- Имеют ли сертификаты SSL последнее обновление?
- Подписаны ли SSL-сертификаты?
- Использует ли SSL достаточно высокую силу шифрования?
- Будет ли ваше приложение принимать одобренные пользователем сертификаты?
Название теста Описание
Insecure Transport Layer Protocols - Показывает, является ли траффик HTTPS или HTTP
TLS Authenticity Flaws - Проверяет Poodle, Beast, CRIME, BREACH, Heartbleed
TLS Weak Encryption - Проверяет упрочнение шифра TLS/SSL
Bypassing TLS Certificate Pinning - Проверяет привязку TLS/SSL
M4 – Небезопасная аутентификация – Контрольный список Android
Плохие или отсутствующие схемы аутентификации позволяют злоумышленнику анонимно выполнять функции в мобильном приложении или вторичном сервере, используемом мобильным приложением. Более слабая аутентификация для мобильных приложений довольно распространена из-за форм-фактора ввода мобильного устройства.
Форм-фактор очень поощряет короткие пароли, которые часто основаны на четырехзначных PIN-кодах. Требования к аутентификации для мобильных приложений могут отличаться от традиционных схем проверки подлинности в Интернете из-за требований доступности. В мобильных приложениях пользователи не должны быть в сети все время на протяжении всего сеанса. Мобильные интернет-соединения намного менее надежны или предсказуемы, чем традиционные веб-соединения.
Следовательно, мобильные приложения могут обладать периодом безотказной работы, который требует офлайн аутентификацию. Это «офлайн требование» может иметь серьезные последствия на те вещи, которые разработчики должны учитывать во время реализации мобильной аутентификации. Чтобы обнаружить плохие или слабые схемы аутентификации, тестировщики могут выполнять бинарные атаки (binary attacks) против мобильного приложения, находясь в режиме «офлайн».
В результате атаки тестировщик заставит приложение обходить офлайн аутентификацию, а затем уже выполнять функции, которые требуют офлайн проверку подлинности (аутентификацию). Кроме того, тестировщики должны анонимно выполнять функции вторичного сервера, удаляя все токены сеанса из любых запросов POST/GET для обеспечения надлежащей функциональности мобильного приложения.
Аутентификация пользователя локально может привести к обходу уязвимостей на стороне клиента. Если приложение хранит данные локально, подпрограмма аутентификации может быть обойдена на джейлбрейк-устройствах через манипуляцию в период работы или через изменения двоичного файла.
По возможности убедитесь, что все запросы на проверку подлинности выполняются на стороне сервера. После успешной аутентификации данные приложения будут загружены на мобильное устройство. Это гарантирует, что данные приложения будут доступны только после успешной проверки подлинности.
Если требуется хранение данных на стороне клиента, данные необходимо зашифровать, используя ключ шифрования, который безопасно получен из учетных данных пользователя. Это гарантирует, что сохраненные данные приложения будут доступны только после успешного ввода правильных учетных данных.
Существуют дополнительные риски, связанные с тем, что данные будут расшифрованы через бинарные атаки. Функция постоянной аутентификации (Запомнить меня (Remember Me)), реализованная в мобильных приложениях, никогда не должна хранить пароль пользователя на устройстве.
В идеале мобильные приложения должны использовать токен аутентификации устройства, который может быть отменен пользователем в мобильном приложении. Это гарантирует, что приложение может уменьшить риски несанкционированного доступа с похищенного/потерянного устройства.
Никогда не используйте значения паролей, которые легко подобрать логически, для аутентификации пользователя. Сюда относятся идентификаторы устройств или геолокация. Персистентная аутентификация в мобильных приложениях должна быть реализована как опция, а не включена по умолчанию.
Неправильное поведение во время сеанса обычно приводит к тем же результатам, что и некорректные действия во время аутентификации. После аутентификации и входа в сеанс, он может позволить получить доступ к мобильному приложению. Код мобильного приложения должен защищать пользовательские сессии так же тщательно, как и его механизм аутентификации.
Вот несколько примеров того, как это часто делается неправильно – Контрольный список Android
- Неудача в признании недействительными сеансов в выходном буфере
- Отсутствие достаточной защиты с помощью лимита времени
- Неправильная замена файлов cookie
- Небезопасное создание токена
- Невозможность идентифицировать пользователя вообще, когда это необходимо
- Неспособность поддерживать личность пользователя, когда это необходимо
- Слабые стороны в управлении сеансами
Название теста Описание
Раскрытие информации через Logcat/системный журнал Apple (Apple System Log (ASL)) - Определение конфиденциальной информацией через журнал приложений
Application Backgrounding (Screenshot) - Определение фонового рисунка снимка приложения / скриншота
URL Caching (HTTP Request and Response) on cache.db - Определение HTTP-кеширования, которое хранится в Cache.db
Кэширование клавиатуры - Определение файла кеша клавиатуры, расположенного в: /var/mobile/Library/Keyboard
Кэширование буфера копирования/вставки - Определение функции копирования/ вставки для конфиденциальной части приложения на EditText/UITextField
Отображение определенных идентификаторов устройства в качестве видимых для атакующего элементов - Наблюдение за сетевым трафиком устройства через прокси, с целью определения отправляется информация об устройстве (UDID) во время передачи или нет.
Использование небезопасных векторов аутентификации проверка на наличие скрытых запросов службы, политики паролей. - Угрозы обхода локальной аутентификации
Проверка политики доступа или наличия слабой аутентификации, которая позволяет подделать действительную идентификационную информацию. - Проверяет имя пользователя и пароль по умолчанию.
Ошибки аутентификации на стороне клиента - Проверка, внедрен ли HTTP в несколько разных типов протоколов аутентификации. например, Basic-Base-64 encode, Digest, NTLM, Microsoft Passport - служба единого входа (A single-sign-in service (SSI)), согласованность и форма (Negotiate and Form-based).
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
Небезопасное использование криптографии распространено в большинстве мобильных приложений, которые используют шифрование. Существует два основных способа, по которым некорректная криптография проявляется в мобильных приложениях. Во-первых, мобильное приложение может использовать процесс шифрования/дешифрования, который в корне ошибочен и может быть использован злоумышленником для дешифрования конфиденциальных данных.
Во-вторых, мобильное приложение может реализовать или использовать алгоритм шифрования/дешифрования, который является слабым по своей природе и может быть непосредственно расшифрован злоумышленником. В следующих подразделах более подробно рассматриваются оба этих сценария:
Опора на встроенные процессы шифрования кода – Контрольный список Android
Используя свободно доступные инструменты, такие как ClutchMod или GBD, злоумышленник загрузит зашифрованное приложение на взломанное устройство и сделает снимок дешифрованного приложения, как только загрузчик iOS загрузит его в память и расшифрует его (незадолго до того, как загрузчик начнет выполнение).
Когда злоумышленник делает снимок и сохраняет его на диске, он может использовать такие инструменты, как IDA Pro или Hopper, чтобы легко выполнять статический/динамический анализ приложения и проводить дальнейшие бинарные атаки.
Некорректно выполненный процесс управления ключами - Контрольный список Android
Многие ошибаются в использовании правильного алгоритма шифрования, вместо этого они реализуют свой собственный протокол для его использования. Вот некоторые примеры проблем, которые могут возникнуть в связи с этим:
- Включение ключей в один и тот же каталог, считываемый злоумышленником, как зашифрованный контент;
- Ключи становятся доступными для злоумышленника;
- Избегание использования жестко закодированных ключей в вашем двоичном коде;
Создание и использование пользовательских протоколов шифрования - Контрольный список Android
Всегда используйте современные алгоритмы, которые воспринимаются сообществом безопасности как сильные, и, когда это возможно, используют современные API-интерфейсы шифрования на вашей мобильной платформе.
Бинарные атаки могут привести к тому, что злоумышленник определит общие библиотеки, которые вы использовали вместе с любыми жестко закодированными ключами в двоичном формате. В случаях с очень высокими требованиями к безопасности, которые связаны с шифрованием, вам следует серьезно подумать об использовании white-box криптографии.
Использование небезопасных и/или устаревших алгоритмов - Контрольный список Android
Многие криптографические алгоритмы и протоколы не должны использоваться, поскольку они показали, что имеют значительные недостатки или же являются недостаточно современными, чтобы удовлетворить требования безопасности. К ним относятся:
RC2,MD4,MD5,SHA1
Название теста Описание
Мощная защита хранилища с помощью надежной криптографии - Определение небезопасных/устаревших криптографических алгоритмов (RC4, MD5, SHA1) в исходном коде
Некорректно произведенный процесс управления ключами - Идентификация жестко закодированного ключа в приложении и ключей, которые могут быть перехвачены с помощью бинарных атак
Использование пользовательских протоколов шифрования - Определить реализацию собственного протокола
Вот мы предоставили вам первую часть контрольного списка тестирования на проникновение для мобильных приложений. Следите за обновлениями для того, чтобы во время ознакомиться со следующей частью контрольного списка Android.