тестирование безопасности мобильных приложений
Чек-лист тестирования мобильных приложений
У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда они приходят в компанию, где нет документации на проекте, либо это только что появившийся стартап. Чтобы ответить на эти вопросы была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого приложения.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Чек-лист для тестирования мобильных приложений состоит из восьми разделов:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
1. Установка/удаление/накатка версий
2. Запуск приложения (отображение Splash Screen)
3. Работоспособность основного функционала приложения
3.1 Авторизация (по номеру телефона/через соц. сети/e-mail)
3.2 Регистрация (по номеру телефона/через соц. сети/e-mail)
3.3 Онбординг новых пользователей
3.4 Валидация обязательных полей
3.5 Навигация между разделами приложения
3.6 Редактирование данных в профиле пользователя
3.7 Проверка оплаты
3.8 Тестирование фильтров
3.9 Бонусы
4. Корректное отображение ошибок
5. Работа с файлами (отправка/получение/просмотр)
6. Тестирование тайм-аутов
7. Тестирование заглушек (не соединения с интернетом/нет, например, товаров и т.д)
8. Тестирование pop-up, алертов
9. Тестирование WebView
10. Скролл/свайп элементов
11. Тестирование PUSH уведомлений
12. Сворачивание/разворачивание приложения
13. Разные типы подключений (сотовая связь/Wi-Fi)
14. Ориентация экрана (альбомная/портретная)
15. Темная/светлая темы
16. Реклама в приложении
17. Шаринг контента в соц. сети
18. Работа приложения в фоне
19. Пагинация страниц
20. Политики конфиденциальности и прочие ссылки на документы
Тестирование совместимости
Тестирование совместимости используется, чтобы убедиться, что ваше приложение совместимо с другими версиями ОС, различными оболочками и сторонними сервисами, а также аппаратным обеспечением устройства.
Что проверяем?
1. Корректное отображение гео
2. Информации об операциях (чеки и т.д.)
3. Различные способы оплаты (Google Pay, Apple Pay)
4. Тестирование датчиков (освещенности, температуры устройства, гироскоп и т.д.)
5. Тестирование прерываний (входящий звонок/смс/push/будильник/режим «Не беспокоить» и т.д.)
6. Подключение внешних устройств (карта памяти/наушники и т.д.)
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности приложения.
Что проверяем?
1. Тестирование разрешений (доступ к камере/микрофону/галерее/и т.д.)
2. Данные пользователя (пароли) не передаются в открытом виде
3. В полях, с вводом пароля и подтверждением пароля, данные скрываются астерисками
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют, а также замену фактических строк псевдостроками. Тестирование локализации включает тестирование приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Что проверяем?
1. Все элементы в приложении переведены на соответствующий язык
2. Тексты зашиты внутри приложения и пользователь в настройках приложения может выставить необходимый язык
3. Тексты зависят от языка в системных настройках
4. Тексты приходят с сервера
5. Корректное отображение форматов дат (ГОД — МЕСЯЦ — ДЕНЬ или ДЕНЬ — МЕСЯЦ — ГОД.)
6. Корректное отображение времени в зависимости от часового пояса
Тестирование удобства использования
Тестирование удобства использования помогает удостовериться в простоте и эффективности использования продукта пользователем, с целью достижения поставленных целей. Иными словами, это не что иное, как тестирование дружелюбности приложения для пользователя.
Что проверяем?
1. Корректное отображение элементов на устройствах с различными разрешениями экранов
2. Все шрифты соответствуют требованиям
3. Все тексты правильно выровнены
4. Все сообщения об ошибках верные, без орфографических и грамматических ошибок
5. Корректные заголовки экранов
6. В поисковых строках присутствуют плейсхолдеры
7. Неактивные элементы отображаются серым
8. Ссылки на документы ведут на соответствующий раздел на сайте
9. Анимация между переходами
10. Корректный возврат на предыдущий экран
11. Поддерживаются основные жесты при работе с сенсорными экранами (swipe back и т.д.)
12. Пиксель-перфект
Стрессовое тестирование
Стрессовое тестирование направлено на определение эффективности производительности приложения в условиях повышенной нагрузки. Стресс-тест в этом контексте ориентирован только на мобильные устройства.
Что проверяем?
1. Высокая загрузка центрального процессора
2. Нехватка памяти
3. Загрузка батареи
4. Отказы
5. Низкая пропускная способность сети
6. Большое количество взаимодействий пользователя с приложением (для этого может понадобиться имитация реальных условий состояния сети)
Кросс-платформенное тестирование
Важный вид тестирования, который необходимо проводить для понимания того, будет ли должным образом отображаться тестируемый продукт на различных платформах, используемых целевой аудиторией.
Что проверяем?
— Работоспособность приложения на различных устройствах разных производителей
Тестирование производительности
Если пользователь устанавливает приложение, и оно не отображается достаточно быстро (например, в течение трех секунд), оно может быть удалено в пользу другого приложения. Аспекты потребления времени и ресурсов являются важными факторами успеха для приложения, и для измерения этих аспектов проводится тестирование производительности.
Что проверяем?
1. Время загрузки приложения
2. Обработка запросов
3. Кэширование данных
4. Потребление ресурсов приложением (например расход заряда батареи)
Сам себе пентестер: как за пару дней проверить безопасность мобильного приложения
Авторизуйтесь
Сам себе пентестер: как за пару дней проверить безопасность мобильного приложения
В идеальном мире никто не проверил бы безопасность кода лучше тех, кто потратил дни и ночи на его написание. В нашем мире у разработчиков нет времени и опыта для такого аудита, и им занимаются отдельные люди — пентестеры.
Однако с хорошей инструкцией даже джуниор может сам провести базовый пентест за 1–2 дня.
Специалист по тестированию на проникновение компании BI.ZONE Олег Петраков расскажет, какими инструментами пользоваться и на что обращать внимание, чтобы быстро найти несложные уязвимости в мобильном приложении. Гайд поможет раньше узнавать о проблемах в коде, получать меньше правок на ревью и следить за безопасностью продукта, если никто больше этим не занимается.
Дисклеймер про термины Проверку приложения на уязвимости, которую в быту называют пентестом, эксперты по кибербезопасности назвали бы анализом защищенности. Пентест для них — другая задача: доказать, что в приложении есть хотя бы одна уязвимость, из-за которой его можно взломать. Однако наша статья написана не для экспертов по кибербезопасности, поэтому мы используем слово «пентест» в бытовом смысле.
специалист по тестированию на проникновение компании BI.ZONE
Готовим инструменты
На некоторых этапах экспресс-пентеста потребуются специальные инструменты. Большую часть из них вы, скорее всего, уже и так используете:
Если работаете с Android, еще пригодится бесплатная утилита Android Backup Extractor.
Из специфически пентестерского арсенала вам хватит единственного инструмента — Mobile Security Framework (MobSF). Это автоматизированный универсальный фреймворк, который помогает проводить аудит безопасности мобильных приложений. Загрузив в него ipa-образ для iOS или apk-образ для Android, вы сможете провести динамический и статический анализ сборки. MobSF полезен и для целей безопасной разработки: к примеру, с помощью раздела Files удобно отслеживать, не попадают ли в релизную сборку лишние файлы.
Следим за лишней информацией в релизных сборках
Для начала проверим, не осталось ли в релизной сборке отладочной информации и журналов работы приложения.
В случае отладочной информации нас интересуют такие артефакты, как адреса тестовых стендов и других компонентов, API-ключи тестовых сервисов (например, аналитики) или сообщения, которые использовались при отладке приложения.
Их нежелательно оставлять по нескольким причинам.
План действий. Убедитесь, что в вашем приложении такой информации не остается. В этом поможет фреймворк MobSF. Загрузите в него релизную сборку вашего приложения и сделайте следующее:
В случае с журналами работы приложения мы проверяем, что логи, выручавшие на этапе тестирования, не станут подспорьем для атакующего.
Само по себе журналирование трудно проэксплуатировать. Однако, как и отладочная информация, логи и строковые константы помогают злоумышленнику изучать работу приложения: дают идеи, за что зацепиться при поиске уязвимостей, позволяют расширить поверхность атаки.
План действий. Воспользуйтесь инструментами Console.app для iOS и adb для Android, чтобы увидеть, включено ли логирование в релизной сборке приложения и что туда попадает.
Чтобы логи не уходили в релизную сборку, лучшее решение — грамотно спроектировать класс Logger. Если же исправление нужно быстро, настройте в скриптах релизной сборки удаление методов логирования из кода. Для iOS-приложений это делается через препроцессорный макрос, а для Android — с помощью применения правил ProGuard.
Проверяем ограничение на отправку СМС
Следующим шагом ищем уязвимость к SMS Abuse: она одновременно и очень распространена, и весьма критична.
Это важно для приложений, в которых часть действий завязана на СМС: двухфакторная аутентификация, восстановление пароля, перевод денег и так далее.
Сообщения закупают у провайдера пакетами: например, оплачивают сразу миллион СМС в месяц. При этом на стороне сервера обычно нет ограничений на отправку СМС за единицу времени. Если атакующий запросит миллион сообщений, сервер их все отправит и исчерпает оплаченный пакет. В итоге разработчик потеряет деньги, а в худшем случае еще и клиентов: пока СМС не приходят, пользователи не могут решать свои задачи и переключаются на другой сервис.
План действий. Вспомните все эндпоинты, где операции требуют отправки СМС, и попробуйте отправить сразу по 20 запросов к каждому с одного IP-адреса или от одного пользователя. Если сообщения придут — система подвержена этой атаке.
Полностью защититься от атаки не получится, но можно сделать ее экономически невыгодной для злоумышленника. Для этого введите капчу при множественных запросах для одного пользователя. А еще хорошо, когда неаутентифицированный пользователь не может запрашивать СМС (кроме как для входа, конечно).
Проводим ревизию библиотек
Шаг короткий, но важный: надо убедиться, что ваши фреймворки и библиотеки собраны со всеми мерами безопасности. В противном случае злоумышленнику будет легче эксплуатировать ряд бинарных уязвимостей (пусть и сложных и редких).
План действий. С помощью MobSF посмотрите, какие библиотеки собраны неправильно и чего не хватает: для этого зайдите в раздел Security Analysis / Binary Analysis.
Исследуем компоненты для работы с внешними ссылками
Внешние ссылки (App Links, Deep Links, Universal Links) могли вам потребоваться по разным причинам:
Однако при встраивании компонентов для работы с внешними ссылками надо помнить: по отношению к другим приложениям эти компоненты всегда открыты. Следовательно, атакующий может отправлять им на обработку вредоносное содержимое. А это путь к обходу бизнес-логики приложения.
План действий. Дать здесь общую инструкцию не получится: все зависит от конкретной платформы и технологии. Но в целом шаг сводится к тому, что вам нужно пройти в коде по всем компонентам, обрабатывающим данные из внешних ссылок, и удостовериться, что у вас есть проверки на соответствие этих данных ожидаемому формату.
При встраивании компонентов для работы с App Links отдельно убедитесь, что ваш сервер сконфигурирован для проверки подписи вашего приложения (подробнее об этом — в инструкциях для разработчиков на iOS и на Android). Иначе ссылку могут перехватить.
Наконец, если ваше приложение обрабатывает и Deep Links, и App Links, определите для них разные компоненты: в противном случае нивелируются собственные меры безопасности, которые есть у App Links.
Проверяем другие открытые компоненты
В Android-клиентах специально определяют открытые компоненты — activity, сервисы и другие компоненты, которые могут обрабатывать запросы от других приложений, установленных на том же устройстве.
С точки зрения злоумышленника, каждый открытый компонент — это дополнительная поверхность атаки на ваш продукт. Из-за этого специалисты по кибербезопасности рекомендуют придерживаться минимализма и не множить открытые компоненты без необходимости.
План действий. Только вы можете решить, какие компоненты вам действительно важны для работы с другими приложениями и компонентами ОС. А увидеть их все в одном окне можно с помощью MobSF — для этого зайдите в раздел Security Analysis / Manifest Analysis.
Ищем недочеты в работе с компонентом WebView
Этот шаг актуален для приложений, которые задействуют WebView:
Для WebView нужны отдельные меры безопасности, а в некоторых ситуациях лучше вообще обойтись без таких компонентов. Сейчас все разберем.
План действий. Если вам нужно показать PDF-документ или статический HTML, не стоит добавлять компонент WebView. Лучше воспользоваться штатными возможностями системы: на iOS — UIDocumentInteractionController, на Android — ACTION_VIEW. Так ваш документ откроется в приложении, которое пользователь чаще всего использует для подобных задач. Это удобнее, проще и безопаснее.
Если задача чуть шире — например, вы показываете отчет, который наполняется динамически — WebView уместен. Главное — убедитесь, что при создании этого компонента вы отключили исполнение JavaScript-кода. Атакующий, как правило, не может повлиять на эти данные, однако отключить поддержку JavaScript-кода стоит из принципа минимальных привилегий.
Для сложных задач предпочтительнее использовать:
Изучаем данные в резервных копиях телефона
Если атакующий получит доступ к резервной копии телефона, он завладеет и всей информацией, которую вы туда сохранили. Опасен ли этот сценарий и оправдан ли риск, зависит от приложения. Но точно стоит обдумать эту перспективу, прежде чем встраивать создание резервных копий. Важно ли вам, чтобы данные вашего приложения могли быть восстановлены на другом телефоне? А вашему пользователю это необходимо?
План действий. Чтобы принять решение, проверьте, какую информацию приложение хранит в резервной копии. На iOS проще всего использовать обычный Finder (или iTunes), на Android — adb. Просмотреть содержимое резервной копии можно с помощью программ iMazing и Android Backup Extractor соответственно.
Ориентируемся на лучшие практики
Заключительный шаг проверки посвятим трем так называемым best practices. Их отсутствие само по себе не говорит об уязвимостях — но если встроить эти практики, защищенность пользователя сильно вырастет. А встраивать их несложно.
SSL Pinning
Без SSL Pinning, то есть механизма привязки сертификата сервера, приложение будет использовать политику проверки сертификата сервера по умолчанию. Это небезопасно: подмена точки доступа и немного социальной инженерии — и ваша разработка станет уязвима к атаке типа «человек посередине» (MitM). В результате такой атаки злоумышленник сможет читать и даже изменять сообщения, которые передаются между мобильным приложением и сервером: конфиденциальность обеспечить не выйдет.
Если решите встроить механизм, не ограничивайтесь HTTP-соединениями. SSL Pinning настраивается вообще для любого протокола, обернутого в TLS: веб-сокетов, XMPP и так далее.
План действий. Чтобы уточнить, настроен ли у вас SSL Pinning, и на iOS, и на Android потребуются одинаковые инструменты — Fiddler, Charles и подобные программы для отладки HTTP- и HTTPS-трафика. Но схема работы будет немного отличаться.
Размытие изображения в фоне
Применять размытие к приложению в фоне (использовать заставку) — рекомендация, которая подходит не всем. С одной стороны, размытие ухудшает опыт пользователей: им будет труднее переносить информацию в другое приложение, например браузер или блокнот. С другой стороны, размытие не даст захватить изображение в фоне не только пользователю, но и другим приложениям, в том числе вредоносным.
Для графического редактора этот механизм безопасности вряд ли будет актуален, а вот приложению для инвестиций его стоит рассмотреть.
План действий. Решить, подходит вам эта практика или нет, помогут ответы на два вопроса:
А если не помните, есть ли у вас размытие, самый быстрый способ это проверить — встать на место пользователя: сверните приложение и перейдите к отображению всех запущенных приложений.
Аутентификация на телефоне
Этот пункт касается использования криптографии при аутентификации, поэтому актуален только для приложений на Android: на iOS механизм работает совсем иначе.
Если в вашем приложении есть аутентификация по отпечатку пальца или графическому ключу, убедитесь, что у вас есть привязка к BiometricPrompt.CryptoObject. С ней вы будете пользоваться всеми возможностями криптографии на Android: при успешной локальной аутентификации приложение будет получать доступ к ключу шифрования, на котором расшифровывается объект, соответствующий сессии пользователя (например, refresh-токен).
План действий. Смотрите пример из мануала для Android-разработчиков: тут в деталях показано, как встроить привязку к CryptoObject.
Резюмируя
Если инструкция вдохновила вас на подвиги, полистайте гайд OWASP по пентесту мобильных приложений. Он понятно и в деталях рассказывает, как проверять безопасность продуктов под iOS и Android.
Но пентест не серебряная пуля. Лучшая защита — у тех приложений, которые создаются в рамках подхода security by design: когда безопасность берут в расчет с самого начала разработки.
А как бы вы закрыли перечисленные уязвимости? Предлагайте примеры в комментариях и советуйте, какие еще проверки стоит добавить в список.
Оценки безопасности мобильных приложений: лучшие практики для запуска и поддержки безопасного приложения
Рассматриваете ли вы оценку безопасности мобильного приложения?
Узнайте о 5 лучших способах компрометации приложений и основных видах тестирования и передовых методах.
Если вам интересно, является ли ваше мобильное приложение безопасным и защищенным, возможно, пришло время подумать об оценке безопасности.
Согласно отчету Nielsen Total Audience за первый квартал 2018 года, средний потребитель в США тратит в среднем три часа и 48 минут в день на цифровые носители, а потребители тратят 62% этого времени на приложения и использование Интернета через смартфоны.
Поскольку многим приложениям требуется доступ к пользовательским данным, создатели приложений должны обеспечить оптимальную безопасность для своей платформы.
Взлом данных с помощью мобильных приложений становится все более популярной целью среди киберпреступников, а средняя стоимость взлома данных составляет 3,86 млн. долларов.
Утечки данных через незащищенные сети Wi-Fi, слабая криптография или другие уязвимости могут сделать ваше приложение главной целью для коварных исполнителей угроз.
Узнайте о пяти лучших способах взлома приложений и о лучших мерах по тестированию безопасности для защиты вашего мобильного приложения.
Что такое безопасность приложений и почему это важно?
Безопасность приложений – это процесс тестирования и проверки приложения на предмет защиты мобильных приложений, веб-приложений или API от потенциальных атак.
Организациям часто не хватает опыта и пропускной способности для адекватного мониторинга своих приложений и адаптации своего протокола безопасности для смягчения возникающих угроз.
Кроме того, изменяющиеся законы о соблюдении требуют от предприятий соблюдения строгих требований по защите (аналогично тому, как диктует соблюдение GDPR).
Каждое предприятие уникально и нуждается в экспертном руководстве для разработки стратегии безопасности, обеспечивающей соответствие требованиям, предотвращение атак и защиту пользовательских данных.
Безопасность приложений необходима, потому что предприятия могут работать над развитием и улучшением бизнеса с гарантией того, что приложения защищены от потенциальной опасности.
Безопасность приложений повышает операционную эффективность, отвечает требованиям соответствия, снижает риски и повышает доверие между бизнесом и пользователями.
Нарушения общественной безопасности и нарушения нормативных требований серьезно подрывают репутацию предприятия и заставляют потенциальных пользователей опасаться доверять бизнес-услугам.
Внедрение эффективной безопасности приложений – стоящее вложение.
Безопасность мобильных приложений: 5 главных угроз безопасности для мобильных устройств
Резкий рост количества смартфонов на рабочем месте и в повседневных ситуациях сделал их главной целью для хакеров.
Ни одно вычислительное устройство не является на 100% безопасным, и субъекты угроз продолжают искать новые способы использования уязвимостей на мобильных устройствах.
По словам Николаса Фирна, в 2017 году число атак на мобильные приложения возросло на 63%, поэтому крайне важно быть в курсе самых серьезных угроз безопасности для мобильных устройств.
1. Незащищенный Wi-Fi
Неподтвержденные серверы и незащищенные сети Wi-Fi в кофейнях или книжных магазинах – это рай для хакеров, не говоря уже об одной из самых серьезных угроз безопасности для мобильных устройств.
По словам репортера CNBC Дженнифер Шлезингер, хакеры пытаются скомпрометировать предприятия с помощью мобильных уязвимостей из-за роста числа смартфонов на рабочем месте.
Несмотря на предупреждения пользователей смартфонов о потенциально опасных и непроверенных серверах, пользователи продолжат подключаться к опасным сетям.
Инициаторы угроз могут использовать эти незащищенные сети для доступа к конфиденциальным данным непосредственно с телефонов или приложений.
2. Приложения с вредоносным кодом
Пользователи смартфонов загрузили 197 миллиардов мобильных приложений в 2017 году.
Однако пользователи могут загружать приложения со сторонних веб-сайтов вне Google Play Store или Apple App Store.
Хакеры могут использовать незащищенные приложения для использования конфиденциальных данных от мобильных пользователей.
Например, вредоносное вредоносное мобильное приложение под названием «Gooligan» заразило 1,3 миллиона пользователей Android, и субъекты угроз смогли украсть пользовательские данные.
Хакеры могут создавать приложения-копии и размещать их в сторонних магазинах приложений, а затем, как и фишинговые схемы, использовать вредоносное программное обеспечение для кражи данных.
Вы можете предотвратить угрозы безопасности мобильных устройств, загружая приложения только из официальных магазинов приложений.
3. Уязвимости операционной системы
Производители смартфонов должны постоянно обновлять операционное программное обеспечение для обеспечения технологических улучшений, новых функций и повышения общей производительности системы.
Пользователю смартфона периодически рекомендуется обновлять операционные системы (например, пользователям iPhone в операционных системах iOS).
Разработчики программного обеспечения отслеживают возникающие уязвимости и настраивают операционные системы для устранения угроз.
Однако пользователи могут отказаться от обновления системы или, возможно, их устройство больше не совместимо с последним обновлением.
Наилучшей защитой от возникающих мобильных угроз является обновление операционной системы как можно скорее и обновление мобильного устройства, если операционная система больше не совместима с новыми обновлениями.
4. Утечки данных
Мобильные приложения обычно хранят данные на удаленных серверах.
Пользователи часто загружают приложения и сразу же заполняют подсказки, чтобы начать использовать приложение, но часто не проверяют это должным образом.
Рекламодатели могут добывать данные, чтобы узнать больше о целевой демографии, но киберпреступники могут также получить доступ к серверам и утечки конфиденциальных данных.
Непреднамеренные утечки данных могут быть вызваны кэшированием, небезопасным хранением и cookie-файлами браузера.
5. Проблемы криптографии
Мобильная криптография имеет решающее значение для безопасности и обеспечивает безопасную работу данных и приложений.
Программное обеспечение iOS должно проверить, что приложение имеет цифровую подпись из надежного источника, а затем расшифровать приложение, чтобы выполнить его.
Программное обеспечение Android просто проверяет, что приложение имеет цифровую подпись, и не обязательно проверяет надежность подписавшего.
Такой дизайн цифрового доверия повышает важность загрузки приложений из официального источника.
Чувствительные данные в состоянии покоя на мобильном устройстве обычно становятся жертвами непреднамеренного раскрытия из-за плохой или полной нехватки криптографических реализаций.
Разработчики, работающие в сжатые сроки или пытающиеся срезать углы, могут использовать алгоритмы шифрования с существующими уязвимостями или вообще не использовать какое-либо шифрование.
Субъекты угроз могут использовать эти уязвимости или грабить данные с взломанного мобильного устройства.
Что такое тестирование мобильных приложений?
Тестирование мобильных приложений снижает риски, тестирует потенциальные уязвимости и проверяет программное обеспечение, чтобы убедиться, что приложение безопасно и соответствует требованиям безопасности.
Эксперты по кибербезопасности используют различные тесты и стратегии для мониторинга уязвимостей, чтобы оценить безопасность мобильного приложения.
Тестирование безопасности мобильных приложений требует передовых знаний и ресурсов.
Эксперты по безопасности часто создают реалистичные кибератаки для выявления потенциальных рисков.
Они проверяют не только мобильное приложение, но и всю внутреннюю систему, поддерживающую инфраструктуру и API.
Тестирование проникновения мобильных приложений: найдите свои уязвимости
Тесты на проникновение являются важной процедурой безопасности для тестирования мобильных приложений.
Хотя сканирование уязвимостей направлено на тестирование известных уязвимостей, аналитики безопасности используют тесты на проникновение, чтобы найти любую потенциальную уязвимость, будь то плохие настройки безопасности, незашифрованные пароли или неизвестный недостаток.
Подражая привычкам субъектов угроз, аналитики могут предвидеть стратегии киберпреступников и создать протокол безопасности, который на шаг впереди плохих парней.
Профессионалы должны выполнять тесты на проникновение, по крайней мере, один или два раза в год, так как стратегии атак кибербезопасности постоянно развиваются.
Аналитики безопасности часто используют два типа тестов на проникновение: тесты black box и white box.
1. Тестирование white box (статическое тестирование безопасности приложений)
Тестирование white box, также известного как статическое тестирование безопасности приложений (SAST), направлено на тестирование безопасности мобильного приложения с точки зрения осведомленного злоумышленника.
Аналитики безопасности пытаются получить как можно больше информации о конкретном мобильном приложении и сети перед выполнением теста.
Специалисты по безопасности будут проводить атаки на основе их понимания.
2. Тестирование black box
Тестирование black box имитирует, как неосведомленный злоумышленник попытается использовать уязвимости.
Специалисты по безопасности внедряют различные угрозы для анализа уровня безопасности мобильного приложения.
Хотя они имитируют более реалистичную атаку, чем атака white box, специалисты по кибербезопасности могут не иметь возможности протестировать некоторые уязвимости из-за недостатка информации о конкретном приложении.
Консультанты Secureworks® объединяют аспекты этих методов при проведении мобильного тестирования.
Комбинируя подход информированного злоумышленника с методами тестирования черного ящика, консультанты могут эффективно тестировать компоненты мобильной среды за меньшее время, чем один только black box тест.