security.txt

security.txt to plik tekstowy publikowany pod adresem /.well-known/security.txt, w którym właściciel serwisu podaje, jak zgłaszać mu podatności. Format opisuje RFC 9116 z września 2022 roku, autorstwa Edwina Foudila i Yakova Shafranovicha ^[1]. Plik jest czytelny zarówno dla człowieka, jak i dla programów: zawiera pola w postaci „nazwa: wartość”, a obowiązkowe są dwa z nich, Contact i Expires ^[1]. Nazwa pliku nie jest tłumaczona.

Jak działa

Plik rozwiązuje prosty problem: badacz bezpieczeństwa, który znalazł błąd, często nie wie, do kogo go zgłosić. Zamiast szukać adresu w stopce albo pisać na ogólną skrzynkę, pobiera plik ze znanej ścieżki i odczytuje kanał kontaktu. CERT Polska rekomenduje opublikowanie pliku zgodnie z RFC 9116, bo w ustandaryzowany sposób wskazuje, jak i gdzie zgłaszać podatności, i ułatwia szybkie dotarcie do właściwego kanału ^[2].

RYS. 1Zgłoszenie podatności przez security.txt

Plik jest wejściem do procesu skoordynowanego ujawniania podatności (CVD): mówi, gdzie zgłosić błąd i na jakich zasadach, ale samej obsługi zgłoszeń nie zastępuje.

Pola

RFC 9116 definiuje dwa pola wymagane i kilka opcjonalnych ^[1].

Pole Expires musi wystąpić dokładnie raz, a norma zaleca, by jego data była odległa o mniej niż rok ^[1]. Plik dotyczy wyłącznie domeny lub adresu IP, spod którego go pobrano, a nie subdomen ani domeny nadrzędnej ^[1]. Plik może zawierać komentarze zaczynające się znakiem #. Niektóre organizacje dopisują własne pola spoza RFC 9116; CERT Polska umieszcza na przykład pola CVD-Contact, CVD-Policy i CVD-Advisories związane z programem CVE ^[3]. Są to rozszerzenia, nie pola normy.

Przykładowy plik dla serwisu example.com:

Contact: mailto:security@example.com
Expires: 2027-06-30T00:00:00.000Z
Policy: https://example.com/polityka-zglaszania-podatnosci/
Preferred-Languages: pl, en
Canonical: https://example.com/.well-known/security.txt

Wymagania techniczne

RFC 9116 umieszcza plik w katalogu /.well-known/, zgodnie z ogólnym mechanizmem „dobrze znanych” adresów ^[1]. Dopuszcza też starszą lokalizację w katalogu głównym serwisu, na przykład przez przekierowanie ^[1]. Starsze opracowania, jak artykuł nfsec.pl z 2019 roku oparty jeszcze na wersji roboczej standardu, opisują obie lokalizacje, w tym plik obok robots.txt ^[6].

Plik musi być dostępny przez https i podawany z typem text/plain w kodowaniu UTF-8 ^[1]. Norma zaleca podpisanie go podpisem OpenPGP w postaci jawnego tekstu ^[1]. Tak robi CERT Polska: jego plik jest podpisany, podaje formularz kontaktowy, adres e-mail, klucz PGP i języki „en, pl” ^[3]. Podpis pozwala sprawdzić, że treści nie zmieniono po włamaniu na serwer; to zabezpieczenie ma sens, gdy klucz jest publikowany także w innym, niezależnym miejscu.

W WordPressie

WordPress nie tworzy pliku security.txt sam. Najprostszy sposób to umieszczenie statycznego pliku w katalogu .well-known w głównym katalogu instalacji; serwer WWW poda istniejący plik bezpośrednio, zanim reguły przepisywania adresów przekażą żądanie do WordPressa. Tę samą treść można też wystawić wtyczką. Ponieważ plik obejmuje tylko domenę, spod której go pobrano ^[1], w sieci Multisite z osobnymi domenami albo przy sklepie w subdomenie trzeba go udostępnić pod każdym z tych adresów. Po wdrożeniu warto sprawdzić, czy odpowiedź ma kod 200 i typ text/plain, a nie stronę błędu motywu.

Wzorem jest plik samego projektu WordPress. Wskazuje on program HackerOne jako kontakt, stronę z podziękowaniami i politykę zgłoszeń w podręczniku Core; ważność ustawiono do 30 czerwca 2027 roku ^[4]. Komentarz w pliku zaznacza, że ten kontakt dotyczy błędów w rdzeniu, błędy we wtyczkach z katalogu wordpress.org zgłasza się na adres plugins@wordpress.org, a właściciel zhakowanej strony powinien zwrócić się do administratora lub firmy hostingowej ^[4]. Polityka, do której prowadzi pole Policy, kieruje zgłoszenia dotyczące samodzielnie hostowanego WordPressa do programu HackerOne i prosi, by nigdy nie zgłaszać błędów bezpieczeństwa publicznie na forach wsparcia ani w systemie Core Trac ^[5].

Dla strony firmowej na WordPressie plik jest przede wszystkim informacją, dokąd kierować zgłoszenia dotyczące tej konkretnej witryny: podatności we wtyczce wykrytej na stronie, publicznie dostępnych plików wrażliwych albo błędnej konfiguracji zabezpieczeń.

Znaczenie i ryzyka

Plik skraca drogę zgłoszenia i zmniejsza ryzyko, że badacz opublikuje informację o błędzie, bo nie znalazł kontaktu. CERT Polska zaleca go producentom oprogramowania jako element procesu obsługi podatności, obok publicznego kanału zgłoszeń ^[2]; szerzej opisuje to hasło zarządzanie podatnościami. Plik uzupełnia też programy bug bounty: wskazuje, gdzie działa program i jakie są jego zasady.

RFC 9116 wymienia kilka ryzyk ^[1]:

• nieaktualne dane — według normy brak pliku może być lepszy niż plik z nieaktualnymi informacjami;
• spam na opublikowany adres kontaktowy;
• podmiana pliku po przejęciu serwisu, np. w ramach podmiany treści strony, która może skierować zgłoszenia do atakującego;
• zniekształcone pliki; norma sugeruje, by programy odrzucały pliki większe niż 32 KB albo pola dłuższe niż 2048 znaków.

Po stronie badaczy RFC 9116 zaleca sprawdzenie podpisu cyfrowego i dostępnej historii pliku przed użyciem zawartych w nim danych oraz ostrożność wobec przekierowań, bo mogą prowadzić do domeny kontrolowanej przez atakującego ^[1].

Pole Expires wymusza okresowy przegląd: gdy data minie, narzędzia uznają plik za nieaktualny ^[1]. Dlatego datę ważności wpisuje się razem z przypomnieniem o jej odnowieniu.