Угроза исследования приложения через отчёты об ошибках

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

• Внешний нарушитель со средним потенциалом
• Внутренний нарушитель со средним потенциалом

• Нарушение конфиденциальности

Угроза исследования приложения через отчеты об ошибках (Crash Reporting) заключается в том, что злоумышленники могут использовать информацию, содержащуюся в этих отчетах, для анализа работы приложения, выявления уязвимостей, получения конфиденциальной информации (например, путей к файлам, ключей API, внутренних IP-адресов) и разработки эксплойтов. Даже “заанонимизированные” или “обезличенные” данные могут быть сопоставлены с другими источниками для деанонимизации.

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

1. Ограничение информации в отчетах об ошибках:

• Минимальный объем информации: Собирать только необходимый минимум информации, достаточный для диагностики и исправления ошибок. Избегать сбора конфиденциальных данных, таких как персональные данные пользователей, ключи API, пароли или данные банковских карт.
• Удаление или маскировка конфиденциальных данных: Автоматически удалять или маскировать конфиденциальные данные из отчетов об ошибках. Это может включать в себя:
  • Замену реальных значений на случайные или предопределенные строки.
  • Хеширование конфиденциальных данных.
  • Удаление фрагментов кода, содержащих конфиденциальную информацию.
• Ограничение размера отчетов: Установить лимит на максимальный размер отчетов об ошибках, чтобы предотвратить случайное включение большого объема данных.
• Фильтрация трассировки стека: Тщательно фильтровать трассировку стека, чтобы исключить пути к файлам и другие внутренние детали реализации, которые могут быть полезны для злоумышленников.
• Обработка строк: При работе со строками, которые могут содержать конфиденциальную информацию, использовать безопасные методы обработки и избегать использования toString() без предварительной очистки.

2. Безопасность хранения и передачи отчетов:

• Шифрование отчетов: Шифровать отчеты об ошибках при хранении и передаче, чтобы защитить их от несанкционированного доступа.
• Защищенное хранилище: Хранить отчеты об ошибках в защищенном хранилище с ограниченным доступом.
• Использовать HTTPS: Использовать HTTPS для передачи отчетов об ошибках.
• Аутентификация и авторизация: Требовать аутентификацию и авторизацию для доступа к отчетам об ошибках.

3. Контроль доступа и мониторинг:

• Ограничение доступа: Ограничить доступ к отчетам об ошибках только авторизованным сотрудникам, которым они необходимы для выполнения их работы.
• Регулярный аудит: Регулярно проводить аудит доступа к отчетам об ошибках и выявлять подозрительную активность.
• Мониторинг: Мониторить использование отчетов об ошибках для выявления аномального поведения.

4. Политики безопасности:

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

5. Использование специализированных сервисов Crash Reporting:

• Оценка рисков: При использовании сторонних сервисов Crash Reporting тщательно оценивать их политики безопасности и конфиденциальности.
• Конфигурация сервисов: Настраивать сервисы Crash Reporting таким образом, чтобы они собирали только необходимый минимум информации и применяли необходимые меры безопасности.
• Изучение документации: Внимательно изучать документацию сервиса и правильно его конфигурировать для обеспечения безопасности.
• Соблюдение GDPR и других законов о защите данных: Убедитесь, что сервис Crash Reporting соответствует требованиям GDPR, CCPA и другим законам о защите данных.

6. Использование Code Signing:

• Подписывать код приложения: Подписывать код приложения с использованием цифровых подписей. Это позволяет убедиться в подлинности кода и предотвратить его подмену.

7. Анти-отладка и обфускация кода:

• Использовать методы обфускации кода: Затруднить анализ кода приложения, чтобы усложнить выявление уязвимостей на основе отчетов об ошибках.
• Применять техники Anti-Debugging: Защитить приложение от отладки, чтобы злоумышленники не могли анализировать его работу в отладчике.

8. Автоматическое удаление старых отчетов:

• Удалять старые отчеты: Автоматически удалять старые отчеты об ошибках после определенного периода времени, чтобы минимизировать риск утечки информации.

9. Проверка на наличие уязвимостей известных библиотек:

• Регулярно проверять зависимости: Регулярно проверять зависимости вашего проекта на наличие известных уязвимостей (например, используя OWASP Dependency-Check). Уязвимые библиотеки могут содержать информацию, которая попадет в отчеты об ошибках.

10. Анонимизация IP-адресов:

• Маскировать IP-адреса: Анонимизировать IP-адреса пользователей, чтобы затруднить их идентификацию.

Примеры конкретных мер:

• В Android использовать android:name в <application> для настройки своего Application класса. В этом классе можно переопределить dispatchUncaughtException и предобработать исключения перед отправкой в Crash Reporting сервис.
• В iOS использовать NSSetUncaughtExceptionHandler для перехвата необработанных исключений и предобработки данных.

Ключевые моменты:

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

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