Генератор security.txt

security.txt — это лучшая практика веб-безопасности, официально стандартизированная IETF (Internet Engineering Task Force) в RFC 9116, разработанная для предоставления сайтам унифицированного, стандартного способа публикации контактной информации безопасности. Проще говоря, это текстовый файл, размещенный по фиксированному пути на сайте, говорящий исследователям безопасности (хакерам white hat): «Если вы обнаружите уязвимости безопасности на моем сайте, вот как с нами связаться, вот наш открытый ключ шифрования, вот наша политика раскрытия, и мы приветствуем ваши отчеты».

До появления стандарта security.txt контактная информация безопасности сайтов была хаотичной. Некоторые сайты вообще не имели контактной информации безопасности, некоторые прятали ее на какой-то неясной странице, некоторые указывали только необслуживаемый адрес электронной почты info@, а некоторые требовали кропотливого поиска в LinkedIn, чтобы найти команду безопасности. Это вызвало серьезную проблему: когда добросовестные исследователи безопасности обнаруживали уязвимости, они часто не могли найти правильный канал для их сообщения. Результатом было — многие уязвимости молча откладывались на полку, оставлялись неисправленными, пока не были обнаружены и эксплуатированы злонамеренными хакерами. security.txt родился, чтобы решить эту проблему «последней мили».

Концепция security.txt была впервые предложена исследователями безопасности EdOverflow и Yakov Shafranovich в 2017 году и быстро получила широкую поддержку отрасли. В апреле 2022 года security.txt был официально утвержден IETF как RFC 9116, став международно признанным стандартом веб-безопасности. Сегодня крупные технологические компании, такие как Google, GitHub, Meta (Facebook), LinkedIn и Cloudflare, а также государственные учреждения, включая правительство Великобритании, CISA США (Агентство по кибербезопасности и защите инфраструктуры), правительство Франции, правительство Италии, правительство Нидерландов и Австралийский центр кибербезопасности, развернули security.txt на своих официальных сайтах и публично рекомендуют другим организациям принять его.

Основная конструкция файла security.txt очень проста — это обычный текстовый файл, состоящий из строк в формате «имя-поля: значение», аналогично формату заголовка HTTP. Стандарт определяет два обязательных поля: Contact (контактная информация безопасности, которая может быть множественной) и Expires (время истечения файла); а также несколько необязательных полей: Encryption (URL открытого ключа шифрования PGP), Acknowledgments (URL страницы благодарностей), Policy (URL политики раскрытия уязвимостей), Hiring (URL вакансий безопасности), Canonical (канонический URL файла), Preferred-Languages (поддерживаемые языки отчетов) и CSAF (URL метаданных поставщика Common Security Advisory Framework). Этот простой формат облегчает анализ как людям, так и машинам.

Почему развертывание security.txt так важно? Во-первых, оно снижает барьер для отчетности об уязвимостях. Исследователям безопасности не нужно тратить значительное время на поиск контактной информации — они могут найти правильный канал отчетности в один клик. Во-вторых, это демонстрирует упреждающее отношение организации к безопасности — сайт с security.txt по сути говорит: «Мы серьезно относимся к безопасности и приветствуем ответственные отчеты». В-третьих, это снижает риск публичного раскрытия или эксплуатации уязвимостей: имея официальный канал, исследователи не будут выбирать публичное раскрытие уязвимостей напрямую в Twitter или GitHub, потому что не смогут ни с кем связаться. В-четвертых, во многих отраслевых регуляторных требованиях (например финансы, здравоохранение, правительство) создание канала раскрытия уязвимостей стало требованием соответствия.

При развертывании security.txt следует обратить внимание на несколько ключевых деталей. Во-первых, путь должен быть правильным: стандартный путь — /.well-known/security.txt, и вы также можете разместить копию в /security.txt в корневом каталоге в качестве запасного варианта. Каталог .well-known здесь — это стандартный каталог «хорошо известных ресурсов», определенный RFC 8615, где другие стандартные файлы, такие как robots.txt, также размещаются в связанных местоположениях. Во-вторых, он должен обслуживаться по HTTPS — простой HTTP считается небезопасным. В-третьих, Content-Type должен быть text/plain, а не text/html или другими типами. В-четвертых, не выполняйте междоменные перенаправления для security.txt — если https://example.com/.well-known/security.txt перенаправляет на https://другой-домен.com/security.txt, исследователи и автоматизированные инструменты сочтут это подозрительным. В-пятых, не забывайте устанавливать поле Expires и регулярно его обновлять; истекший security.txt будет считаться имеющим ненадежную информацию.

Поле Contact — самое важное поле в security.txt и единственное по-настоящему необходимое поле (Expires также обязательное, но это просто метка времени). Contact поддерживает три формата URI: mailto: для адресов электронной почты, https:// для веб-ссылок (например страниц форм отчетности по безопасности) и tel: для номеров телефонов. Настоятельно рекомендуется предоставить как минимум один адрес электронной почты mailto и одну ссылку на форму https — формы предотвращают спам от ботов, в то время как электронная почта более удобна для исследователей для прямой отправки зашифрованных отчетов. Несколько контактов могут быть перечислены в нескольких строках, например одновременно предоставляя адрес электронной почты команды безопасности, адрес электронной почты руководителя безопасности и ссылки на сторонние платформы уязвимостей.

Хотя поле Encryption необязательное, на практике оно очень важно. Когда исследователи безопасности обнаруживают критическую уязвимость (такую как утечка данных пользователя или удаленное выполнение кода), они абсолютно не хотят отправлять сведения об уязвимости в электронном письме в открытом виде — потому что электронная почта проходит через несколько серверов во время передачи, любой узел может быть подслушан. Шифрование открытым ключом PGP (Pretty Good Privacy) является отраслевым стандартом безопасной связи. Вам нужно только сгенерировать пару ключей PGP, разместить открытый ключ на своем сайте (например по адресу /.well-known/pgp-key.txt) и ввести этот URL в поле Encryption. Исследователи шифруют контент отчета вашим открытым ключом, и только те, кто владеет соответствующим закрытым ключом, могут его расшифровать и прочитать.

Поле Policy связывается с вашей страницей Политики раскрытия уязвимостей (Vulnerability Disclosure Policy, VDP), которая является ключом к построению доверия исследователей. Хорошая VDP должна четко указывать: область тестирования (какие системы входят в область тестирования и какие — вне области), разрешенные методы тестирования (например тестирование SQL injection/XSS разрешено, но DDoS/социальная инженерия/доступ к реальным данным пользователей запрещены), гарантированные времена реакции (например «Мы подтвердим получение отчетов в течение 3 рабочих дней»), предлагаются ли вознаграждения и обязательства по правовой безопасной гавани (четко указывающие о непреследовании добросовестных исследователей, соблюдающих правила). Существует множество шаблонов VDP, доступных на международном уровне для справки, и CISA США также предоставляет шаблон VDP с открытым исходным кодом.

Помимо самого контакта безопасности, у security.txt есть несколько «неожиданных» полей. Поле Acknowledgments создает Зал славы безопасности — публично благодаря исследователей, которые помогают вам находить уязвимости, что признает их работу, а также служит построению сообщества. Поле Hiring — очень умный дизайн: люди, которые могут находить уязвимости на вашем сайте, по своей сути являются отличными талантами в области безопасности, и размещение ссылки на набор в security.txt — это наиболее точный канал набора талантов в области безопасности. Многие компании наняли отличных инженеров по безопасности через security.txt. Поле Canonical — это соображение безопасности — предотвращение подделки злоумышленниками вашего security.txt в других доменах.

Что касается распространенного беспокойства о спаме, на практике большинство организаций, развернувших security.txt, сообщают о незначительном увеличении спама. Это происходит потому, что: во-первых, спамеры обычно не получают адреса электронной почты путем сканирования security.txt; во-вторых, ссылки на формы https:// можно использовать вместо прямого размещения электронных писем mailto, и добавление CAPTCHA к формам может полностью блокировать ботов; в-третьих, выделенные электронные письма безопасности (например security@) обычно имеют строгую фильтрацию спама, настроенную. Напротив, стоимость пропуска критических отчетов об уязвимостях из-за отсутствия канала контактов безопасности намного перевешивает потенциальное увеличение небольших количеств спама.

Этот генератор создан в строгом соответствии со стандартом RFC 9116, и все форматы вывода нормализованы: поле Contact автоматически распознает префиксы, поле Expires использует стандартный формат времени UTC ISO 8601, а Preferred-Languages автоматически устанавливается на основе языка, который вы используете. Сгенерированный контент можно напрямую скопировать и развернуть по пути /.well-known/security.txt без каких-либо модификаций. Кроме того, вся конфигурация выполняется локально в вашем браузере и никогда не отправляется ни на какой сервер — ваша контактная информация безопасности всегда остается на вашем устройстве. Развертывание security.txt занимает всего 5 минут, но канал коммуникации по безопасности, который он создает, может помочь вам избежать серьезного инцидента безопасности в будущем.