Сегодня мы в Beeline Cloud решили обсудить RFC 9116, который описывает security.txt. Это — своеобразная «визитная карточка» с контактной информацией владельца ресурса. Она позволяет сообщить ему или ИБ-специалистам организации о найденных уязвимостях.
Несмотря на то, что стандарт был опубликован IETF, он так и не обрел популярность. Обсудим, как получилось, что достаточно простое и понятное решение, которое было призвано помочь безопасникам, стало еще одним источником их головной боли.
О каких уязвимостях идет речь
В прошлом году один крупный международный хостинг-провайдер проанализировал порядка пятисот веб-приложений и составил собственный список наиболее распространенных уязвимостей по типу OWASP Top 10. Специалисты обнаружили о��оло 2,5 тыс. случаев, связанных с возможностью проведения межсайтового скриптинга (в основном из-за устаревших библиотек JavaScript), а также выявили свыше 1,2 тыс. уязвимостей, позволяющих злоумышленникам реализовать атаку типа кликджекинг.
Что касается ситуации в России, то, согласно последним отчетам ИБ-компаний, практически каждое второе веб-приложение имеет серьезные уязвимости. В целом, ситуацию с безопасностью корпоративных веб-приложений в России мы разбирали в одном из предыдущих материалов. Говорили о том, почему они остаются любимой мишенью злоумышленников, и что в этом контексте предлагают решения класса Web Application Firewall.
В целом ни для кого уже не новость, что свежие уязвимости в веб-приложениях обнаруживаются с завидной регулярностью; и многие из них злоумышленники практически сразу «берут в работу». Например, в июле этого года были атакованы сервера Microsoft SharePoint — хакеры получили контроль над системами через цепочку эксплойтов, основанных на уязвимостях CVE-2025-49704 и CVE-2025-49706.
Новые угрозы появляются, конечно же, и в ходе эксплуатации хорошо изученных легаси-систем и технологий — например, таких как HTTP/1.1 (протокол до сих пор используется, хотя и серьезно проигрывает HTTP/2 и HTTP/3). В этом году появилась новая вариация атаки HTTP Desync, которая оказалась способна привести к массовой компрометации учетных данных и ранее считалась «неэксплуатируемой».
В то же время дополнительные риски появляются и в рамках обыкновенной работы над проектами — в ходе их совершенствования и настройки. По различным оценкам, до трети всех обнаруженных уязвимостей из списка OWASP Top 10 — следствие неправильной конфигурации окружения и технологического стека. Но и мисконфигурации — лишь одна из множества причин, влияющих на ИБ-риски.
Нельзя просто так взять и сообщить о баге
Поскольку закрыть весь спектр ИБ-рисков силами одной команды сложно, организации стимулируют сторонних специалистов участвовать в поиске уязвимостей. Для одних поиск дыр в безопасности становится своего рода хобби, которое позволяет совмещать профессиональные интересы с пользой для общества. Для других заработок на программах bug bounty превращается в полноценный источник дохода. Однако, как пишет один из профессиональных bug bounty-хантеров, такой заработок связан с высокими рисками и может быть крайне трудозатратным. Поэтому помимо хакеров-одиночек существуют и целые исследовательские организации, которые проводят тесты интернет-инфраструктуры и уведомляют компании об обнаруженных уязвимостях. Как правило, такие коллективы существуют на гранты и финансируются различными фондами.
Тем не менее, найти уязвимость и понять, в чем причина, — это лишь половина дела. Пытаясь сообщить владельцам сайта или домена о потенциальной угрозе, исследователи часто сталкиваются с неожиданной проблемой — невозможностью найти контактные данные ответственного лица. Какую-то информацию можно найти через интернет-регистраторов и Whois, однако она зачастую оказывается неактуальной. При этом существующие конвенции с описанием формата коммуникаций не рассчитаны на ИБ-специалистов. Так, Себастьян Пиппинг, который курирует список организаций, использующих libexpat для парсинга XML, рассказал, как пытался разослать компаниям уведомление об обнаруженной уязвимости: «Найти нужный контакт службы безопасности было нетривиальной задачей, в некоторых случаях этого не получилось сделать вообще».
Аналогичным опытом делится Скотт Хельме, ИБ-исследователь, который развивает набор инструментов для оценки безопасности и сообщает организациям об обнаруженных уязвимостях из чувства долга. По его словам, отдельную боль представляют ситуации, когда нужно срочно предупредить компанию о критической уязвимости: «Я обращался в колл-центры, чаты, социальные сети и Бог знает куда еще, чтобы попытаться выйти на нужного человека. Этот процесс — настоящий кошмар, который отнимает у меня много времени, пока сайт и его пользователи остаются под угрозой».
Простое решение — security.txt
Еще десять лет назад проблему не просто «глухих», но «молчащих» телефонов и email-адресов заметил Эд Фодил, ИБ-исследователь и бывший аналитик компании HackerOne, развивающей bug bounty-платформу. Чтобы разрешить ситуацию, в 2017 году он предложил реализовать стандарт security.txt. Он описывает содержимое специального файла — того самого security.txt — который размещается в директории /.well-known и включает контактную информацию и инструкции для оповещения об уязвимостях. По сути, это — аналог robots.txt, только для специалистов по информационной безопасности.
Эд рассказывает, что идея оформилась после посещения конференции DEF CON и соревнований по кибербезопасности. Он размышлял о вкладе участников подобных мероприятий в развитие инфобеза: «Я решил перестать держать идеи при себе и начать делиться ими, работать над своими проектами». По его словам, источником вдохновения также послужили SECURITY.md и BUG-BOUNTY.md — файлы с политиками безопасности, которые разработчики добавляют в репозитории. В свою очередь, IETF-драфт нового стандарта был предназначен для более широких задач и включал следующие поля:
Contact — для указания email, номера телефона, URL специальной формы на сайте и других каналов коммуникации по теме уязвимостей.
Encryption — содержит ссылку на ключ шифрования, который ИБ-специалисты должны использовать для передачи сообщений.
Acknowledgements — компания может указать ссылку на веб-страницу, где она говорит спасибо исследователям, которые ей помогли.
Disclosure — формат предоставления информации об уязвимости.
При этом в репозитории, где автор делал заметки, изначально были отмечены и другие поля — например, In-scope, Out-of-scope-vuln, Rate-limit, Platform, Reward, Payment-method, Currency, Donate и Disallow. Они, помимо прочего, предоставляли больше информации о программах bug bounty, вознаграждении для этичных хакеров и декларировали, отчеты о каких уязвимостях не будут рассматриваться ИБ-специалистами компании, разместившей security.txt на своем сайте.
Разработчик решил не включать данные поля в драфт, потому что представители крупной технологической фирмы рекомендовали ему посмотреть, как владельцы сайтов отреагируют на новый стандарт. И уже потом корректировать его, анализируя обратную связь. В апреле 2022 года security.txt был опубликован как RFC 9116, и финальный список полей был действительно модернизирован. Например, было убрано поле Disclosure, вместо него появилось поле Policy со ссылкой на политики раскрытия информации — как стоит действовать ИБ-исследователям, желающим сообщить об уязвимости. Также появились поля:
Expires — дата, после которой файл ��читается устаревшим.
Hiring — информация о ИБ-вакансиях у компании-владельца сайта.
Preferred-Languages — языки, на которых стоит сообщать о найденных уязвимостях.
Canonical — здесь указан основной URL, по которому доступна актуальная версия файла security.txt. Если организации публикуют security.txt в нескольких местах (например, /.well-known/security.txt, /security.txt, на поддоменах), поле Canonical позволяет указать, какой из них является основным.
При этом стоит отметить, что стандарт security.txt должен был не заменить, но дополнить RFC 2142, который, помимо прочего, рекомендует владельцам сайтов завести почтовый ящик security@domain для приема сообщений о проблемах безопасности. Но поскольку RFC 2142 не специализирован и описывает стандартные адреса электронной почты для широкого спектра задач — в том числе для маркетинговых обращений — этот набор рекомендаций часто игнорируется. Несмотря на этот факт, некоторые участники ИТ-комьюнити до сих пор задаются вопросом, а стоило ли придумывать еще один стандарт?
Ты должен был бороться со злом, а не примкнуть к нему!
Стандарт security.txt приживается не слишком активно. По некоторым оценкам — например, на основе анализа ресурсов из рейтинга Tranco, включающего миллион наиболее посещаемых веб-страниц — на 2022 год security.txt был представлен лишь на 3724 сайтах (0,37%). Более свежую оценку, пусть и на меньшей выборке, привел в своем блоге Себастьян Пиппинг. В этом году он проверил 50 компаний из своего списка пользователей libexpat (в него вошли такие организации, как Bosch, Ford, Yamaha и др.) и обнаружил security.txt на сайтах только одиннадцати из них. Другой пример: в 2024 году разработчик Дарко Тодорич проанализировал 50 популярных сайтов в Сербии и не нашел ни одного, где бы присутствовал security.txt.
Причина состоит в том, что о стандарте знает не так уж много специалистов. Один из участников обсуждения данной темы отметил: «Всю свою жизнь я занимался технологиями, но впервые слышу о security.txt». Не способствует популярности стандарта и тот факт, что он до сих пор не является частью международных фреймворков информационной безопасности вроде ISO 27001.
Более того, далеко не все ИБ-специалисты и владельцы сайтов видят в security.txt однозначное благо. Есть мнение, что раскрытие каналов для связи с ИБ-специалистами — это отличный способ собрать пачку спама с сомнительными сообщениями об уязвимостях. Как пишет один из резидентов тематического форума, довольно большое количество сообщений, которые он получает, выглядят так: «Критическая проблема: у вас не настроена SPF-запись, мы бы хотели обсудить с вами детали, сколько вы заплатите?».
Некоторые опасения также связаны с тем, что контакты из security.txt могут использоваться не по прямому назначению: «На мой взгляд, все, что находится в зоне .well-known, предназначено для автоматизированных систем. Единственная автоматизированная система, которая использует security.txt — парсеры email-адресов». Показательно, что даже на официальном сайте стандарта в разделе Projects перечислены десятки парсеров для анализа содержимого security.txt.
Есть еще одна потенциальная проблема, которая ставит под вопрос целесообразность security.txt. Он должен помочь владельцам сайтов предотвратить взломы и утечки данных, но, если злоумышленник успел скомпрометировать ресурс, ничего не мешает ему модифицировать и сам файл — например, подменить контактные данные, чтобы владелец не получил уведомление об уязвимости. RFC 9116 предлагает использовать поле Canonical и цифровую подпись. Если у специалистов по ИБ возникает подозрение, что файл скомпрометирован, им стоит использовать альтернативные способы связи — что снова возвращает их к исходной проблеме поиска релевантных контактов.
Наконец, даже если файл существует (что само по себе редкость) и не был изменен, он часто оказывается некорректно оформлен. Так, в британской технической консалтинговой компании провели исследование и обнаружили примерно тысячу сайтов (из выборки в миллион), на которых файл присутствовал, но его формат отличался от описанного в стандарте. В 2022 году специалисты из Карлтонского университета в Канаде тоже проанализировали миллион доменов и обнаружили, что имеющиеся файлы security.txt нередко были устаревшими или заполненными с ошибками. Иногда в них отсутствовали ключевые поля — например, контактная информация (sic!).
Что еще больше шокировало исследователей — у ряда крупных площадок в графе Contact красовалась почта из примера в описании стандарта [mailto:security@example.co].
Сложно сказать наверняка, что поможет повысить узнаваемость стандарта security.txt, сделать его более распространенным. Однако отдельные страны уже реализуют профильные инициативы. Например, в Нидерландах государственные сайты обязали работать с security.txt на законодательном уровне. В начале 2023 года файл был только на 20% ресурсов, но местное правительство планировало значительно увеличить эту цифру. В США была предпринята похожая инициатива: в декабре 2019 года Агентство по безопасности и информации (CISA) обязало все федеральные агентства внедрить стандарт security.txt, чтобы третьи лица могли сообщать об ошибках и недостатках на веб-сайтах. Наконец, к популяризации стандарта присоединилось и open source-комьюнити. Энтузиасты разрабатывают инструменты для генерации файлов security.txt на основе JSON-шаблонов. Наконец, тот факт, что стандарт продвигают крупные игроки, в том числе облачные и CDN-провайдеры, тоже может сыграть важную роль в его дальнейшем распространении.
Beeline Cloud — secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.
Материалы в нашем блоге на Хабре: