Привет, Хабр! Меня зовут Юра Петров, я руководитель отдела разработки в компании Friflex и автор канала «Мобильный разработчик».
Эта статья — про аудит безопасности приложений, ту самую вещь, о которой часто задумываются уже после того, как что-то пошло не так. Если вы были на CrossConf, то помните, что это тема моего выступления и она довольно объемная. Поэтому статей будет несколько.
В этой части расскажу немного о типах аудитов, о ресурсах для самопроверки и о том, почему подготовка так важна. Если вы разработчик, который хочет сделать свое приложение лучше и безопаснее, то эта статья для вас.
Какие бывают аудиты
Их на самом деле три обширных. Это Black box, Grey box и White box.
Black box — вы ничего не предоставляете аудиторам. Они просто скачивают вашу APK или iOS-версию из магазина приложений, устанавливают ее и пытаются взломать. У них нет доступов к коду, документации или инфраструктуре.
✅ Не требует подготовки: вы просто даете аудиторам доступ к приложению, и они начинают работу.
✅ Помогает оценить безопасность приложения так, как это делают настоящие злоумышленники.
✅ Подходит, чтобы проанализировать, как уязвимости могут повлиять на репутацию компании и пользовательский опыт.
? Ограниченная глубина проверки, многие проблемы на стороне сервера или в коде остаются незамеченными.
? Выявленные уязвимости могут быть общими и не учитывать нюансы внутренней архитектуры.
? Результаты зависят от уровня профессионализма аудиторов, а не от ваших усилий по подготовке.
Gray box — все то же самое, но при этом вы еще даете какие-то тестовые данные, чтобы аудиторы могли зайти в приложение и, например, повлиять на бэкэнд или еще что-то. Это позволяет провести аудит клиентской и серверной сторон приложения.
✅ Позволяет выявить больше уязвимостей и, к примеру, проверить передачу данных между клиентом и бэкендом.
✅ Помогает понять, как слабые места в архитектуре приложения могут использоваться злоумышленниками.
✅ Баланс между трудозатратами и глубиной проверки.
? Требуется подготовка: нужно собирать тестовые данные и объяснять аудиторам, как работает приложение.
? Может упустить некоторые скрытые уязвимости — аудиторы все-таки видят не всю картину.
? Результат зависит от того, насколько хорошо вы передали ключевую информацию.
White box — вы полностью раскрываете аудиторам внутреннюю кухню приложения: исходный код, репозитории, архитектурные диаграммы и документацию. Они проводят глубокий анализ на всех уровнях системы.
✅ Максимальная глубина проверки.
✅ Полезно для улучшения качества кода и инфраструктуры.
✅ Помогает выстроить доверие с клиентами или партнерами, потому что подтверждает соответствие стандартам безопасности.
? Это долго: требуется собрать и передать много информации аудиторам.
? Риск утечки данных, если аудиторы недостаточно надежны или используют надежные каналы передачи данных.
? Может быть трудно внедрить, если документация или инфраструктура проекта не в порядке.
Три этапа аудита
Первый этап — все только начинается. Вы получаете сообщение, что скоро будет аудит. Это хорошее время, чтобы подготовиться. Что полезно сделать до начала:
Провести самопроверку. О ней расскажу отдельно ниже.
Создать тестовую среду. Настройте окружение, где аудиторы смогут работать без риска повредить продакшн. При подготовке тестовой среды очень важно учесть, что она должна полноценно повторять продакшн-окружение. В этой среде не должно быть каких-либо ограничений, которых нет у реального пользователя на проде — это может повлиять на результат аудита.
Подготовить и передать аудиторам необходимые данные (для Grey box и White box).
Убедиться, что у вас есть логи и метрики, чтобы отслеживать действия аудиторов и видеть, как приложение реагирует на их запросы.
Использовать чек-листы из OWASP или других ресурсов, чтобы оценить текущий уровень безопасности.
Подготовить команду к быстрому реагированию на обнаруженные уязвимости, чтобы минимизировать потенциальный ущерб.
Второй этап — это сам аудит. Он проходит достаточно тривиально:
Анализ клиентской части. Это может быть попытка реверс-инжиниринга приложения, анализ хранения данных, проверка шифрования.
Проверка API. Аудиторы тестируют эндпоинты, проверяют обработку данных, авторизацию и аутентификацию.
Искусственные атаки. Аудиторы используют различные техники взлома (SQL-инъекции, XSS, brute force и другие), чтобы найти уязвимости.
Оценка кода (в случае White Box). Аудиторы анализируют исходный код на предмет уязвимостей, ошибок авторизации или утечек данных.
И третий этап — вы получаете документ, где описаны все ваши проблемы. Вы, в принципе, их решаете и возвращаете к первому этапу, все опять отправляете аудитору. Чтобы внедрить изменения и избежать типичных ошибок:
Действуйте быстро. Критические уязвимости должны быть исправлены как можно быстрее, особенно если они могут быть использованы в продакшене.
Проведите повторное тестирование. После внесения изменений убедитесь, что исправления действительно работают, и не создали новых проблем.
Делитесь знаниями. Организуйте внутренний разбор аудита с командой, чтобы предотвратить повторение ошибок.
Обновите процессы. Если уязвимости связаны с неправильной организацией работы (например, отсутствием код-ревью или слабым тестированием), измените процесс разработки.
Что значит самопроверка?
Перед аудитом можно самостоятельно оценить состояние безопасности приложения, чтобы заранее найти и устранить очевидные уязвимости. Эффективный процесс самопроверки можно выстроить, даже если в команде нет специалиста по безопасности — нужен просто хороший чек-лист для проверки.
Изучите его пункты и отфильтруйте их по специфике вашего проекта. Многие пункты чек-листов для самопроверки требуют у разработчиков дополнительного времени для изучения, поэтому для качественной проверки важно тщательно подготовиться.
Есть очень классный сайт, называется Open Worldwide Application Security Project или OWASP - это международная некоммерческая организация, которая занимается вопросами безопасности веб-приложений. Один из основных принципов OWASP заключается в том, что все их материалы являются общедоступными, и их можно найти на их веб-сайте. Это дает возможность всем желающим повысить уровень безопасности своих веб-приложений. Материалы, которые они предлагают, включают документацию, инструменты, видео и форумы. Это один из наиболее авторитетных источников знаний по безопасности веб- и мобильных приложений.
Там есть три раздела, на которые вы можете обратить внимание.
MASVS (Mobile Application Security Verification Standard) — это правила, которые помогают делать мобильные приложения безопасными. Их используют архитекторы и разработчики, чтобы создавать надёжные приложения, а тестировщики — чтобы проверять их. По сути, это отраслевой стандарт безопасности приложения. Оно структурировано по уровням безопасности (1–3). Это позволяет выбрать подходящий набор требований в зависимости от вашего приложения.
MASWE (Mobile Application Security Weakness Enumeration) — список слабых мест в безопасности мобильных приложений. Можно использовать как чек-лист для выявления критических проблем.
MASTG (Mobile Application Security Testing Guide) — это прямо такой ультимативный гайд по тестированию мобильных приложений. Он описывает основные уязвимости и методы их выявления. Можно скачать в виде PDF и ознакомиться.
Рекомендую ознакомиться с данными материалами вне зависимости от того, будет ли у вас аудит или нет. Очень полезно для личного развития и понимания концепции безопасности OWASP.
Есть еще один классный сайт — компании Стингрей (она как раз занимается безопасностью в приложениях), и там есть крутой чек-лист. Его можно спокойно использовать без глубоких знаний безопасности, он структурированный и простой.
Наконец, есть еще ГОСТы. Про них почти никто не знает, но они есть. ГОСТ 27034 - Безопасность приложений.
Если вдруг захотите изучить, вот список:
ГОСТ Р ИСО/МЭК 27034-1-2014 - общее понятие;
ГОСТ Р ИСО/МЭК 27034-2-2021 - нормативная структура организации;
ГОСТ Р ИСО/МЭК 27034-3-2021 - процесс менеджмента безопасности приложений;
ГОСТ Р ИСО/МЭК 27033-4-2021 - Безопасность сетей;
ГОСТ Р ИСО/МЭК 27034-5-2020 - Структуры данных протоколов и мер обеспечения безопасности приложений;
ГОСТ Р ИСО/МЭК 27034-6-2021 - Практические примеры;
ГОСТ Р ИСО/МЭК 27034-7-2020 - Основы прогнозирования доверия;
На самом деле, там нет никаких прямых действующих руководств. Но есть общие правила и стандарты, которые можно использовать для систематизации процесса разработки. Например, определить минимальные требования к шифорванию. Рекомендую изучить данные ГОСТы, хотя бы поверхностно.