Проверка сайта на уязвимости: что можно проверить самому

Самостоятельная проверка сайта на уязвимости закрывает «базовую гигиену»: версии CMS и плагинов, заголовки безопасности, открытые служебные файлы, сертификат, права доступа и пароли. На это хватает одного часа и бесплатных инструментов. Глубокие проверки (подбор логики приложения, нагрузочные и инъекционные тесты) делает аудитор по договору, потому что без согласования такие проверки могут навредить сайту и нарушить закон.

Границы: что можно, а что нельзя

Проверять вы вправе свои сайты и системы, к которым у вас есть доступ. Активное сканирование чужого или арендованного ресурса (например, общего хостинга) без разрешения владельца может нарушить условия хостинга, а при ущербе и закон. Если сайт делал подрядчик и размещён на его сервере, согласуйте проверку заранее.

Чек-лист на час

Как делать по шагам

1. Составьте список: домены, поддомены, CMS, плагины, хостинг, кто имеет доступ.
2. Обновите всё, что имеет исправления безопасности. Перед этим сделайте резервную копию и проверьте её восстановление.
3. Удалите то, чем не пользуетесь: старые плагины, тестовые поддомены, забытые копии сайта. Нет компонента — нет уязвимости.
4. Проверьте заголовки безопасности и сертификат бесплатными сервисами.
5. Убедитесь, что служебные файлы и папки не отдаются по прямой ссылке.
6. Включите двухфакторную аутентификацию для админки и хостинга.
7. Запишите результаты и дату. Повторяйте раз в квартал и после каждого крупного обновления.

Бесплатные сканеры: чему можно доверять

Автоматические сканеры вроде OWASP ZAP в пассивном режиме или Mozilla Observatory показывают очевидные недочёты: отсутствие заголовков, устаревшие библиотеки, ошибки cookie. Относитесь к отчёту как к списку вопросов, а не приговору. Сканер выдаёт и ложные срабатывания, и пропускает логические ошибки: например, возможность увидеть чужой заказ, изменив номер в адресе.

Запускайте активный режим сканера только на тестовой копии сайта. Рабочий сайт может отреагировать как на атаку: блокировкой, нагрузкой или заполнением базы тестовыми записями.

Когда нужен аудит или пентест

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

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

Если уязвимость нашёл посторонний

Как читать результаты и что исправлять первым

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

Зафиксируйте, что исправили, и повторно проверьте. Нередко после обновления одна проблема уходит, а другая появляется: например, меняются права на файлы или сбрасывается конфигурация.

Исследователи иногда сообщают о проблемах сайта сами. Чтобы такие письма не терялись, опубликуйте контакт по стандарту: security.txt. Отвечайте спокойно и без угроз: чаще всего это бесплатная подсказка.