Generuj raporty dotyczące nadużyć dla rejestratorów, dostawców usług hostingowych i sieci CDN – w formie wiadomości e-mail oraz pliku JSON.
Nowe
Generator pliku security.txt
Działa lokalnie
Samo narzędzie jest w języku angielskim; na tej stronie znajdziesz wyjaśnienia w Twoim języku.
Użyj Generator pliku security.txt
Jak to działa
Utwórz plik security.txt, aby badacze i osoby zgłaszające przypadki phishingu podszywającego się pod Twoją markę wiedziały, jak się z Tobą skontaktować. Zapisz plik pod nazwą /.well-known/security.txt.
Działa całkowicie w przeglądarce: żadne wprowadzone dane nie są przesyłane.
Jak korzystać z Generator pliku security.txt
- Dodaj kontakt. W polu „Kontakt” wpisz informacje o tym, jak skontaktować się z zespołem ds. bezpieczeństwa, po jednej pozycji w każdym wierszu: adres e-mail mailto:security@example.com, adres https:// formularza zgłoszeniowego lub numer tel.:. Do samego adresu e-mail zostanie dodany prefiks „mailto:”.
- Ustaw datę ważności. Wybierz datę w polu „Wygasanie”. Domyślnie ustawiono rok od dzisiaj; norma RFC 9116 zaleca okres krótszy niż rok, więc wybierz wcześniejszą datę.
- Dodaj pola opcjonalne. Wypełnij pola „Preferred-Languages” (domyślnie „en”), „Canonical”, „Policy”, „Encryption”, „Acknowledgments” oraz „Hiring”, jeśli są dostępne. Puste pola nie zostaną uwzględnione w pliku.
- Wygeneruj i skopiuj. Naciśnij przycisk „Generuj” i sprawdź wynik w polu wyników. Sprawdź jeszcze raz wszystkie adresy, ponieważ narzędzie kopiuje je dokładnie tak, jak zostały wpisane, a następnie naciśnij przycisk „Kopiuj”.
- Opublikuj i odnów. Zapisz tekst jako plik /.well-known/security.txt na swojej stronie za pośrednictwem protokołu HTTPS, podpisz go za pomocą polecenia `gpg --clearsign`, jeśli chcesz, i zanotuj datę, aby odnowić go przed wygaśnięciem.
Przykład
Plik minimalny
mailto:security@example.comContact: mailto:security@example.com
Expires: 2027-10-20T23:59:59.000Z
Preferred-Languages: enGeneruje pole „Contact”: mailto:security@example.com, datę wygaśnięcia „Expires” ustaloną na rok w przyszłości o godz. 23:59:59Z oraz pole „Preferred-Languages”: en – dwa pola obowiązkowe oraz wskazówkę dotyczącą języka – wraz z przypomnieniem, że norma RFC 9116 zaleca ustalenie daty wygaśnięcia „Expires” na okres krótszy niż rok.
Co jest sprawdzane
| Sygnał | Co to oznacza |
|---|---|
| Kontakt: | Jedna linia na kontakt, w kolejności, w jakiej zostały wpisane. Każdy wpis musi mieć postać adresu mailto:, https:// lub tel: zgodnie z wymogami RFC 9116; adresy typu http:// oraz nieprawidłowe wartości powodują wyświetlenie błędu zamiast pliku. |
| Ważność do: | Wybrana data o godz. 23:59:59 czasu UTC, podana z dokładnością do milisekund, na przykład 2027-03-31T23:59:59.000Z. Jeśli wyczyścisz pole daty, funkcja „Generuj” przestanie tworzyć nowy plik. |
| Preferowane języki: | domyślnie „en”. Należy używać kodów języków rozdzielonych przecinkami, np. „en”, „de”, lub wyczyścić to pole, aby pominąć tę linię. |
| Canonical: | Pełny adres https://, pod którym znajduje się ten plik, dzięki czemu można rozpoznać kopię udostępnianą z innego źródła. |
| Szyfrowanie: | Link do Twojego klucza publicznego OpenPGP, dzięki czemu dziennikarze będą mogli zaszyfrować poufne informacje. |
| Polityka, podziękowania, rekrutacja | Linki do polityki ujawniania informacji, strony z podziękowaniami dla dziennikarzy oraz ofert pracy w dziedzinie bezpieczeństwa. Wszystkie te elementy są opcjonalne, a narzędzie nie sprawdza, czy linki działają. |
| Adres funkcji w sekcji „Kontakt” | Należy korzystać z adresu lub formularza, z którego korzysta cały zespół, np. security@twojadomena, a nie ze skrzynki pocztowej jednej osoby, aby zgłoszenia nadal docierały, nawet gdy pracownicy zmieniają stanowisko. |
| Błąd: Wymagane jest podanie danych kontaktowych | Wyświetla się, gdy pole „Kontakt” jest puste. Wszelkie błędy zastępują wyświetlany tekst komunikatem informującym, że nic nie zostało wygenerowane, dopóki pola nie zostaną poprawione. |
Więcej przykładów
Formularz internetowy z opcjami językowymi i informacjami o zasadach
Contact https://example.org/report-security, Expires 2027-03-31, Preferred-Languages en, de, Canonical https://example.org/.well-known/security.txt, Policy https://example.org/security-policyPięć wierszy w następującej kolejności: Kontakt: https://example.org/report-security, Termin ważności: 2027-03-31T23:59:59.000Z, Preferowane języki: en, de, Canonical: https://example.org/.well-known/security.txt, Polityka: https://example.org/security-policy.
Kontakt e-mailowy z kluczem, bez języka
Contact mailto:abuse@example.net, Expires 2027-06-30, Preferred-Languages cleared, Encryption https://example.net/pgp-key.txtTrzy wiersze: Kontakt: mailto:abuse@example.net, Termin ważności: 2027-06-30T23:59:59.000Z oraz Szyfrowanie: https://example.net/pgp-key.txt.
Pole „Kontakt” pozostawiono puste
All fields filled except ContactBłąd: Wymagane jest wypełnienie pola „Kontakt”, a ponadto pojawiła się informacja, że nic nie zostało wygenerowane. Pozostałe pola zachowują swoje wartości, więc należy wypełnić pole „Kontakt” i ponownie nacisnąć przycisk „Generuj”.
Najczęściej zadawane pytania
Które pola są obowiązkowe?
RFC 9116 wymaga co najmniej jednego pola „Contact” i dokładnie jednego pola „Expires”; pozostałe pola są opcjonalne. Każda linia „Contact” musi mieć postać URI typu „mailto:”, „https://” lub „tel:” (do samego adresu e-mail dodawane jest „mailto:”), pole „Expires” musi zawierać datę przyszłą, a pole „Generate” wyświetla komunikat o błędzie zamiast pliku, jeśli któreś z tych pól brakuje lub jest nieprawidłowe.
Na jaką wartość powinienem ustawić parametr „Expires”?
Domyślną datą jest rok od dzisiaj, podczas gdy RFC 9116 zaleca okres krótszy niż rok, więc wybierz wcześniejszą datę, aby zachować zgodność z tym zaleceniem; strona wyświetli przypomnienie, jeśli data ta przypada za ponad rok. Odnów plik przed upływem tej daty, ponieważ zgodnie z RFC wygasły plik security.txt należy traktować jako nieaktualny.
Czy program coś przesyła lub podpisuje?
Nie. Plik jest tworzony w przeglądarce i nic nie jest nigdzie wysyłane. Nie jest on podpisany; norma RFC 9116 zaleca podpis OpenPGP w postaci zwykłego tekstu, który można dodać za pomocą polecenia `gpg --clearsign` przed opublikowaniem.
Czy mogę podać więcej niż jedną osobę kontaktową?
Tak. Specyfikacja RFC 9116 dopuszcza podanie kilku wierszy z danymi kontaktowymi, które są odczytywane według kolejności preferencji. W polu „Kontakt” należy wpisać po jednym kontakcie w każdym wierszu; zduplikowane wpisy są zapisywane tylko raz.
Gdzie dokładnie trafia ten plik?
Pod adresem https://your-domain/.well-known/security.txt, udostępniana przez protokół HTTPS w postaci zwykłego tekstu. Umieszczenie kopii lub przekierowania pod adresem /security.txt jest opcjonalne.
Czy jeden plik obejmuje wszystkie moje subdomeny?
Nie. Zgodnie z dokumentem RFC 9116 plik security.txt ma zastosowanie wyłącznie do serwera, z którego został pobrany, a nie do jego subdomen ani domeny nadrzędnej. Należy opublikować kopię tego pliku na każdym serwerze, na którym użytkownicy mogą go szukać, np. na www i shop.
W jaki sposób plik security.txt pomaga w walce z phishingiem, w którym wykorzystuje się nazwę mojej marki?
Osoby, które natrafiają na stronę wyglądającą podobnie do Twojej lub fałszywy e-mail wysłany w Twoim imieniu, często chcą Cię o tym ostrzec. Działający kanał kontaktowy przekazuje takie zgłoszenie bezpośrednio do Twojego zespołu ds. bezpieczeństwa, a nie do ogólnej kolejki pomocy technicznej, dzięki czemu możesz szybciej podjąć działania w sprawie tej podobnej domeny.