Generator security.txt

security.txt to najlepsza praktyka bezpieczeństwa sieci Web formalnie ustandaryzowana przez IETF (Internet Engineering Task Force) w RFC 9116, zaprojektowana w celu zapewnienia witrynom ujednoliconego, standardowego sposobu publikowania informacji kontaktowych bezpieczeństwa. Mówiąc prościej, jest to plik tekstowy umieszczony w stałej ścieżce w witrynie, mówiący badaczom bezpieczeństwa (hakerom white hat): „Jeśli znajdziesz luki w zabezpieczeniach mojej witryny, oto jak się z nami skontaktować, oto nasz klucz publiczny szyfrowania, oto nasza polityka ujawniania i czekamy na Twoje raporty”.

Przed powstaniem standardu security.txt informacje kontaktowe bezpieczeństwa witryn były przypadkowe. Niektóre witryny w ogóle nie miały informacji kontaktowych bezpieczeństwa, niektóre ukrywały je na jakiejś niejasnej stronie, niektóre podawały tylko nieobsługiwany adres e-mail info@, a niektóre wymagały żmudnego wyszukiwania na LinkedIn, aby znaleźć zespół bezpieczeństwa. Spowodowało to poważny problem: gdy badacze bezpieczeństwa działający w dobrej wierze odkrywali luki, często nie mogli znaleźć właściwego kanału do ich zgłoszenia. Rezultatem było — wiele luk zostało cicho odłożonych na półkę, pozostawionych niezałatanych, dopóki nie zostały odkryte i wykorzystane przez złośliwych hakerów. security.txt powstał, aby rozwiązać ten problem „ostatniej mili”.

Koncepcja security.txt została po raz pierwszy zaproponowana przez badaczy bezpieczeństwa EdOverflowa i Yakova Shafranovicha w 2017 roku i szybko zyskała szerokie wsparcie branży. W kwietniu 2022 r. security.txt zostało formalnie zatwierdzone przez IETF jako RFC 9116, stając się międzynarodowo uznanym standardem bezpieczeństwa sieci Web. Obecnie duże firmy technologiczne, takie jak Google, GitHub, Meta (Facebook), LinkedIn i Cloudflare, a także agencje rządowe, w tym rząd Wielkiej Brytanii, amerykańska CISA (Agencja Bezpieczeństwa Cybernetycznego i Infrastruktury), rząd Francji, rząd Włoch, rząd Holandii i Australijskie Centrum Cyberbezpieczeństwa, wdrożyły security.txt na swoich oficjalnych witrynach i publicznie zalecają innym organizacjom jego przyjęcie.

Podstawowa konstrukcja pliku security.txt jest bardzo prosta — jest to plik zwykłego tekstu składający się z wierszy w formacie „nazwa-pola: wartość”, podobny do formatu nagłówka HTTP. Standard definiuje dwa obowiązkowe pola: Contact (informacje kontaktowe bezpieczeństwa, które mogą być wielokrotne) i Expires (czas wygaśnięcia pliku); a także kilka opcjonalnych pól: Encryption (adres URL klucza publicznego szyfrowania PGP), Acknowledgments (adres URL strony podziękowań), Policy (adres URL polityki ujawniania luk), Hiring (adres URL ofert pracy bezpieczeństwa), Canonical (kanoniczny adres URL pliku), Preferred-Languages (obsługiwane języki raportów) i CSAF (adres URL metadanych dostawcy Common Security Advisory Framework). Ten prosty format ułatwia analizowanie zarówno ludziom, jak i maszynom.

Dlaczego wdrożenie security.txt jest tak ważne? Po pierwsze, obniża barierę zgłaszania luk. Badacze bezpieczeństwa nie muszą poświęcać dużo czasu na znajdowanie informacji kontaktowych — mogą znaleźć właściwy kanał zgłaszania jednym kliknięciem. Po drugie, demonstruje proaktywne podejście organizacji do bezpieczeństwa — witryna z security.txt zasadniczo mówi: „Traktujemy bezpieczeństwo poważnie i czekamy na odpowiedzialne raporty”. Po trzecie, zmniejsza ryzyko publicznego ujawnienia lub wykorzystania luk: mając formalny kanał, badacze nie będą wybierać publicznego ujawniania luk bezpośrednio na Twitterze lub GitHubie, ponieważ nie mogą się z nikim skontaktować. Po czwarte, w wielu wymaganiach regulacyjnych branży (np. finanse, opieka zdrowotna, rząd) ustanowienie kanału ujawniania luk stało się wymogiem zgodności.

Podczas wdrażania security.txt należy zwrócić uwagę na kilka kluczowych szczegółów. Po pierwsze, ścieżka musi być poprawna: standardowa ścieżka to /.well-known/security.txt, a kopię można również umieścić w /security.txt w katalogu głównym jako rezerwę. Katalog .well-known w tym miejscu jest standardowym katalogiem „dobrze znanych zasobów” zdefiniowanym w RFC 8615, w którym inne standardowe pliki, takie jak robots.txt, są również umieszczane w powiązanych lokalizacjach. Po drugie, musi być obsługiwany przez HTTPS — niezaszyfrowany HTTP jest uważany za niebezpieczny. Po trzecie, Content-Type musi być text/plain, a nie text/html lub inny typ. Po czwarte, nie wykonuj przekierowań międzydomenowych dla security.txt — jeśli https://example.com/.well-known/security.txt przekierowuje do https://inna-domena.com/security.txt, badacze i zautomatyzowane narzędzia uznają to za podejrzane. Po piąte, pamiętaj o ustawieniu pola Expires i regularnym go aktualizowaniu; wygasłe security.txt zostanie uznane za posiadające niewiarygodne informacje.

Pole Contact jest najważniejszym polem w security.txt i jedynym naprawdę niezbędnym polem (Expires również jest obowiązkowe, ale jest tylko znacznikiem czasu). Contact obsługuje trzy formaty URI: mailto: dla adresów e-mail, https:// dla linków sieci Web (np. stron formularzy zgłaszania bezpieczeństwa) i tel: dla numerów telefonów. Zdecydowanie zaleca się podanie co najmniej jednego adresu e-mail mailto i jednego linku do formularza https — formularze zapobiegają spamowi botów, podczas gdy poczta e-mail jest wygodniejsza dla badaczy do bezpośredniego wysyłania zaszyfrowanych raportów. Wiele kontaktów może być wymienionych w wielu wierszach, na przykład jednocześnie podając adres e-mail zespołu bezpieczeństwa, adres e-mail kierownika bezpieczeństwa i linki do platform luk w zabezpieczeniach stron trzecich.

Chociaż pole Encryption jest opcjonalne, w praktyce jest bardzo ważne. Gdy badacze bezpieczeństwa odkryją krytyczną lukę (taką jak wyciek danych użytkownika lub zdalne wykonanie kodu), absolutnie nie chcą wysyłać szczegółów luki w wiadomości e-mail w postaci jawnej — ponieważ poczta e-mail przechodzi przez wiele serwerów podczas transmisji, każdy węzeł może zostać podsłuchany. Szyfrowanie kluczem publicznym PGP (Pretty Good Privacy) jest branżowym standardem bezpiecznej komunikacji. Wystarczy wygenerować parę kluczy PGP, umieścić klucz publiczny w witrynie (np. pod adresem /.well-known/pgp-key.txt) i wprowadzić ten adres URL w polu Encryption. Badacze szyfrują zawartość raportu Twoim kluczem publicznym, a tylko osoby posiadające odpowiedni klucz prywatny mogą go odszyfrować i odczytać.

Pole Policy łączy się z Twoją stroną Polityki Ujawniania Luk (Vulnerability Disclosure Policy, VDP), która jest kluczem do budowania zaufania badaczy. Dobra VDP powinna jasno określać: zakres testowania (które systemy są w zakresie testowania, a które poza zakresem), dozwolone metody testowania (np. testowanie SQL injection/XSS dozwolone, ale DDoS/inżynieria społeczna/dostęp do rzeczywistych danych użytkownika zabronione), zobowiązane czasy reakcji (np. „Potwierdzamy otrzymanie raportu w ciągu 3 dni roboczych”), czy oferowane są nagrody za luki oraz zobowiązania dotyczące bezpiecznej przystani prawnej (jasno określające nieściganie badaczy działających w dobrej wierze, którzy przestrzegają zasad). Istnieje wiele szablonów VDP dostępnych międzynarodowo do wglądu, a amerykańska CISA również udostępnia szablon VDP o otwartym kodzie źródłowym.

Oprócz samego kontaktu bezpieczeństwa, security.txt ma kilka „zaskakujących” pól. Pole Acknowledgments tworzy Galerię Sław Bezpieczeństwa — publicznie dziękując badaczom, którzy pomagają znaleźć luki, co uznaje ich pracę, a także służy budowaniu społeczności. Pole Hiring to bardzo sprytny projekt: ludzie, którzy potrafią znaleźć luki w Twojej witrynie, są z natury doskonałymi talentami bezpieczeństwa, a umieszczenie linku rekrutacyjnego w security.txt to najprecyzyjniejszy kanał rekrutacji talentów bezpieczeństwa. Wiele firm zatrudniło doskonałych inżynierów bezpieczeństwa za pośrednictwem security.txt. Pole Canonical to kwestia bezpieczeństwa — zapobieganie fałszowaniu przez atakujących Twojego security.txt w innych domenach.

Jeśli chodzi o powszechne obawy dotyczące spamu, w praktyce większość organizacji, które wdrożyły security.txt, zgłasza znikomy wzrost spamu. Dzieje się tak dlatego, że po pierwsze, spamujący zazwyczaj nie uzyskują adresów e-mail przez indeksowanie security.txt; po drugie, zamiast bezpośredniego umieszczania wiadomości e-mail mailto można używać linków do formularzy https://, a dodanie CAPTCHA do formularzy może całkowicie zablokować boty; po trzecie, dedykowane wiadomości e-mail bezpieczeństwa (np. security@) zwykle mają skonfigurowane surowe filtrowanie spamu. W przeciwieństwie do tego, koszt pominięcia krytycznych raportów o lukach z powodu braku kanału kontaktu bezpieczeństwa znacznie przewyższa potencjalny wzrost niewielkich ilości spamu.

Ten generator jest zbudowany w ścisłej zgodności ze standardem RFC 9116, a wszystkie formaty wyjściowe są znormalizowane: pole Contact automatycznie rozpoznaje prefiksy, pole Expires używa standardowego formatu czasu UTC ISO 8601, a Preferred-Languages jest automatycznie ustawiane na podstawie języka, z którego korzystasz. Wygenerowaną zawartość można bezpośrednio skopiować i wdrożyć do ścieżki /.well-known/security.txt bez żadnych modyfikacji. Ponadto cała konfiguracja jest wykonywana lokalnie w przeglądarce i nigdy nie jest wysyłana na żaden serwer — Twoje informacje kontaktowe bezpieczeństwa zawsze pozostają na Twoim urządzeniu. Wdrożenie security.txt zajmuje tylko 5 minut, ale kanał komunikacji bezpieczeństwa, który tworzy, może pomóc Ci uniknąć poważnego incydentu bezpieczeństwa w przyszłości.