Проверка сайта на безопасность онлайн бесплатно: вирусы, SSL и заголовки
Что проверяет онлайн-сканер безопасности сайта и где его границы
Владелец сайта обычно приходит к вопросу безопасности не из теории, а от конкретного симптома: в выдаче появилась пометка о возможном взломе, посетители жалуются на странные редиректы или хостинг прислал письмо о вредоносных файлах. В такой ситуации первым делом хочется узнать, видно ли заражение снаружи. Именно эту задачу решает проверка сайта на вирусы, которую можно запустить без регистрации и без доступа к серверу. Важно сразу понимать, что такой сканер смотрит на сайт глазами посетителя и поискового робота, а не глазами администратора.
Снаружи видно то, что сервер отдаёт в ответе на обычный запрос главной страницы. Сюда относится вредоносный код, вставленный прямо в HTML, скрипты, подгружаемые с посторонних доменов, скрытые iframe, майнеры криптовалют и скиммеры, которые перехватывают данные карт на форме оплаты. Также видны признаки подмены контента: например, когда страница для поискового бота содержит спам-ссылки, а человек видит нормальный сайт. Всё это проверяется без атак и без подбора путей, поэтому сканирование безопасно для самого сайта.
- Затем переходят к заголовкам, cookie и почтовым записям
- Удаление легитимного счётчика, который сканер ошибочно отметил, может сломать аналитику, а игнорирование настоящего скиммера ведёт к утечке данных посетителей
- Буква сама по себе ничего не объясняет, и без разбора конкретных находок владелец не знает, что именно исправлять
- Вторая — смена паролей без очистки уже внедрённого кода
Теперь о границах, которые важнее любых достоинств. Сканер принципиально не увидит серверные бэкдоры и веб-шеллы, если они лежат в файлах и ничего не выводят на главную страницу. Не увидит он уязвимости плагинов, которые проявляются только при определённых действиях пользователя, и закрытые разделы вроде админки. Поэтому результат «чисто» означает именно то, что на главной странице и в публичных базах признаков заражения нет, а не то, что сайт гарантированно не взломан. Путать эти два утверждения опасно: именно на этой путанице многие владельцы успокаиваются раньше времени.
Как устроена оценка A+–F
Итоговая буква складывается из нескольких блоков, и каждый из них отвечает за свой класс проблем. Блок вредоносного кода и репутации домена имеет наибольший вес, поскольку активное заражение — это самый острый риск для посетителей и для позиций в поиске. Затем идут шифрование и заголовки безопасности, потом cookies, версии CMS и библиотек, и наконец почтовые и DNS-записи. Такая структура объясняет, почему сайт с идеально настроенным TLS может получить низкую оценку из-за одного найденного скрипта со следами обфускации.
Низкий балл при отсутствии реального взлома — явление частое, и его стоит разбирать спокойно. Причиной обычно становятся отсутствующие заголовки безопасности, cookie без флагов Secure и HttpOnly, устаревшая версия библиотеки или отсутствие записи DMARC. Эти находки не означают, что сайт заражён, но они снижают общий балл, потому что повышают вероятность заражения в будущем. Разумно читать букву не как приговор, а как карту: какие блоки просели и насколько они критичны именно для вашего проекта.
Промежуточные оценки от B до D требуют особого внимания, потому что именно здесь чаще всего скрываются незакрытые проблемы, которые ещё не превратились в инцидент. Критичным стоит считать любой признак активного вредоносного кода, попадание домена в чёрный список и устаревшую CMS с известными уязвимостями. Всё остальное можно ранжировать по времени: сначала закрываем то, что открыто для атаки прямо сейчас, а затем наращиваем защиту по слоям.
Проверка сайта на вирусы и вредоносный код: что именно сканируется
Анализ начинается с HTML-кода главной страницы. Сканер ищет обфусцированный JavaScript, то есть код, намеренно запутанный так, чтобы его было трудно прочитать. Легитимные сайты используют обфускацию редко, поэтому её присутствие само по себе повод для проверки. Дополнительно разбираются подгружаемые скрипты и домены, с которых они берутся: если скрипт тянется с недавно зарегистрированного домена или с адреса, похожего на известный сервис, это тревожный сигнал.
Отдельно проверяется наличие скрытых iframe, которые часто используются для фишинговых редиректов и для загрузки чужого контента, невидимого владельцу. Признаки майнера выглядят как скрипт, который использует ресурсы процессора посетителя для расчёта криптовалюты, и обычно маскируется под счётчик или виджет. Скиммер карт распознаётся по перехвату полей формы оплаты и отправке введённых данных на внешний адрес. Каждый из этих признаков по отдельности может оказаться ложным срабатыванием, поэтому оценка всегда строится на совокупности.
Ложные срабатывания встречаются, и их важно уметь отличать от реальной угрозы. Например, рекламный сервис, аналитика или виджет чата легитимно подгружают сторонний код, который может выглядеть подозрительно при поверхностном взгляде. Практический критерий простой: если вы знаете, какой сервис подключали и зачем, и домен совпадает с официальным, то это, скорее всего, ваш собственный скрипт. Если же появился незнакомый домен, которого вы не добавляли, и тем более если скрипт запускается только при определённых условиях, относитесь к находке серьёзно.
Проверка по чёрным спискам и репутации домена
Вторая группа проверок опирается не на анализ кода, а на репутацию домена и адресов. Сканер сверяет сайт с базами, которые ведут антивирусные вендоры, поисковые системы и почтовые сервисы. Попадание в такой список означает, что браузеры или почтовики уже предупреждают пользователей, и это напрямую бьёт по трафику и доверию. Важно, что список формируется по данным о вредоносной активности, а не по субъективному мнению.
Домен может оказаться в списке даже при чистом коде. Типичные причины: старый взломанный поддомен, на который всё ещё ссылаются, общий IP-адрес хостинга, с которого рассылали спам, либо скрипт, который был удалён, но оставил след в кэше баз. Поэтому после устранения проблемы нужно не только очистить сайт, но и подать запрос на пересмотр в соответствующий сервис. Пересмотр занимает время, и ждать его придётся без гарантии мгновенного результата.
Сроки обновления баз влияют на результат напрямую. Если база обновляется нечасто, свежий вредонос может не попасть в список до момента проверки, и сайт получит чистый отчёт, который окажется ложным успокоением. Поэтому чистая проверка сегодня не исключает заражения вчера. Для критичных проектов разумно повторять сканирование регулярно, а не разово.
Чистый отчёт фиксирует состояние сайта в момент проверки на момент проверки, а не гарантию безопасности на всё время его работы.
Признаки компрометации по поведению сайта
Некоторые заражения не видны в HTML при прямом заходе, потому что вредоносный код срабатывает избирательно. Он может перенаправлять посетителей только тогда, когда переход пришёл из поиска, или показывать подменённую страницу только мобильным устройствам. Такой приём называется клоакингом, и именно он делает заражение невидимым для владельца, который открывает сайт с компьютера и видит всё в порядке.
Последствия для поисковых позиций могут быть серьёзными. Поисковый робот, получивший спам-контент, индексирует его, и в выдаче появляются чужие страницы под вашим доменом. Это снижает доверие поисковика и может привести к понижению сайта или пометке о взломе. Устранять такие последствия сложнее, чем сам взлом, потому что нужно не только очистить сайт, но и дождаться переиндексации и убедиться, что спам больше не отдаётся роботу.
Если симптомы есть, а внешний отчёт чистый, стоит проверять отчёт Search Console и сравнивать, что видит обычный посетитель и что видит робот. Расхождения между этими двумя версиями и есть главный признак клоакинга, даже если на главной странице явного кода не видно.
Технические заголовки и шифрование: SSL, HSTS, CSP и другие
Конфигурация SSL и TLS проверяется по нескольким параметрам: актуальность сертификата, полная цепочка доверия, поддерживаемые протоколы и набор шифров. Сертификат с истекающим сроком или неполной цепочкой вызывает предупреждения в браузере, а это прямой удар по доверию. Устаревшие версии TLS 1.0 и 1.1 уже не считаются безопасными и подлежат отключению, а смешанный контент, когда защищённая страница загружает ресурсы по незащищённому HTTP, ломает замок в адресной строке.
Заголовки безопасности работают как дополнительный слой защиты, который браузер применяет по инструкции сервера. Content-Security-Policy ограничивает, с каких источников разрешено загружать скрипты и стили, и во многом защищает от внедрённого кода. Strict-Transport-Security заставляет браузер всегда открывать сайт по HTTPS. X-Frame-Options запрещает встраивать страницу в чужие iframe, что закрывает часть атак через подмену интерфейса. X-Content-Type-Options не даёт браузеру угадывать тип файла, а Referrer-Policy управляет тем, сколько информации о переходе уходит на внешние сайты.
Неверная настройка заголовков способна сломать работу сайта. Слишком строгая политика CSP может заблокировать нужные скрипты, а HSTS с большим сроком действия без подготовки закрепит проблемы с HTTPS на месяцы. Поэтому внедрять заголовки стоит поэтапно, проверяя каждое изменение на тестовой копии, а не на боевом сайте.
Cookies и сессии
Флаги cookies определяют, как браузер обращается с данными сессии. Флаг Secure разрешает передавать cookie только по HTTPS, HttpOnly запрещает читать её из JavaScript, что защищает от кражи через внедрённый скрипт, а SameSite ограничивает отправку cookie при переходах с других сайтов и помогает против части атак с подделкой запросов. Отсутствие этих флагов — одна из самых частых находок в отчётах, и исправляется она обычно несколькими строками в настройках сервера или фреймворка.
Вручную проверить флаги можно в инструментах разработчика браузера, открыв вкладку с cookie для домена. Там видно, какие флаги выставлены для каждой записи. Важно проверять не только основные cookie сессии, но и сторонние, так как они тоже могут передавать данные и требуют учёта в политике конфиденциальности. Поэтому для более полной картины стоит дополнить разовую проверку регулярным мониторингом и сверкой с журналами сервера, а сам сервис проверка сайта на вирусы рассматривать как один из инструментов, а не как единственный способ убедиться в безопасности ресурса.
Cookie сторонних трекеров относятся уже не только к безопасности, но и к законодательству о персональных данных. В разных юрисдикциях требуется уведомлять посетителей о таких cookie и получать согласие до их установки. Поэтому технический отчёт о флагах полезен, но не закрывает правовой вопрос: его нужно рассматривать вместе с настройками баннера согласия.
Устаревшая CMS, плагины и версии ПО
Сканер определяет версию CMS и компонентов по косвенным признакам: заголовкам ответа, метатегам генератора, путям к файлам стилей и скриптов, структуре ссылок на ресурсы. Например, путь к файлам темы или плагина часто содержит название и иногда номер версии, а метатег с генератором может прямо назвать систему. Точность такого определения ограничена, потому что владелец может скрыть версию, удалив метатеги и переименовав пути, и тогда отчёт станет менее надёжным.
Сопоставление версий с базами CVE — это поиск известных уязвимостей, опубликованных для конкретной версии компонента. Если версия определена и для неё есть опубликованная уязвимость, сайт получает соответствующую отметку. Однако важно помнить, что уязвимость может быть закрыта в более поздней версии или в исправлении от разработчика без смены номера, поэтому отметка требует ручной проверки.
Обновление не всегда закрывает риск полностью. Остаются неиспользуемые плагины, которые продолжают лежать на сервере и могут быть эксплуатированы, старые файлы установки, которые стоило удалить, и неверные права доступа к каталогам. Поэтому после обновления стоит пройтись по списку компонентов, удалить всё лишнее и проверить права на запись в системные папки. Именно такие остаточные элементы часто становятся точкой входа при повторном взломе.
Как выбрать сервис проверки безопасности сайта: критерии и сравнение подходов
Первый критерий — глубина проверки. Внешний анализ даёт срез того, что видно снаружи, а сервисы с расписанием и мониторингом повторяют проверку и сообщают о новых угрозах. Если вам нужна разовая картина, достаточно внешнего сканера, а если важна постоянная защита, нужен механизм регулярных пересканов и оповещений.
Второй критерий — прозрачность методики. Хороший сервис объясняет, по каким правилам выставляется оценка, какие базы используются и что означает каждая находка. Возможность экспортировать отчёт тоже важна: он нужен для передачи разработчикам, хостингу или для фиксации состояния до и после работ. Закрытая черта оценки, которую нельзя ни проверить, ни объяснить, — повод усомниться в результате.
Третий критерий — частота обновления баз, наличие программного интерфейса и политика хранения данных о сайте. Нужно понимать, как долго сервис хранит результаты и кому они доступны, особенно если речь идёт о внутренних проектах. Наконец, стоит сравнить стоимость бесплатного и платного тарифов и ограничения бесплатной версии: число проверок, глубину и срок кэширования результатов.
Сравнивая подходы, стоит различать три уровня. Онлайн-сканер даёт быстрый внешний срез за минуты и подходит для первичной оценки. Локальные утилиты работают с файлами, но требуют доступа к серверу и навыков их разбора. Аудит специалиста — самый глубокий вариант, в котором проверяется код, конфигурация и история событий. Каждый уровень закрывает свою часть задачи, и их разумно сочетать, а не выбирать один.
Пошаговый порядок проверки и сроки выполнения
Подготовка начинается со сбора доступов и данных. Заранее стоит подготовить список доменов и поддоменов, которые нужно проверить, данные о хостинге и CMS, доступ к Search Console и почтовым записям. Также полезно зафиксировать текущее состояние: сохранить копию сайта и базы, чтобы иметь точку отсчёта на случай необходимости восстановления или расследования.
Выбор момента для проверки тоже имеет значение. Лучше запускать сканирование в период, когда команда разработки может оперативно реагировать на находки, а не перед длительным отпуском или запуском новой кампании. Согласование с теми, кто отвечает за сайт, заранее экономит время, потому что многие исправления требуют изменений в конфигурации или в коде.
Разбор отчёта лучше начинать с критичных находок: признаков активного вредоносного кода, попадания в чёрный список и устаревших компонентов с известными уязвимостями. Ориентировочно первичная проверка занимает от пяти до тридцати секунд, но полный цикл с исправлениями и повторным сканированием растягивается на часы или дни, в зависимости от объёма работ.
Типичные ошибки при проверке безопасности сайта и как их избежать
Самая распространённая ошибка — принять ложное срабатывание за реальную угрозу и наоборот. Поэтому любую находку стоит проверить по источнику: откуда подключён скрипт, кто его добавил и зачем.
Вторая ошибка — игнорировать оценку ниже A без понимания причин. Правильный подход — открыть каждый пункт, понять его риск и решить, что закрывать первым, а что можно отложить.
Ошибки после получения отчёта касаются двух вещей. Первая — исправление симптомов без поиска точки входа: удалили вредоносный код, но не нашли уязвимый плагин, через который он попал, и заражение вернулось через неделю. Пароли нужно менять обязательно, но делать это стоит после устранения источника, иначе злоумышленник, сохранивший доступ через бэкдор, останется внутри. Такой порядок действий и есть главный вывод: проверка даёт карту, но вылечить сайт можно только тогда, когда вы понимаете, откуда пришла угроза, и закрываете именно эту дверь.