Проверка сайта на безопасность онлайн бесплатно: вирусы, SSL и оценка A+–F
Представьте, что сайт, который вы годами наполняли и продвигали, однажды начинает открываться с чужим казино или перенаправлять мобильных посетителей на незнакомую страницу. Владелец при этом заходит в браузер с компьютера и видит привычную витрину. Именно поэтому взлом часто замечают поздно: вредоносный код рассчитан на то, чтобы не попадаться на глаза тому, кто проверяет сайт вручную. Компания PromoPilot™ выпустила бесплатный сканер, который помогает быстро увидеть такие признаки снаружи, и эта статья объясняет, что он реально проверяет, как читать оценку от A+ до F и где проходит граница между внешней проверкой и полноценным аудитом. Если вы хотите сразу попробовать, можно проверить сайт на безопасность без регистрации.
Статья адресована владельцам интернет-ресурсов, руководителям, маркетологам и тем специалистам, которые отвечают за работу сайта, но не обязаны разбираться в серверном администрировании. Вы узнаете, какие сигналы говорят о заражении, какие технические метрики стоит смотреть, как устроена шкала оценок, в каком порядке устранять найденные проблемы и какие ошибки совершают чаще всего. Практические примеры и критерии выбора инструмента помогут превратить разовую проверку в понятный регулярный процесс.
- Пояснения к каждой находке помогают понять, зачем она нужна и что изменится после исправления, даже если вы не специалист по безопасности
- Когда сайт уже взламывали, принимает платежи, хранит данные клиентов или приносит заметный доход, одной внешней проверки недостаточно
- Начинать стоит с быстрого внешнего среза: он покажет признаки вредоносного кода, попадание в чёрные списки, слабый TLS, отсутствующие заголовки, флаги cookie, устаревшие компоненты и пробелы в почтовых записях
- Это делает его полезным и безопасным инструментом, но не отменяет глубокого аудита там, где на кону деньги, данные и репутация
Что именно проверяет онлайн-сканер безопасности сайта
Внешний сканер работает так же, как браузер посетителя: запрашивает главную страницу и анализирует то, что сервер в неё отдал. Это принципиальное ограничение, но и главное преимущество, потому что проверка безопасна для сайта и не требует доступов. Инструмент получает HTML-код, список подключённых скриптов, заголовки ответа, параметры cookie и DNS-записи домена, после чего сопоставляет эти данные с известными признаками угроз. Результат зависит от того, что именно доступно снаружи, поэтому важно понимать границы метода заранее.
Вредоносный код на главной странице обычно проявляется в трёх формах. Первая — обфусцированный JavaScript, который кажется набором случайных символов и выполняет загрузку внешнего скрипта. Вторая — скрытые iframe нулевого размера, через которые посетителя перенаправляют на чужие ресурсы. Третья — скрипты с подозрительных доменов, например, похожих на популярные библиотеки, но с неожиданным адресом. Отдельно проверяются криптомайнеры, которые используют процессор посетителя, и признаки скиммера, перехватывающего данные полей банковской карты на странице оплаты.
Важно различать подозрительный и подтверждённо вредоносный код. Обфускация встречается и в легальных счётчиках, аналитических модулях и защитных скриптах, поэтому эвристический признак не равен диагнозу. Хороший отчёт помечает такие находки как требующие проверки и объясняет, почему они попали в список. Окончательное решение принимает владелец, сравнивая найденный фрагмент со своими скриптами и историей их установки. Если фрагмента в вашем коде быть не должно, это серьёзный повод для немедленных действий.
Проверка по чёрным спискам и репутационным базам — второй важный слой. Сканер сверяет домен с базой вредоносных URL, например URLhaus, и со списками доменов, связанных со спамом, таких как Spamhaus DBL. Попадание в такой список влияет не только на посетителей, которым браузер может показать предупреждение, но и на доставляемость писем с домена, а также на допуск в рекламные сети. Иногда сайт оказывается в списке из-за соседства с заражённым ресурсом на том же IP, поэтому стоит проверять и репутацию адреса сервера.
Проверка по спискам, однако, не равна полному аудиту. Домен может быть чистым в базах, но уже содержать свежую инъекцию, которую ещё никто не зафиксировал. И наоборот, домен может попасть в список по ошибке, и тогда владельцу придётся подавать запрос на пересмотр. Поэтому репутационная проверка лучше всего работает в связке с анализом кода: если одно говорит «чисто», а другое фиксирует аномалию, аномалия заслуживает внимания.
Существенная часть угроз вообще не видна извне. Веб-шеллы, бэкдоры и заражённые PHP-файлы, которые не выводят ничего на главную страницу, остаются за пределами пассивного сканирования. То же относится к слабым учётным записям администраторов, неправильным правам доступа на сервере и уязвимостям в конфигурации, которые проявляются только при активных проверках. Внешний сканер честно сообщает о своих пределах, и это его сильная сторона: отсутствие находок не означает отсутствие проблем, а лишь говорит о том, что публичная часть выглядит чистой.
Заголовки безопасности, SSL/TLS и cookies: как читать технические метрики
Технические метрики кажутся сухими, но именно они чаще всего дают быстрый выигрыш в защищённости. Сертификат, протоколы шифрования, HTTP-заголовки и параметры cookie настраиваются один раз, а затем работают постоянно. Ошибка здесь обходится дёшево в исправлении, но дорого в последствиях, потому что браузер посетителя начинает показывать предупреждения, а злоумышленник получает дополнительные возможности для атаки на сессии пользователей.
Сертификат SSL/TLS оценивается по нескольким параметрам. Первый — срок действия: просроченный сертификат приводит к ошибке в браузере, и посетитель обычно уходит без объяснений. Второй — цепочка доверия: сертификат должен быть выпущен доверенным центром, а промежуточные сертификаты должны быть подключены корректно. Третий — версии протоколов. Старые TLS 1.0 и 1.1 считаются небезопасными и отключаются, оставляя TLS 1.2 и выше. Четвёртый — набор шифров, который должен исключать слабые алгоритмы. Смешанный контент, когда страница по HTTPS подгружает ресурсы по HTTP, тоже относится к этой группе и часто ломает замочек в браузере.
HTTP-заголовки безопасности работают как инструкции браузеру, что разрешено делать с вашей страницей. HSTS указывает браузеру всегда обращаться к сайту только по HTTPS, что защищает от перехвата при первом подключении и от понижения протокола. Content-Security-Policy ограничивает источники скриптов, стилей и изображений, и это один из самых мощных барьеров против внедрённого кода, хотя его настройка требует аккуратности, чтобы не сломать легитимные скрипты. X-Frame-Options запрещает встраивать страницу во фреймы на чужих сайтах, защищая от кликджекинга. X-Content-Type-Options не даёт браузеру угадывать тип файла, а Referrer-Policy управляет тем, какие данные о переходе уходят на внешние ресурсы.
Не все заголовки одинаково критичны. HSTS и CSP дают наибольший эффект, потому что закрывают целые классы атак, а X-Frame-Options и X-Content-Type-Options решают более узкие задачи и во многих случаях уже частично закрыты другими механизмами. Заголовок, добавленный формально, без правильной настройки, может создать ложное ощущение защиты. Например, CSP с разрешением 'unsafe-inline' и широкими доменами почти не ограничивает внедрённый скрипт. Поэтому оценку заголовков нужно читать вместе с деталями, а не только по факту наличия.
Cookie заслуживают отдельного внимания, потому что через них злоумышленник получает доступ к сессии пользователя. Флаг Secure запрещает передавать cookie по незашифрованному соединению. Флаг HttpOnly скрывает cookie от JavaScript, что усложняет кражу сессии через внедрённый скрипт. Атрибут SameSite ограничивает отправку cookie при запросах с чужих сайтов и тем самым снижает риск CSRF-атак. Отсутствие этих флагов не делает сайт немедленно уязвимым, но увеличивает поверхность атаки, и исправляется такая настройка обычно в несколько строк конфигурации.
Хорошая практика — относиться к заголовкам и cookie как к страховке: она не предотвращает всё, но сильно сужает пространство для злоумышленника и делает многие атаки невыгодными.
Устаревшая CMS, плагины и библиотеки как источник риска
Система управления сайтом, её плагины и JavaScript-библиотеки чаще всего становятся входной точкой для атаки не из-за сложности, а из-за того, что их обновляют реже, чем стоило бы. Устаревший компонент с известной уязвимостью описан в открытых базах CVE, и для злоумышленников это готовая инструкция. Поэтому проверка версий входит в состав большинства онлайн-сканеров, а отчёт о ней помогает расставить приоритеты без лишних догадок.
Сканер определяет версию CMS и компонентов по признакам, которые видны в HTML и заголовках. Это могут быть мета-теги генератора, пути к файлам ресурсов с номером версии, комментарии в коде, характерные структуры каталогов и ответы сервера. Для WordPress типичны пути к плагинам и темам с указанием версии, для библиотек JavaScript — имя файла с номером релиза. Чем больше таких признаков открыто, тем точнее определение. Если разработчики скрыли версии или переименовали файлы, точность падает, и отчёт получает оговорку, что определение ориентировочное.
Срочность обновления определяется степенью риска конкретной уязвимости. Критичные уязвимости, которые позволяют выполнить код на сервере или получить административный доступ без авторизации, требуют немедленных действий, даже если сайт работает стабильно. Уязвимости среднего уровня, например, раскрывающие служебную информацию, можно закрыть в плановом порядке. Важно учитывать, используется ли уязвимый компонент на самом деле. Неактивный плагин, который лежит в каталоге, создаёт меньший риск, чем работающий, но его всё равно лучше удалить.
Ложные срабатывания встречаются регулярно, и их нужно уметь отличать. Версия может определиться неверно, если разработчик темы взял за основу библиотеку и подключил её под своим именем, или если в файле осталось старое упоминание версии. Проверить это можно простым способом: сравнить найденную версию с фактической в административной панели или в файлах на сервере. Если расхождение подтверждается, отчёт стоит поправить, а не паниковать. Если версия совпадает и уязвимость реальная, обновление становится первоочередной задачей.
Обновление само по себе не всегда безопасно: после него могут сломаться темы и плагины, несовместимые с новой версией. Поэтому разумная последовательность такая — сделать резервную копию, обновить тестовую копию сайта, проверить функции, затем применить изменения на боевом ресурсе. Для сайтов без разработчика этот процесс можно поручить хостинг-провайдеру или подрядчику, но важно, чтобы кто-то отвечал за регулярные обновления, а не действовал разово.
Как выбрать инструмент проверки и на что смотреть в отчёте
Выбор инструмента зависит от задачи. Если нужно быстро понять, нет ли очевидных проблем на публичной части сайта, достаточно бесплатного внешнего сканера. Если сайт принимает оплату, хранит персональные данные или уже подвергался взлому, понадобится глубокая проверка с доступом к серверу. Критерии выбора при этом одинаковы: глубина сканирования, частота обновления баз угроз, прозрачность методики и понятность отчёта.
Глубина сканирования показывает, что именно проверяется: только главная страница или несколько разделов, есть ли анализ JavaScript, заголовков, TLS и DNS. Частота обновления баз важна, потому что вредоносные домены живут недолго, и база, обновлённая месяц назад, пропустит свежую угрозу. Прозрачность методики означает, что сервис объясняет, по чего делает выводы, и не скрывает, что не проверяет. Понятность отчёта определяет, сможете ли вы действовать по результатам, или получите набор непонятных кодов.
Бесплатные и платные варианты отличаются обычно не качеством базовой проверки, а объёмом и глубиной. Бесплатный сканер даёт ответ о публичной части сайта и ограничен по числу запусков. Платные решения добавляют поиск открытых служебных файлов, активные проверки с подтверждением владения, мониторинг и рекомендации по исправлению. Выбирать стоит исходя из того, какой риск вы готовы закрывать самостоятельно, а какой передать специалисту.
Шкала оценок от A+ до F — удобный способ быстро понять состояние сайта, но её нужно читать правильно. Итоговый балл складывается из нескольких групп проверок: вредоносный код и репутация, TLS и сертификат, заголовки безопасности, cookie, устаревшие компоненты, почтовые записи. Высокий уровень означает, что найденные проблемы минимальны и публичная часть настроена грамотно. Низкий уровень говорит о наличии серьёзных пробелов, которые стоит закрыть в первую очередь. Однако высокий балл не гарантирует отсутствие инцидентов, потому что внешний сканер не видит серверную часть, и это принципиально. Для тех, кто хочет быстро оценить состояние своего ресурса, удобно проверить сайт на безопасность с помощью онлайн-сервиса, который не требует установки программ и доступа к панели управления.
Практичный подход — смотреть не только на букву, но и на перечень находок. Две страницы с одинаковой оценкой могут иметь совершенно разные проблемы: в одном случае — отсутствие нескольких заголовков, в другом — признак заражения. Поэтому фиксировать нужно каждую находку и её уровень риска, а не только итоговый балл. Оценка полезна для динамики: если она снижается от проверки к проверке, значит, после изменений появились новые проблемы.
Чтобы превратить отчёт в план, удобно пользоваться простым чек-листом приоритизации. Сначала идут признаки заражения и попадание в чёрные списки, потому что они влияют на посетителей и репутацию немедленно. Затем — устаревшие компоненты с известными критичными уязвимостями и просроченный сертификат. Далее — отсутствующие заголовки безопасности и флаги cookie. Последними обычно идут почтовые записи и информационные находки, например, раскрытие версии сервера. Такой порядок помогает не распыляться и закрывать самое опасное в первую очередь.
Пошаговый порядок проверки сайта и сроки выполнения
Проверка эффективнее, когда у неё есть понятный порядок. Первый шаг — подготовка. Соберите доступы к хостингу, панели управления сайтом и почте домена, даже если не планируете их использовать сразу: они понадобятся при исправлении. Создайте резервную копию файлов и базы данных в текущем состоянии, чтобы сохранить следы возможного взлома и иметь точку отката. Составьте список доменов и поддоменов, потому что поддомен с устаревшим сервисом часто оказывается слабым местом всей инфраструктуры.
Второй шаг — выполнение проверки. Запустите внешний сканер для основного домена, затем повторите её для ключевых поддоменов, например, почтового сервиса, личного кабинета или магазина. Зафиксируйте результаты: дату, оценку, список находок с уровнями риска. Сохранённый отчёт позволит сравнить состояние сайта после изменений и доказать, что проблема устранена. Если найдены признаки вредоносного кода, не удаляйте его сразу, а сохраните фрагмент для анализа и дальнейшего поиска источника.
Третий шаг — устранение и повторная проверка. Начните с критичных находок, затем переходите к остальным по чек-листу приоритетов. После каждого существенного изменения запускайте проверку заново, чтобы убедиться в результате. Учтите, что некоторые изменения, например, кэш на стороне сервера или CDN, могут задерживать обновление результатов, поэтому не спешите делать выводы сразу после правки.
По срокам всё зависит от масштаба. Первичная внешняя проверка занимает минуты, а её разбор — от получаса до нескольких часов, если находок немного. Устранение типовых проблем, таких как настройка заголовков, включение HTTPS-редиректа и выставление флагов cookie, обычно укладывается в день работы специалиста. Обновление CMS и плагинов с тестированием может занять от нескольких часов до нескольких дней в зависимости от количества компонентов и сложности тем. Расследование заражения и поиск бэкдоров в файлах требуют значительно больше времени и часто выходят за рамки внешней проверки.
Типичные ошибки при проверке безопасности и как их избежать
Самая частая ошибка — проверить сайт один раз и забыть о нём. Безопасность меняется: появляются новые уязвимости, истекают сертификаты, владельцы добавляют скрипты, которые потом не контролируют. Разовая проверка фиксирует состояние на конкретный момент, и через несколько месяцев картина может быть совершенно другой. Решение — регулярный мониторинг, хотя бы раз в месяц, и обязательная проверка после любых изменений на сайте.
Вторая распространённая ошибка — исправлять симптомы, не находя первопричину. Удалили вредоносный скрипт, но не закрыли уязвимый плагин, через который он попал, и через неделю заражение повторилось. Чтобы этого избежать, после очистки нужно искать источник: изменённые недавно файлы, незнакомых администраторов, устаревшие компоненты, подозрительные файлы в папках загрузок. Без этого очистка превращается в бесконечную борьбу с последствиями.
Третья ошибка — игнорировать поддомены, почту и сторонние скрипты. Атакующие часто идут не через главную страницу, а через забытый поддомен или подключённый внешний виджет, который может быть скомпрометирован на стороне поставщика. Почтовые записи SPF, DMARC и CAA влияют на то, смогут ли злоумышленники подделывать письма от вашего имени. Всё это входит в картину безопасности и должно проверяться вместе с сайтом.
Четвёртая ошибка — доверять только одному инструменту. Каждый сканер имеет собственную базу, собственную методику и собственные слепые зоны. Перекрёстная проверка двумя-тремя сервисами помогает увидеть то, что пропустил один из них, и снижает риск ложной уверенности. При этом важно сравнивать не только оценки, но и конкретные находки, потому что расхождения часто говорят о разных подходах, а не о том, что один сервис ошибается.
Какие задачи решает сайт для проверки безопасности
Сервис PromoPilot предлагает бесплатную онлайн-проверку, которая закрывает первый уровень вопросов: есть ли признаки вредоносного кода на главной странице, попадал ли домен в чёрные списки, как настроены HTTPS, TLS, заголовки безопасности и cookie, есть ли устаревшие версии CMS и библиотек, и заданы ли почтовые DNS-записи. Проверка пассивная, без атак и перебора путей, поэтому её безопасно запускать на любом публичном сайте. Результат выводится в виде оценки от A+ до F и списка находок, сгруппированных по уровню риска с пояснениями.
В отчёте вы увидите итоговую оценку, перечень найденных проблем и рекомендации по приоритету. Критичные и высокого риска находки стоит закрывать в первую очередь, остальные можно включить в плановые работы. Поэтому отчёт удобно передавать разработчику или хостинг-провайдеру как готовое техническое задание.
Бесплатная проверка имеет ограничения, о которых важно знать заранее. Она смотрит только главную страницу, не видит серверные файлы и закрытые разделы, не выполняет активных проверок и определяет версии по признакам, которые можно скрыть. Есть и лимиты на количество запусков в сутки. В таких случаях нужен углублённый аудит с доступом к серверу, который выполняет специалист и который включает поиск бэкдоров, анализ логов и проверку конфигурации.
Заключение
Проверка безопасности сайта — это не разовое действие и не лотерея с одной оценкой, а повторяемый процесс. Дальше находки распределяются по уровню риска, и критичные проблемы закрываются первыми, а не теми, которые проще исправить.
Минимальный набор, который стоит поддерживать постоянно, выглядит так: ежемесячная проверка публичной части сайта, немедленная проверка после любых изменений, контроль сроков сертификата, регулярное обновление CMS и плагинов с тестированием, и наличие ответственного человека, который получает уведомления и принимает решения. Если таких людей несколько, закрепите за каждым конкретную зону, чтобы задачи не терялись между отделами.
Помните, что внешний сканер видит ровно то, что видит посетитель. Используйте бесплатную проверку как первый сигнал, а не как окончательный приговор, и тогда отчёт станет тем, чем он и должен быть: понятным планом действий для защиты вашего сайта.