Alex.Morozov
New member
Когда ко мне приходят небольшие компании с вопросом «а всё ли у нас в порядке с безопасностью сайта», почти всегда звучит одно и то же: денег на полноценный пентест нет, времени тоже, а тревога есть. Я долго сопротивлялся идее быстрого аудита, но за последние пару лет отработал схему, которая реально укладывается в один рабочий день. Скажу сразу: это не полноценное тестирование на проникновение, но процентов восемьдесят типовых дыр на коммерческом сайте такой прогон находит. И для бизнеса это как раз тот формат, который можно повторить через квартал своими силами.
Начинаю всегда с подготовки, иначе день уйдёт в пустоту. Нужен полный инвентарь: сколько доменов, какие поддомены, где хостинг, кто владелец аккаунтов, какие CMS и плагины стоят. Обязательно прошу доступы к админке, панели хостинга и репозиторию, а также список людей, у которых есть права. Уже на этом этапе всплывают сюрпризы: забытые тестовые поддомены, стенды без пароля, аккаунты сотрудников, которые уволились полгода назад. Половина находок, кстати, делается именно здесь, а не в технической части.
Дальше первая половина дня — внешний периметр, всё, что видно без авторизации. Смотрю сертификат и редиректы, чтобы весь трафик шёл по шифрованному соединению, проверяю заголовки безопасности, отсутствие вывода версий движка и ошибок наружу. Прохожусь по открытым портам, ищу доступные панели администрирования, базы данных, файлы резервных копий, конфиги и логи, которые кто-то забыл закрыть. Отдельно смотрю служебные файлы вроде карты сайта и правил для поисковиков: иногда они сами подсказывают, где лежат админка, раздел с загрузками и внутренние документы.
После обеда занимаюсь движком и расширениями. Обновления ядра, плагинов и тем, удаление всего, что не используется, проверка прав и ролей пользователей. Дефолтные логины вида «admin», пароли из восьми символов, отсутствие двухфакторной аутентификации у администраторов — это классика, которую находят в семи случаях из десяти. Отдельным пунктом идёт резервное копирование: где лежат копии, доступны ли они извне, пробовали ли вы реально восстановить сайт из бэкапа. Если восстановление не проверяли ни разу, считайте, что его нет.
Потом код и формы — то, куда обычно лезет автоматика. Проверяю обработку пользовательского ввода в формах обратной связи, поиске, регистрации и корзине, смотрю права на файлы и папки, чтобы скрипты не могли быть изменены или выполнены там, где не надо. Ищу файлы с настройками и паролями в открытом доступе, смотрю, не отдаётся ли листинг директорий, нет ли отладочного режима, который показывает всю внутреннюю кухню. Здесь же проверяю политику доступа к панели управления: ограничение по адресам, капча после неудачных попыток входа, журналирование действий администраторов.
Финальный блок — инфраструктура и процессы. Кто и как получает доступ, отзываются ли права при уходе сотрудника, есть ли мониторинг доступности и оповещения о подозрительной активности, подключён ли базовый фильтр веб-запросов. Проверяю, куда пишутся логи и сколько они хранятся. Очень рекомендую в конце дня честно ответить на простой вопрос: если сайт прямо сейчас упадёт или будет зашифрован, за сколько часов вы поднимете его из копии и кто это будет делать в субботу вечером. Ответ на этот вопрос часто отрезвляет сильнее любой технической находки.
Результат дня я всегда оформляю в короткий отчёт с тремя уровнями: критично — чинить немедленно, важно — закрыть в течение недели, стоит улучшить — по возможности. Никаких простыней на сорок страниц, бизнес их не читает. Пишу человеческим языком: что нашли, чем это грозит и что конкретно сделать. И сразу договариваюсь о дате повторной проверки, потому что половина уязвимостей закрывается в первый день, а вторая половина тихо возвращается при следующем обновлении сайта.
Мой главный вывод: регулярный однодневный аудит своими силами полезнее, чем один дорогой пентест раз в три года. Он не заменит профессионалов, но снимает самые очевидные риски и, что важнее, вырабатывает привычку смотреть на свой сайт глазами злоумышленника. А теперь вопрос к вам, коллеги: есть ли в вашем рабочем чек-листе пункт, который неожиданно для вас ловил реальные проблемы чаще всего? Расскажите, что это было, — уверен, каждый из нас вынесет из этого что-то полезное.
Начинаю всегда с подготовки, иначе день уйдёт в пустоту. Нужен полный инвентарь: сколько доменов, какие поддомены, где хостинг, кто владелец аккаунтов, какие CMS и плагины стоят. Обязательно прошу доступы к админке, панели хостинга и репозиторию, а также список людей, у которых есть права. Уже на этом этапе всплывают сюрпризы: забытые тестовые поддомены, стенды без пароля, аккаунты сотрудников, которые уволились полгода назад. Половина находок, кстати, делается именно здесь, а не в технической части.
Дальше первая половина дня — внешний периметр, всё, что видно без авторизации. Смотрю сертификат и редиректы, чтобы весь трафик шёл по шифрованному соединению, проверяю заголовки безопасности, отсутствие вывода версий движка и ошибок наружу. Прохожусь по открытым портам, ищу доступные панели администрирования, базы данных, файлы резервных копий, конфиги и логи, которые кто-то забыл закрыть. Отдельно смотрю служебные файлы вроде карты сайта и правил для поисковиков: иногда они сами подсказывают, где лежат админка, раздел с загрузками и внутренние документы.
После обеда занимаюсь движком и расширениями. Обновления ядра, плагинов и тем, удаление всего, что не используется, проверка прав и ролей пользователей. Дефолтные логины вида «admin», пароли из восьми символов, отсутствие двухфакторной аутентификации у администраторов — это классика, которую находят в семи случаях из десяти. Отдельным пунктом идёт резервное копирование: где лежат копии, доступны ли они извне, пробовали ли вы реально восстановить сайт из бэкапа. Если восстановление не проверяли ни разу, считайте, что его нет.
Потом код и формы — то, куда обычно лезет автоматика. Проверяю обработку пользовательского ввода в формах обратной связи, поиске, регистрации и корзине, смотрю права на файлы и папки, чтобы скрипты не могли быть изменены или выполнены там, где не надо. Ищу файлы с настройками и паролями в открытом доступе, смотрю, не отдаётся ли листинг директорий, нет ли отладочного режима, который показывает всю внутреннюю кухню. Здесь же проверяю политику доступа к панели управления: ограничение по адресам, капча после неудачных попыток входа, журналирование действий администраторов.
Финальный блок — инфраструктура и процессы. Кто и как получает доступ, отзываются ли права при уходе сотрудника, есть ли мониторинг доступности и оповещения о подозрительной активности, подключён ли базовый фильтр веб-запросов. Проверяю, куда пишутся логи и сколько они хранятся. Очень рекомендую в конце дня честно ответить на простой вопрос: если сайт прямо сейчас упадёт или будет зашифрован, за сколько часов вы поднимете его из копии и кто это будет делать в субботу вечером. Ответ на этот вопрос часто отрезвляет сильнее любой технической находки.
Результат дня я всегда оформляю в короткий отчёт с тремя уровнями: критично — чинить немедленно, важно — закрыть в течение недели, стоит улучшить — по возможности. Никаких простыней на сорок страниц, бизнес их не читает. Пишу человеческим языком: что нашли, чем это грозит и что конкретно сделать. И сразу договариваюсь о дате повторной проверки, потому что половина уязвимостей закрывается в первый день, а вторая половина тихо возвращается при следующем обновлении сайта.
Мой главный вывод: регулярный однодневный аудит своими силами полезнее, чем один дорогой пентест раз в три года. Он не заменит профессионалов, но снимает самые очевидные риски и, что важнее, вырабатывает привычку смотреть на свой сайт глазами злоумышленника. А теперь вопрос к вам, коллеги: есть ли в вашем рабочем чек-листе пункт, который неожиданно для вас ловил реальные проблемы чаще всего? Расскажите, что это было, — уверен, каждый из нас вынесет из этого что-то полезное.