Чтобы провести аудит безопасности сайта, согласуйте объекты и допустимые действия, сохраните исходное состояние и проверьте восстановление. Затем проверьте предупреждения, доступы и формы, поручите специалисту анализ уязвимостей кода и сервера. Получите подтверждённые находки, план исправлений и повторный тест. При признаках взлома сразу подключите специалиста для ограничения ущерба.
Для производства последствия атак — недоступный каталог, чужой номер вместо отдела продаж или утечка чертежей клиентов из запросов КП. Проверка должна охватывать путь покупателя от карточки оборудования до получения обращения.
Рабочий принцип: результат аудита — подтверждённый риск, ответственный и проверяемое исправление. Автоматический отчёт без разбора не показывает, какие проблемы действительно угрожают вашему сайту.
1. Определите границы проверки и сохраните исходное состояние
Составьте список: основной сайт, поддомены, CMS (система управления содержимым), хостинг, домен, формы, CRM и внешние виджеты. Укажите владельца каждого доступа. Для каждого проекта запишите, какие данные проходят через сайт: например, контакты закупщика и приложенный к запросу расчёта чертёж.
До изменений попросите администратора сохранить файлы, базу данных и настройки. Проверять восстановление следует в изолированной среде без отправки реальных писем и заявок. Зафиксируйте дату копии, место хранения и исполнителя возврата. Копию храните отдельно от рабочего сайта с ограниченным доступом. Если есть признаки заражения, сохранённое состояние нужно для разбора инцидента; его нельзя считать чистой копией для восстановления.
Как проверить результат. Согласованы объекты, разрешённые действия, окно работ и способ остановить проверку при сбое. Активное сканирование выполняет специалист в этих границах. Копия помогает проверить исправления, но конфигурацию боевого сервера оценивают отдельно.
Типичная ошибка. Запустить сканер на работающем каталоге без согласования нагрузки.
Что сказать подрядчику. «Укажите объекты, ограничения и порядок возврата. Кто проверит восстановление?»
2. Проверьте предупреждения и внешний вид сайта
В Яндекс Вебмастере выберите сайт → «Оптимизация сайта» → «Безопасность и нарушения». Откройте описание нарушения, сохраните его с датой. Названия разделов сверьте в кабинете и справке Яндекс Вебмастера. Отсутствие списка означает, что сервис не показывает действующих ограничений Поиска, но не подтверждает отсутствие уязвимостей или вредоносного кода.
Самостоятельно откройте главную, каталог и карточку продукта с компьютера и телефона. Сверьте номер отдела продаж, кнопки запроса КП, документы и адрес после перехода. Не обходите предупреждение браузера ради заполнения формы.
Как проверить результат. Зафиксированы предупреждения, неожиданные перенаправления и подмена контактов, если они есть. При признаках взлома попросите специалиста сохранить журналы сервера и ограничить повреждённый участок; согласуйте с директологом остановку трафика на него.
Типичная ошибка. Удалить подозрительную страницу, не выяснив способ её появления.
Что сказать подрядчику. «Проверьте источник изменений и соседние разделы, сохраните доказательства до очистки».
3. Проверьте доступы, CMS и настройки сервера
В панели хостинга найдите пользователей и выданные доступы; в CMS — учётные записи и роли. Названия разделов зависят от продукта: сверьте их с официальной документацией панели. Сопоставьте администраторов с действующими сотрудниками и подрядчиками. Не отключайте неизвестную запись вслепую: установите её назначение.
Попросите специалиста перечислить версии CMS, модулей и серверного ПО, проверить поддержку и исправления безопасности. Обновления сначала проверяют на копии. Для выбранной CMS сверьте меры защиты с официальной документацией: разграничение прав, обновления, резервирование и журналирование.
Отдельно проверьте правила входа:
- У сотрудников отдельные учётные записи; пароли уникальны и не передаются в общем чате.
- Где доступно, включена двухфакторная аутентификация — подтверждение входа вторым фактором. Проверен способ восстановления доступа.
- Доступы бывших исполнителей отозваны после передачи работ. При компрометации специалист меняет пароли и ключи интеграций, завершает подозрительные сеансы и проверяет устройства администраторов.
Как проверить результат. У каждого доступа есть владелец; права соответствуют задачам. Для устаревших компонентов есть план обновления или замены. Администратор проверил HTTPS, срок сертификата, отсутствие общедоступных резервных архивов и конфигурационных файлов. HTTPS защищает передачу данных, но не устраняет ошибки кода.
Типичная ошибка. Считать защитный модуль заменой обновлений.
Что сказать подрядчику. «Кто управляет доменом, хостингом и CMS? Где доступна дополнительная проверка входа и кто получает уведомления?»
4. Проверьте формы и поручите анализ уязвимостей
Для самостоятельной проверки безопасности сайта отправьте согласованную тестовую заявку на расчёт с карточки продукта. Впишите пометку «тест» и согласованные тестовые данные, приложите безопасный тестовый документ, если предусмотрена загрузка. Проследите обращение до почты или CRM и предупредите менеджера. Проверьте кнопку звонка: она должна открывать правильный номер, но клик не доказывает состоявшийся разговор.
Как проверить сайт на уязвимости глубже? Передайте специалисту задание на анализ кода и настроек, проверку прав доступа, загрузки файлов и серверной обработки ввода. Руководство OWASP WSTG по тестированию веб-приложений помогает определить состав работ. Для вашего сайта согласуйте применимые сценарии:
- Проверка входа и авторизации: можно ли обойти вход или получить права другой роли.
- Анализ обработки ввода: SQL-инъекции позволяют вмешаться в запросы к базе, XSS — выполнить посторонний скрипт в браузере посетителя при наличии соответствующей уязвимости.
- Защита действий вошедшего пользователя от подделки запросов и проверка завершения сеанса после выхода.
- Контроль вложений: ограничения размера и типа файлов, запрет исполнения загруженного кода и доступа посторонних к чертежам.
Выявление вредоносного кода — отдельная часть задания: специалист исследует файлы, подозрительные изменения и журналы. Поиск вирусов не заменяет анализ уязвимостей, через которые возможно повторное заражение.
Как проверить результат. Заявка дошла нужному получателю с названием оборудования; специалист проверил, что посторонний пользователь не получает чужие обращения или закрытые файлы. Находки подтверждены безопасным тестом. Онлайн-сканер не выявляет всех ошибок бизнес-логики; его выводы требуют проверки.
Типичная ошибка. Испытывать подозрительные команды в форме на боевом сайте или загружать рабочие чертежи в сторонний сервис.
Что сказать подрядчику. «Какие сценарии проверены вручную? Подтвердите защиту на стороне сервера и перечислите ограничения проверки».
5. Превратите отчёт в план исправлений
Попросите отчёт с объектом проверки, датой, подтверждением, последствием для бизнеса, приоритетом, ответственным и способом повторного теста. Отдельно обозначьте предположения и непроверенные участки. Общий балл сканера не заменяет эти сведения. Отчёт с доказательствами храните в закрытом доступе; пароли, токены и данные клиентов в него не включайте.
| Находка | Что потребовать | Как принять |
|---|---|---|
| Чужой доступ к заявкам | Ограничить права, выяснить причину | Повторить проверку с тестовыми ролями |
| Уязвимый модуль | Проверить исправление на копии | Подтвердить обновление и работу формы |
| Нет проверенного восстановления | Восстановить файлы и базу | Открыть каталог и проверить обращение |
Как проверить результат. Подтверждённый доступ посторонних к данным и активное заражение получают первоочередную реакцию. Для остальных работ приоритет определяется доступностью уязвимости и ущербом, а не числом строк отчёта.
До заказа услуги согласуйте процесс работы: какие доступы нужны, включён ли анализ исходного кода, кто устраняет находки и входит ли повторный тест в стоимость. Если код или сервер недоступен исполнителю, это ограничение должно быть в отчёте.
Типичная ошибка. Закрывать мелкие замечания, оставляя действующий путь компрометации.
Что сказать подрядчику. «Разделите подтверждённые проблемы, рекомендации и непроверенные участки. Для каждой правки укажите риск и проверку».
6. Примите исправления и проверьте путь заявки
Повторите исходные проверки. Проверьте каталог, скачивание открытого паспорта оборудования, запрос КП, доставку формы и контакты на телефоне. Сверьте достижение цели Яндекс Метрики с реальным обращением. Цель «Отправка формы» может учитывать и безуспешную попытку: событие в отчёте не доказывает доставку. Порядок сверки разобран в статье о проверке целей в Яндекс Директе.
При ограничениях в Поиске Яндекса после устранения причины укажите изменения в блоке нарушения, отметьте «Нарушение исправлено» и нажмите «Отправить на проверку», затем подтвердите действие. Актуальные названия и доступность кнопок сверьте в кабинете и справке Яндекс Вебмастера. Итоговый статус проверяйте отдельно от технической приёмки.
Как проверить результат. Есть повторный тест, журнал изменений, работоспособная копия и инструкция возврата: какие файлы, базу и настройки восстановить. Возврат старой копии может потерять новые обращения и вернуть уязвимость — это нужно согласовать до внедрения.
Типичная ошибка. Принять работу по исчезнувшему предупреждению, не проверив форму.
Что сказать подрядчику. «Покажите повторный тест, ограничения и подтверждение доставки заявки после релиза».
Типовой сценарий. После обновления защитного модуля производитель перестал получать запросы с вложениями. Маркетолог отправляет тест с карточки станка, администратор находит блокировку обработчика и корректирует правило без отключения всей защиты. Повторный тест должен подтвердить и доставку, и сохранение ограничений загрузки файлов.
Независимый технический взгляд нужен при повторном заражении или споре о подтверждении уязвимости. Если сайт очищен, а обращения теряются, нужен разбор пути заявки. При утрате доступа и копий сначала согласуйте восстановление сайта и источники данных для него.
Итог
Повторяйте проверку после смены подрядчика, переноса сайта, существенных обновлений и инцидентов. Периодичность остальных проверок согласуйте с ответственным за поддержку с учётом изменений и рисков.
Получить аудит
Вопросы по теме
Можно ли самостоятельно проверить безопасность сайта?
Можно проверить предупреждения, контакты, доставку форм и владельцев доступов. Анализ кода, серверных настроек и проверки прав доступа поручите специалисту в согласованных границах.
Что входит в аудит безопасности сайта?
Объём согласуют заранее: доступы, CMS и модули, сервер, обработка данных, формы, интеграции и восстановление. Отчёт должен перечислять проверенные и непроверенные участки.
Достаточно ли онлайн-сканера для поиска уязвимостей?
Нет. Он даёт часть наблюдений и может ошибаться. Права пользователей и логику работы с обращениями проверяют отдельно; найденную проблему нужно подтвердить.
Что делать, если сайт уже взломан?
Подключите технического специалиста, сохраните журналы и исходное состояние, согласуйте ограничение повреждённых участков. После очистки нужно устранить причину проникновения и повторить проверки.
Аудит интернет-маркетинга включает тестирование на проникновение?
Такой состав нельзя предполагать. Аудит интернет-маркетинга разбирает сайт, рекламу, SEO, аналитику и обращения. Проверки безопасности и их глубину согласуйте отдельно с техническим исполнителем.
