Многие руководители ожидают от корпоративного сайта лишь того, чтобы он «открывался, отображался и позволял оставить телефон». После приёмки в день запуска никто годами не заходит в административную панель.
И только когда клиент звонит и говорит: «При переходе на ваш сайт открывается страница с азартными играми», или приходит письмо о том, что база данных продаётся в даркнете, — выясняется, что проблема существует уже давно.
Тестирование безопасности сайта — это не роскошь для крупных корпораций. Если на вашем сайте есть административная панель, формы и данные клиентов, он заслуживает регулярной проверки.
Для начала разберёмся: что именно тестируется
Многие думают, что тестирование безопасности — это «просканировать уязвимости»: установить сканер, прогнать его и получить отчёт. Это лишь половина дела.
Полноценное тестирование безопасности должно охватывать как минимум три уровня:
Первый уровень — конфигурация и поверхность атаки. Находится ли страница входа в админку по стандартному пути вроде /admin, не забыли ли закрыть тестовую среду, которая напрямую доступна из интернета, открыт ли порт базы данных наружу, лежат ли файлы резервных копий в корневой директории сайта, откуда их можно напрямую скачать. Эти проблемы не требуют глубоких технических знаний, но вероятность инцидента здесь наивысшая.
Второй уровень — распространённые веб-уязвимости. SQL-инъекции, несанкционированный доступ, загрузка файлов, XSS, слабые пароли. Особенно это касается административных панелей: может ли обычная учётная запись, изменив параметр URL, увидеть чужие заказы — об этом многие компании при разработке сайта вообще не задумывались.
Третий уровень — бизнес-логика. Например, можно ли в мини-программе записи обойти ограничения фронтенда и отправить форму повторно; можно ли накрутить скриптом интерфейс купонов; работает ли капча или она существует лишь формально. Такие проблемы сканер не обнаружит — только ручное тестирование.
Только пройдя все три уровня, вы поймёте, где находитесь.
Почему нужно «регулярно», а не «один раз»
Тестирование безопасности — это не прививка, после которой иммунитет на всю жизнь. Это скорее медосмотр: то, что нормально в этом году, не обязательно будет нормально в следующем.
Причины вполне конкретны:
Система меняется. Ваш корпоративный сайт мог в этом квартале получить онлайн-чат, в следующем — подключить оплату, а к концу года — сменить версию CMS. Каждое изменение кода может привнести новую брешь. В прошлый раз проблем не было, потому что той функции ещё не существовало.
Компоненты меняются. Производители фреймворков, плагинов и сторонних SDK, используемых сайтом, постоянно раскрывают новые уязвимости. Вы ничего не трогали, но то, от чего вы зависите, изменилось.
Способы атак меняются. Автоматизированные инструменты ежедневно сканируют IP-адреса по всему интернету в поисках сайтов, которые не обновлялись полгода. Атакующий не выбирает вас — он выбирает тех, к кому легко проникнуть.
Разумный ритм: ключевые бизнес-системы — раз в полгода, обычные корпоративные сайты — минимум раз в год, плюс дополнительная проверка после каждого крупного редизайна или запуска новых функций. Если есть оплата, регистрация пользователей, административная панель — ориентируйтесь на полгода.
Конкретный случай: что упустили после редизайна сайта
Приведём типичный пример.
Компания делала редизайн корпоративного сайта: обновила визуал, добавила фильтр продукции, добавила форму «Онлайн-сообщение» и заодно перенесла админку со старой системы на новую CMS. Цикл разработки — месяц, при приёмке смотрели отображение страниц и работоспособность отправки форм — всё в порядке, подписали.
Через три месяца обнаружились проблемы: в новой админке не было ограничения на количество неудачных попыток входа и не было капчи. То есть пароль можно было бесконечно подбирать скриптом. Кроме того, у интерфейса формы сообщений не было ограничения частоты запросов — его завалили десятками тысяч спам-записей, и база данных стала отвечать медленнее.
Обе проблемы базовое тестирование безопасности выявило бы за десять минут. Но в процессе редизайна за это никто не отвечал.
Вот почему тестирование безопасности нужно включать в процесс запуска, а не ждать инцидента. В чек-листе приёмки разработки сайта должен быть пункт «Тестирование безопасности пройдено».
Тестировать самим или нанимать — как решить
Не всё нужно отдавать на аутсорс. Некоторые базовые действия команда может выполнить сама:
- Обязательные сложные пароли в админке, включение двухфакторной аутентификации
- Отключение неиспользуемых тестовых сред, демонстрационных страниц, учётных записей по умолчанию
- Проверка доступности файлов резервных копий и директорий логов из интернета
- Регулярная проверка сторонних компонентов на известные уязвимости
Это операционная дисциплина — низкие затраты, высокая отдача, нет причин этого не делать.
Но части, связанные с несанкционированным доступом, инъекциями, обходом логики, обратным тестированием, где нужно выстраивать пути атаки, обычно требуют специалистов. Причина не в том, что свои не справятся, а в том, что разработчики и тестировщики слишком хорошо знают свою систему и склонны идти «нормальным путём», не представляя, где атакующий свернёт.
В каких случаях стоит обратиться в MIC Studio
Если ваша ситуация соответствует следующим пунктам, можно рассмотреть наше участие:
Во-первых, сайт или мини-программа только что запущены или завершён крупный редизайн — нужен независимый взгляд, чтобы убедиться в отсутствии очевидных брешей.
Во-вторых, административная панель предполагает несколько ролей — например, дилеры, сотрудники, администраторы с разными уровнями, и есть опасения по поводу несанкционированного доступа.
В-третьих, сайт уже подвергался взлому, заваливался спамом или вы получали письма с требованиями выкупа — нужно сначала локализовать проблему, а потом говорить об усилении защиты.
В-четвёртых, есть App или скриптовые сервисы — нужно провести обратное тестирование на уровне интерфейсов, чтобы проверить надёжность передачи данных и аутентификации.
MIC Studio при разработке корпоративных сайтов, мини-программ и App включает тестирование безопасности как часть этапа сдачи; мы также принимаем отдельные заказы на тестирование безопасности сайтов. По результатам выдаётся выполнимый список исправлений, а не непонятный отчёт сканера.
Три рекомендации, которые можно выполнить прямо сейчас
Первое: включите «тестирование безопасности» в чек-лист приёмки следующего редизайна. Не ждите следующего года — сделайте при следующем изменении кода, это минимальные затраты.
Второе: сегодня же проверьте три вещи: можно ли угадать адрес входа в админку, закрыта ли тестовая среда, нет ли подозрительных файлов в корневой директории сайта. Полчаса хватит.
Третье: назначьте фиксированную дату повторного тестирования для ключевых систем. Запишите в календарь — раз в полгода, и выполняйте в срок, не полагаясь на память.
В вопросах безопасности, пока ничего не случилось, это выглядит как пустая трата денег, но когда случается — понимаешь, что это была самая дешёвая инвестиция.