Пассивное внешнее сканирование. Каждая находка содержит исходное наблюдение сканера
и команду, которую вы можете выполнить сами для воспроизведения - ничего здесь не написано моделью.
14 группы проверок:
Разрешение DNS и проверка записей CAA · Проверка SPF и DMARC · Проверка сертификата TLS и версий протокола · Проверка перенаправления с HTTP на HTTPS · Чтение заголовков безопасности ответа · Проверка атрибутов cookie · Анализ политики CORS · Поиск баннеров версий · Проверка разрешённых методов HTTP · Сканирование главной страницы на смешанный контент и небезопасные формы · Поиск открытых файлов конфигурации и систем контроля версий · Проверка листинга каталогов · Чтение robots.txt и security.txt · Проверка открытых портов служб
Запуск…
0%
О сервисе Сканирование безопасности сайта
Многие сканеры выдают оценку буквой и список пугающих слов. Этот тоже ставит оценку, но каждый снятый балл привязан к находке, где показан реально полученный ответ и однострочная команда, которая вернёт вам тот же ответ. Находку можно проверить, а не принимать на веру.
Что делает
Проверяет DNS и CAA, SPF и DMARC, TLS-сертификат и TLS 1.0/1.1, перенаправление на HTTPS, заголовки безопасности, атрибуты cookie, CORS, баннеры версий, методы HTTP, смешанное содержимое, 23 чувствительных пути, листинги каталогов, robots.txt, security.txt и 12 сервисных портов.
Каждый результат содержит исходное наблюдение и команду shell для его воспроизведения.
Проверки, которые не удалось выполнить, отмечаются как "не проверено" - никогда молча как пройденные.
Отчёты скачиваются в формате Markdown или JSON.
Как это работает
1Введите домен, за который вы отвечаете.
2Сканирование выполняет пассивные пробы - обычные запросы, без эксплойтов.
3Прочитайте результаты, каждый со своим доказательством, и проверьте те, что важны.
Ни один результат не выдуман
В сканере нет языковой модели. Критичность, последствия и способ исправления заданы для каждой проверки заранее, а каждая находка строится по реальному наблюдению. Отчёт на экране и выгрузки в Markdown и JSON собираются из тех же находок, без участия какой-либо модели.
Как считается оценка
Счёт начинается со 100 и теряет 34 балла за каждую критическую находку, 13 за высокую, 5 за среднюю и 1,5 за низкую, с потолком для каждой степени (высокая 45, средняя 22, низкая 9). Информационные и пройденные проверки баллы не снимают. 90 и выше это A, от 75 B, от 60 C, от 40 D, ниже F. Один открытый файл .env или доступный порт базы данных опускает чистый сайт со 100 до 66, то есть до C; две такие находки дают 32, F.
Как избегаются ложные тревоги
Прежде чем проверять пути вроде /.git/HEAD или /backup.sql, сканер запрашивает случайный адрес, которого не может существовать, и запоминает ответ сайта. Путь считается открытым, только если он отдаёт HTTP 200, отличается от этого эталонного ответа и совпадает с сигнатурой самого файла. Поэтому сайт, который на любой URL отвечает главной страницей, не покрывается критическими находками.
Чистый отчёт - не сертификат
Это пассивные проверки работающего сайта. Они не охватывают логику приложения, аутентификацию, контроль доступа или что-либо за экраном входа - места, где обычно начинаются настоящие взломы. Проверки, которые не удалось завершить, перечислены как непроверенные именно по этой причине: успех, полученный из неудавшегося соединения, - это ложное успокоение, а сканирование без результатов означает, что ничего не найдено, а не что ничего нет.
Сканируйте только своё
Сканируйте домены, которыми вы владеете, или на тестирование которых у вас есть письменное разрешение. Инструмент отказывает хостам, которые разрешаются в приватные или внутренние адреса, и ограничен по частоте на один IP, но ответственность за авторизацию остаётся на вас.
Вопросы
Это активная атака?
Нет. Он делает обычные запросы GET, HEAD и OPTIONS, TLS-рукопожатия (включая попытки с TLS 1.0 и 1.1), DNS-запросы через DNS-over-HTTPS от Cloudflare и простые TCP-подключения к 12 портам. Ничего не эксплуатируется, формы не отправляются и ничего не изменяется.
Могу я сканировать любой сайт?
Только те, которыми вы владеете или на тестирование которых у вас есть разрешение. Сканирование чужой инфраструктуры без разрешения может быть незаконным в вашей юрисдикции.
Почему проверка показывает "не проверено"?
Потому что её не удалось завершить - обычно потому, что на этом источнике ничего не ответило. Это честно отмечается, а не записывается как пройденная проверка.
Могу я экспортировать отчёт?
Да, в Markdown или JSON, в течение часа: отчёт хранится в кэше сервера это время, чтобы работали загрузки, а затем удаляется. Ни одна выгрузка не использует модель. В записи об использовании остаются число находок и оценка, но не домен.
Какие файлы и порты проверяются?
Файлы: 23 фиксированных пути, среди них /.git/HEAD, /.git/config, /.env, /.env.local, /.env.production, /.aws/credentials, /id_rsa, /backup.zip, /backup.sql, /dump.sql, /wp-config.php.bak, /phpinfo.php, /server-status, /actuator/env; каждый отмечается, только если ответ совпадает с сигнатурой именно этого файла. Опубликованный /.well-known/security.txt засчитывается в вашу пользу. Порты: обычное TCP-подключение, без попыток входа, к 21 FTP, 23 Telnet, 25 SMTP, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 3389 RDP, 5900 VNC, 11211 Memcached, 8080. Доступный из интернета порт базы данных (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch) или Telnet оценивается как критический.
Что отмечают проверки SPF и DMARC?
Обе записи читаются из публичного DNS, даже если сайт не отправляет почту: без них кто угодно может рассылать письма якобы от имени вашего домена. Нет записи SPF - средний уровень; SPF с +all, разрешающий отправку любому серверу в интернете, - высокий. Нет записи DMARC в _dmarc - средний; p=none (или нет тега p=) только наблюдает - низкий; p=quarantine или p=reject проходит проверку. Домен, который вообще не отправляет почту, может опубликовать v=spf1 -all.
Какие заголовки безопасности проверяются и какое значение проходит?
Шесть заголовков в ответе вашей главной страницы. При отсутствии HSTS и Content-Security-Policy - высокий уровень, X-Content-Type-Options и X-Frame-Options - средний, Referrer-Policy и Permissions-Policy - низкий. Strict-Transport-Security требует max-age не меньше 15552000 (180 дней): меньше - низкий, max-age=0 - средний. Content-Security-Policy отмечается как ослабленная (средний), если script-src разрешает 'unsafe-inline', политика разрешает 'unsafe-eval' или в default-src либо script-src стоит одиночный подстановочный знак *. X-Content-Type-Options должен быть ровно nosniff. X-Frame-Options должен быть DENY или SAMEORIGIN и не нужен, если CSP задаёт frame-ancestors. Referrer-Policy отмечается только при unsafe-url или no-referrer-when-downgrade. Permissions-Policy достаточно просто указать. К каждому отсутствующему или слабому заголовку приложена команда curl -sI, чтобы вы могли проверить его сами.
Как проверяются атрибуты cookie (Secure, HttpOnly, SameSite)?
Сканер читает каждый заголовок Set-Cookie в ответе главной страницы (до 12 cookie) и проверяет у каждого Secure, HttpOnly и SameSite. Отсутствие Secure или HttpOnly - средний уровень; отсутствие только SameSite - низкий, а SameSite=None без Secure отмечается отдельно, потому что браузеры отвергают такую cookie. Cookie со всеми тремя атрибутами проходит. Обычное исправление: Secure; HttpOnly; SameSite=Lax (в Django: SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY и SESSION_COOKIE_SAMESITE). Сканер не входит в аккаунт, поэтому cookie, которые ставятся только после входа, он не видит. Проверить самостоятельно: curl -sI https://your-site/ | grep -i set-cookie
Как работает проверка CORS и когда она критическая?
Сканер отправляет один GET-запрос на главную страницу с Origin: https://scanner-probe.example и читает в ответе Access-Control-Allow-Origin и Access-Control-Allow-Credentials. Нет заголовка Access-Control-Allow-Origin или указан фиксированный origin, не повторяющий тестовый, - проверка пройдена. Возврат тестового origin вместе с Access-Control-Allow-Credentials: true - критический уровень: любой сайт, который откроет вошедший пользователь, сможет читать его ответы. Возврат origin без учётных данных - средний. Подстановочный знак * - низкий, или средний, если разрешены и учётные данные (браузеры такую комбинацию отвергают). Проверяется только главная страница, предварительный запрос OPTIONS не отправляется, поэтому маршруты API проверяйте отдельно: curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control
Что проверяет TLS-проверка (срок действия сертификата, TLS 1.0 и 1.1)?
Сканер подключается к порту 443 и проверяет цепочку сертификатов и имя хоста. Сертификат, не прошедший проверку, получает высокую критичность, просроченный дополнительно отмечается как критический, а сертификат, которому осталось меньше 15 дней, получает среднюю; в остальных случаях субъект, издатель, дата окончания и имена SAN показываются как пройденная проверка. Согласованный протокол должен быть TLS 1.2 или TLS 1.3, всё более старое получает высокую критичность. Затем сканер отдельно пробует рукопожатие TLS 1.0 и TLS 1.1: если сервер принимает любое из них, это средняя находка, поскольку обе версии объявлены устаревшими в RFC 8996. Если собственный OpenSSL сканера не может предложить старую версию, ничего не сообщается, а не выдаётся догадка. Исправление для nginx: ssl_protocols TLSv1.2 TLSv1.3; Проверьте даты сами командой echo | openssl s_client -connect your-site:443 -servername your-site 2>/dev/null | openssl x509 -noout -dates
Проверяет ли он перенаправление с HTTP на HTTPS?
Да. Он запрашивает http://your-site/, не следуя перенаправлениям. Ответ 301 или 308 на адрес https:// проходит проверку. 302, 303 или 307 на HTTPS получает низкую критичность, потому что браузеры не запоминают временное перенаправление и каждый новый визит начинается с одного незашифрованного запроса. Страница, отданная по незашифрованному HTTP (ответ 2xx), получает высокую критичность. Если порт 80 вообще не отвечает, это информационное сообщение, а не ошибка. Исправление для nginx: server { listen 80; return 301 https://$host$request_uri; }, затем добавьте Strict-Transport-Security. Проверьте сами командой curl -I http://your-site/
Какие HTTP-методы он отмечает (TRACE, PUT, DELETE)?
Сканер отправляет один запрос OPTIONS на главную страницу и читает заголовок Allow, а если его нет, то Access-Control-Allow-Methods. Если объявлены TRACE, TRACK, PUT или DELETE, это средняя критичность; одни только PATCH или CONNECT дают низкую; только стандартные методы чтения проходят проверку. Если сервер не отправляет ни один из этих заголовков, ничего не сообщается. Объявленный метод не обязательно работает, поэтому проверьте его, прежде чем что-то менять. TRACE может вернуть вызывающему заголовки запроса вместе с cookie (Cross-Site Tracing). nginx по умолчанию отклоняет TRACE; в Apache укажите TraceEnable Off. Оставьте PUT и DELETE только тем маршрутам API, которым они нужны, и закройте их аутентификацией. Проверьте сами командой curl -X OPTIONS -i https://your-site/
Как он находит листинг каталогов ("Index of /")?
Сканер запрашивает 7 путей: /, /static/, /assets/, /uploads/, /images/, /files/ и /backup/. Путь, который отвечает HTTP 200 страницей, чей заголовок title или главный заголовок начинается с "Index of /", получает среднюю критичность (CWE-548), потому что листинг показывает файлы, на которые нигде нет ссылок: резервные копии, выгрузки и старые версии. Если таких путей нет, проверка пройдена; если сайт недоступен, она отмечается как не выполненная. Исправление для nginx: autoindex off; (это значение по умолчанию, так что ищите явный autoindex on), для Apache: Options -Indexes, затем уберите всё конфиденциальное из корня сайта. Проверьте сами командой curl -s https://your-site/uploads/ | head -20
Находит ли он смешанное содержимое и формы, отправляемые по HTTP?
Да, на главной странице. Сканер читает HTML в том виде, в каком его отдаёт сервер (JavaScript не выполняется), и перечисляет каждый тег script, link, iframe или img, у которого src или href начинается с http://. Если среди них есть файл .js или .css, находка средняя: подменённый по пути скрипт или стиль выполняется внутри вашей HTTPS-страницы; только изображения и фреймы дают низкую; если таких нет, проверка пройдена (CWE-311). Форма, у которой action начинается с http://, получает высокую оценку (CWE-319), потому что всё, что в неё вводят, включая пароли, уходит без шифрования. Исправление: перевести эти URL на https:// или сделать их относительными и добавить заголовок Content-Security-Policy: upgrade-insecure-requests как страховку. Проверить самостоятельно: curl -s https://your-site/ | grep -Eo "(src|href|action)=.http://[^ >]*"
Что он проверяет в robots.txt и security.txt?
robots.txt: сканер загружает /robots.txt и, если ответ HTTP 200 и это текстовый файл, читает строки Disallow в первых 8000 символах. Путь Disallow, содержащий admin, internal, private, backup, config, staging, test, api, secret, dev, получает низкую оценку (CWE-200): robots.txt публичен и лишь просит добросовестных роботов не заходить, поэтому перечисление таких путей их только рекламирует. Защитите их входом по паролю, а страницы из поиска убирайте через noindex. security.txt: сканер запрашивает /.well-known/security.txt, место, заданное RFC 9116, и засчитывает файл в вашу пользу, если в нём есть строка Contact:. Отсутствие файла баллы не снижает. RFC 9116 также требует поле Expires:, которое сканер не проверяет, поэтому публикуйте оба, например Contact: mailto:security@your-site, Expires: 2027-06-30T23:00:00Z. Проверить самостоятельно: curl -s https://your-site/.well-known/security.txt
Что ищет проверка CAA и как добавить запись CAA?
Она запрашивает записи CAA (RFC 8659) для введённого имени хоста через DNS-over-HTTPS Cloudflare. Если записи найдены, проверка пройдена, а в доказательствах показано до 5 из них; если нет, выводится "No CAA record" с низкой важностью, потому что тогда любой публичный удостоверяющий центр может выпустить сертификат для этого имени. Запись CAA перечисляет центры сертификации, которыми вы реально пользуетесь, например your-site. IN CAA 0 issue "letsencrypt.org", плюс 0 iodef "mailto:security@your-site" для получения уведомлений. Добавьте строку issue для каждого используемого CA и строку issuewild, если wildcard-сертификаты должен выпускать другой CA. Проверить самостоятельно: dig CAA your-site
Почему при сканировании www или поддомена нет CAA, SPF или DMARC?
Каждая DNS-проверка выполняется для точного введённого имени: www.example.com запрашивается как www.example.com, а не как example.com, а три записи наследуются по-разному. CAA: удостоверяющий центр, не найдя записи CAA на www.example.com, поднимается к example.com и использует её (RFC 8659, раздел 3), поэтому "No CAA record" на поддомене может быть ложной тревогой. DMARC: получатели используют политику организационного домена, которая может задать отдельную политику для поддоменов через sp= (RFC 9989, заменивший RFC 7489), поэтому отсутствие записи в _dmarc.www.example.com обычно покрывается записью _dmarc.example.com. SPF: наследования нет (RFC 7208), поэтому "No SPF record" для этого имени верно; имя хоста, которое не отправляет почту, может опубликовать v=spf1 -all. Неудачный DNS-запрос тоже отображается как отсутствующая запись. Просканируйте и основной домен без www или проверьте командами dig CAA example.com и dig TXT _dmarc.example.com