Перейти к основному содержанию
Блог

Процесс

Что такое экспертиза кибербезопасности и как к ней подготовиться

Что проверяют на официальной экспертизе кибербезопасности, как выглядит отчёт и как спокойно подготовить к ней продукт.

· 6 мин. чтения

Фото: Sniper Zeta, CC BY-SA 4.0 · Wikimedia Commons

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

В этой статье на основе собственного опыта объясняем, как устроена экспертиза, на что в ней обычно смотрят и как подготовить продукт к проверке.

Что проверяет экспертиза

Экспертиза — это независимая оценка текущего состояния продукта. Специалисты смотрят на систему глазами внешнего атакующего и фиксируют каждую найденную уязвимость в отчёте.

Для веб-приложений

На веб-сайтах и порталах обычно рассматривают:

  • Уязвимости уровня приложения — проблемы из категорий OWASP Top 10 (2021): ошибки контроля доступа, инъекции, небезопасные настройки.
  • Бизнес-логику — выполняются ли процессы в правильном порядке и с нужными проверками.
  • Раскрытие информации — лишние внутренние данные в ответах, сообщениях об ошибках или файлах, отправляемых в браузер.
  • Сервер и сеть — открытые в интернет порты, ненужные сервисы, доступ к панелям управления.
  • Транспортную безопасность — HTTPS, настройки TLS и заголовки безопасности.

Для мобильных приложений

В приложениях Android (APK) и iOS (IPA) проверка близка к направлениям OWASP MASVS и Mobile Top 10 (2024): защита бинарного файла (обнаружение root/jailbreak, защита от динамического анализа, проверка целостности), безопасное хранение данных на устройстве, корректная проверка сертификатов и сетевой трафик. Для переданных файлов также запрашивают контрольные суммы MD5, SHA1 и SHA256 — чтобы подтвердить, что проверялся именно ваш файл.

Как выглядит отчёт

Результат экспертизы — список найденных уязвимостей. Каждая находка обычно указывается с уровнем риска (высокий, средний, низкий), описанием и рекомендацией. Владелец продукта закрывает находки и подаёт продукт на повторную проверку.

На примере нашего собственного продукта — SaaS-платформы для налогов и финансов — веб-экспертиза вернула 6 находок: страница «успешной оплаты» показывалась до подтверждения от платёжного провайдера, host header injection, два случая раскрытия информации, действия без проверки состояния и открытые в интернет порты. Экспертиза мобильного приложения дала 9 находок по Android и iOS. Все были закрыты, но каждый круг занимал время.

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

Экспертиза — не экзамен, а независимое зеркало. Чем лучше вы к ней готовы, тем меньше кругов повторной подачи.

Подготовка: практический список

Следующие шаги полезны для любого веб- или мобильного продукта.

1. Проведите инвентаризацию

Чётко запишите, что входит в проверку: домены и поддомены, IP-адреса, API-эндпоинты, адреса админ-панелей, версии фреймворков и библиотек. Часто проблема находится на «забытом» тестовом поддомене или в старой версии API.

2. Закройте лишнее

  • Неиспользуемые порты и сервисы (FTP, порт базы данных, панель сервера) должны быть закрыты из интернета.
  • Панели управления должны открываться только с разрешённых IP-адресов.
  • Тестовые и отладочные страницы, phpinfo, старые резервные копии нужно удалить с сервера.

Быстро проверить сервер снаружи:

nmap -Pn -p- your-domain.uz

В результате должны остаться только нужные порты (обычно 80 и 443).

3. Проверьте режим production

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

4. Обновите зависимости

С помощью composer audit, npm audit и подобных инструментов найдите и обновите библиотеки с известными уязвимостями. Серверное ПО (nginx, PHP, база данных) тоже должно быть обновлено.

5. Настройте HTTPS и заголовки

HTTP-запросы перенаправляются на HTTPS, устаревшие версии TLS отключены, добавлены заголовки Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options и другие.

6. Вручную просмотрите бизнес-логику

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

7. Отдельно для мобильного приложения

Собирайте release-сборку с обфускацией, добавьте обнаружение root/jailbreak и certificate pinning, храните секреты в Keystore/Keychain, отключите cleartext-трафик. Заранее посчитайте контрольные суммы для APK и IPA:

sha256sum app-release.apk

8. Ответственный и документация

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

Итог

Экспертиза независимо проверяет уровень безопасности продукта, и это полезный процесс. Подготовиться к ней — значит заранее самим найти и закрыть дыры, которые могут быть обнаружены. Тогда проверка завершится за меньшее число кругов, и команда быстрее вернётся к основной работе.

Хотите узнать, насколько ваш продукт готов к экспертизе? Оставьте заявку на сканирование — Claude AI агент и наш специалист посмотрят основные уязвимости и подскажут, с чего начать.