Введение

Как страстный поклонник телефонов Android, если ваш телефон внезапно выйдет из строя, вашей первой мыслью будет: «О боже!» или что ваши деньги в Google Pay или Paypal небезопасны? Если последнее загруженное приложение не только отображает различную скучную рекламу, но и неожиданные уведомления, можете ли вы подумать, что это попытка фишинга, и немедленно удалить приложение?

Как мы можем гарантировать, что наше приложение обеспечивает безопасную работу для пользователей, которые недостаточно осведомлены об уязвимостях безопасности Android? Каковы уязвимости безопасности в экосистеме Android? Где мы можем изучить новые методы тестирования безопасности Android? Как мы можем оптимизировать процесс тестирования безопасности?

Распространенные уязвимости безопасности Android

Во-первых, преимущество операционной системы Android в разработке с открытым исходным кодом также скрывает присущие ей проблемы безопасности, такие как песочница системы Android (т. е. виртуальная машина). Однако базовый уровень имеет одну уязвимость за другой, позволяя вредоносным программам (или инструментам) получать root-доступ и нарушать ограничения песочницы. Как и в эпоху ПК, не существует абсолютно безопасной операционной системы для ПК; В эпоху мобильного интернета не существует абсолютно безопасной мобильной операционной системы. Угрозы безопасности экосистемы Android с открытым исходным кодом подобны кровавым звонкам тревоги, поражающим сердца каждого разработчика Android.

Во-вторых, риски безопасности в процессе разработки приложений/SDK для Android подобны неизвестным черным дырам. Мы никогда не знаем, где находится конечная точка противостояния безопасности, кто атакующие, кто терминаторы и как от них защититься.

Наконец, на уровне пользователя, каковы некоторые распространенные и узнаваемые уязвимости в поведении безопасности?

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

Примеры тестирования безопасности приложений Android

Обзор причин уязвимости
Дополнительный компонент приложения (именуемый в дальнейшем приложением) Android SDK открыл случайный порт локально, чтобы отслеживать, работает ли служба уровня Java. Однако, когда уровень Java взаимодействует с компонентом, он не проверяет строго входные параметры, что приводит к возможности заполнения кодом атаки и вредоносными атаками при вызове функции «system()» системы Linux.

На следующем снимке экрана показано, что после атаки на порт моделирования намерение компонента приложения изменяет содержимое URL-адреса во время связи, а в Webview отображается искаженный код:

Потенциальные риски безопасности, связанные с уязвимостью

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

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

1. Локальное выполнение команды: если имя пакета встроенного приложения указано как само приложение, а имя компонента указано как активность приложения, любое действие приложения может быть началась, включая защищенную неэкспортируемую деятельность, что создает угрозу безопасности. Например, уязвимость типа «отказ в обслуживании» можно обнаружить, запустив одно за другим несколько неэкспортированных действий через HTTP-запросы.

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

3. Раскрытие конфиденциальной информации, управление мобильным телефоном: локальная служба открывает порт UDP для прослушивания и после получения определенного командного слова может вернуть конфиденциальную информацию мобильного телефона. Например, дворецкий мобильного телефона Baidu может удаленно управлять секретным ключом мобильного телефона, а затем несанкционированные злоумышленники могут полностью управлять мобильным телефоном через сеть.

Выполнение тестирования безопасности Android

Оптимизация версии для усиления безопасности Android

1. Добавьте проверки системных команд и фильтрацию специальных символов как на собственном уровне, так и на уровне Java.

2. Шифрование сокета для процесса демона JNI Watchdog.

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

4. Измените место хранения имени пакета в локальном хранилище приложения.

5. Добавьте функцию онлайн-конфигурации.

Это важные требования для оптимизации усиления безопасности.

Специальное тестирование безопасности

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

Регулярное регрессионное тестирование безопасности Android

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

2. Атаки на разрешения: проверьте каталог приложения и убедитесь, что его разрешения не позволяют другим членам группы читать или писать; проверьте, не подвергаются ли системные разрешения атаке.

3. Защита разрешений компонентов Android: предотвращение произвольного вызова внутренних компонентов приложения сторонними программами: предотвращение вызова действий сторонними программами, предотвращение перехвата действий; обеспечивать безопасность приема и передачи трансляций, получать только трансляции, отправленные приложением, и не допускать получения передаваемого контента третьими лицами; предотвратить злонамеренный запуск или остановку служб; проверьте разрешения на работу Контент-провайдера; если компоненты необходимо вызывать извне, проверьте, были ли применены ограничения подписи к вызывающей стороне.

4. Обновления: проверьте целостность и законность пакета обновления, чтобы избежать взлома.

5. Сторонние библиотеки: если используются сторонние библиотеки, следите за их обновлениями и проверяйте их безопасность.

6. Безопасность ПЗУ: используйте официальные ПЗУ или ПЗУ, предоставленные авторитетными командами, чтобы избежать добавления имплантированной рекламы, троянов и т. д.

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

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

Заворачивать

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

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

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

Доверьтесь WeTest, чтобы защитить свое приложение от потенциальных угроз и обеспечить безопасность пользователей.