Представьте, что исследователь безопасности нашёл серьёзную уязвимость на вашем сайте. Он хочет вам сообщить, но общий email на странице контактов попадает в маркетинговый отдел, а телефон — на ресепшен. Время идёт, уязвимость остаётся открытой, и в итоге её эксплуатирует кто-то другой. Именно для решения этой проблемы создан стандарт RFC 9116 — файл security.txt. Этот простой текстовый файл чётко указывает исследователям безопасности, куда сообщать об уязвимостях, и существенно упрощает процесс responsible disclosure.
Где располагается security.txt
Согласно стандарту RFC 9116 файл security.txt должен находиться в каталоге /.well-known/, то есть полный URL будет example.com/.well-known/security.txt. Это место выбрано не случайно — каталог .well-known определён как специальное расположение для различных интернет-стандартов, там также размещаются webfinger, ACME challenge, openid configuration и другие сервисы. Старые рекомендации допускали размещение в корневом каталоге, но для новых проектов рекомендуется только версия в .well-known. Файл обязательно должен обслуживаться через HTTPS.
Основные поля
В файле security.txt есть несколько полей, из которых самое важное — Contact, указывающее email или URL для отправки сообщений о безопасности. Поле Expires определяет срок действия файла и согласно RFC 9116 является обязательным. Preferred-Languages сообщает исследователям, на каких языках возможно общение. Поле Canonical указывает официальное расположение файла, что защищает от атак spoofing. Поле Acknowledgments даёт ссылку на страницу с благодарностями исследователям, сообщившим об уязвимостях.
Encryption и PGP-ключи
Для сообщения о конфиденциальных уязвимостях шифрованная связь крайне важна. Поле Encryption указывает, где находится PGP-ключ команды безопасности. Используя этот ключ, исследователь может зашифровать детали уязвимости и тем самым защитить данные от посторонних глаз. PGP-серверы ключей или ваш собственный сайт могут работать как место хранения ключа. Для систем с высокой чувствительностью это поле практически обязательно, так как отправка деталей уязвимости обычной почтой создаёт лишний риск.
Policy и Hiring
Поле Policy ссылается на страницу, объясняющую политику responsible disclosure компании. На этой странице обычно описан процесс сообщения об уязвимостях, сроки ответа компании, юридическая защита и часто — программа вознаграждений bug bounty. Поле Hiring интересным образом ссылается на вакансии для специалистов по безопасности и является отличным способом привлечь талантливого исследователя, нашедшего уязвимость. Многие крупные технологические компании именно таким путём построили великолепные команды безопасности.
Практика Сайт.уз
Сайт.уз внедрил файл security.txt в 2024 году, и он доступен по адресу sayt.uz/.well-known/security.txt. В файле указаны контактный адрес security@sayt.uz, ссылка на PGP-ключ и возможность общения на узбекском, русском и английском языках. В 2024 году 14 внешних исследователей сообщили через этот канал об уязвимостях, и все сообщения были подтверждены в среднем за 8 часов. В стоимость хостинга от 95 000 сум входит шаблон security.txt и руководство по созданию PGP-ключа. Для корпоративных клиентов предлагается специальная интеграция с bug bounty платформой от 1 600 000 сум, автоматизирующая работу с внешними исследователями.