Defaults.Exposed › Naprawy › HSTS (Strict-Transport-Security)

Jak naprawić HSTS (Strict-Transport-Security)

HSTS to jednolinijkowa instrukcja, którą Twoja strona daje każdej przeglądarce: «zawsze wracaj do mnie przez bezpieczne, zaszyfrowane połączenie — nigdy przez niebezpieczne». Bez niego Twoja kłódka może zostać po cichu zdjęta w współdzielonym WiFi, a sama pierwsza wizyta na Twojej stronie jest wystawiona.

W skrócie dla Twojej firmy: Posiadanie HTTPS (kłódki) to nie to samo co jego wymuszanie. Bez HSTS atakujący w tej samej sieci WiFi co Twój klient może po cichu obniżyć połączenie do zwykłego, nieszyfrowanego HTTP — przechwytując logowania, dane kart i dane formularzy, podczas gdy klient nie widzi nic niepokojącego. Twój certyfikat SSL, za który być może płacisz, zostaje obejrzany. Naprawa jest darmowa i zajmuje około 15 minut osobie prowadzącej Twoją stronę.

Ile może Cię to kosztować

• Klienci w WiFi kawiarni, hotelu, lotniska czy konferencji mogą mieć połączenie z Twoją stroną po cichu obniżone, a ich dane odczytane — bez żadnego ostrzeżenia na ekranie.
• Zapłaciłeś za HTTPS i masz kłódkę, ale bez HSTS atakujący mogą po prostu ją obejść; certyfikat daje fałszywe poczucie bezpieczeństwa.
• Sama pierwsza wizyta na Twojej stronie (przed jakimkolwiek przekierowaniem na HTTPS) to słaby punkt, w który celują atakujący — HSTS jest tym, co zamyka go dla każdej kolejnej wizyty.
• Kwestionariusz bezpieczeństwa, formularz cyberubezpieczenia lub lista kontrolna kupującego z dużej firmy oznacza «brak HSTS» i wstrzymuje transakcję, dopóki nie zostanie naprawione.
• Ustawisz wartość źle (zbyt krótko) i dostajesz najgorsze z obu światów: wygląda na skonfigurowane, a daje niemal żadnej realnej ochrony.

Dlaczego to ma znaczenie. HTTPS chroni połączenie, gdy już jest zaszyfrowane — ale nie zmusza przeglądarek, by go używały. Atakujący wykorzystują tę lukę «zdejmowaniem SSL» (SSL stripping): w każdej współdzielonej sieci po cichu trzymają odwiedzającego na niebezpiecznym HTTP, czytając wszystko. HSTS każe przeglądarce całkowicie odmawiać zwykłego HTTP dla Twojej domeny, na długo, więc luka zamyka się po pierwszej wizycie. To pojedynczy nagłówek odpowiedzi, darmowy do dodania, a w naszej ocenie wart realnych punktów, bo brakująca lub zbyt krótka wartość zostawia każdego odwiedzającego w publicznym WiFi wystawionego.

Czym to jest, prostymi słowami

Niemal na pewno masz HTTPS — małą kłódkę w pasku przeglądarki. Dobrze. Ale oto część, o której prawie nikt nie jest informowany: posiadanie HTTPS to nie to samo co jego wymuszanie.

HTTPS czyni połączenie zaszyfrowanym gdy przeglądarka zdecyduje się go użyć. HSTS — skrót od HTTP Strict Transport Security — to instrukcja, która sprawia, że przeglądarka zawsze go używa. To pojedyncza, niewidzialna linia, którą Twoja strona wysyła każdemu odwiedzającemu, mówiąca w istocie:

„Od teraz, dla mojej domeny, rozmawiaj ze mną wyłącznie przez bezpieczne połączenie. Nigdy przez niebezpieczne. Nawet nie próbuj”.

Przeglądarka zapamiętuje to i przestrzega tak długo, jak każesz — zwykle rok. Po pierwszej bezpiecznej wizycie odwiedzającego jego przeglądarka po prostu odmówi wczytania Twojej strony przez zwykłe, nieszyfrowane HTTP, nawet jeśli coś będzie próbowało to wymusić.

Bez HSTS ta reguła „zawsze używaj bezpiecznej wersji” nie istnieje — a atakujący wiedzą dokładnie, jak wykorzystać tę lukę.

Ile może Cię to kosztować

To realne, codzienne scenariusze. Nigdy nie podajemy nazwy prawdziwej firmy; to ilustracje tego, jak luka jest wykorzystywana.

1. Kawiarniany koszyk. Klient otwiera Twój sklep w kawiarnianym WiFi i przechodzi do finalizacji. Atakujący w tej samej sieci uruchamia darmowe, dobrze znane narzędzie, które trzyma klienta na zwykłym HTTP zamiast HTTPS. Klient widzi coś, co wygląda jak Twoja normalna strona — bez ostrzeżenia, bez zepsutej kłódki w miejscu, gdzie by zerknął — i wpisuje dane karty. Atakujący czyta każde naciśnięcie klawisza. Twój certyfikat SSL nic nie zdziałał, bo połączeniu nigdy nie pozwolono stać się bezpiecznym.

2. Podróżujący pracownik. Członek personelu loguje się do Twojego panelu administracyjnego lub poczty z hotelu czy lotniska. Ta sama sztuczka z obniżeniem przechwytuje jego nazwę użytkownika i hasło. Teraz atakujący ma drogę do Twojej firmy — nie dlatego, że Twoja polityka haseł była słaba, ale dlatego, że strona logowania była osiągalna przez niebezpieczne HTTP.

3. Transakcja, która utyka. Większy klient przysyła Ci swój standardowy kwestionariusz bezpieczeństwa przed podpisaniem. Jedna linia pyta: „Czy Twoja strona wymusza HTTPS przez HSTS?”. Twój kontakt IT musi odpowiedzieć „nie”, a proces zakupowy zatrzymuje się, podczas gdy w pośpiechu naprawiasz darmowe, 15-minutowe ustawienie, które teraz wygląda jak czerwona flaga przed kupującym.

4. Kontrola cyberubezpieczenia lub zgodności. Skan ubezpieczyciela albo audytor przeglądający Twoją postawę ochrony danych oznacza brakujący nagłówek. Szyfrowanie danych osobowych to jawne oczekiwanie wedle reguł ochrony danych (RODO, artykuł 32), a „mamy certyfikat, ale go nie wymuszamy” to słaba pozycja do obrony.

5. Fałszywe poczucie bezpieczeństwa. Płacisz za SSL, kłódka się pokazuje i wszyscy zakładają, że strona jest bezpieczna. Przeważnie jest — aż klient znajdzie się w współdzielonej sieci, czyli dokładnie wtedy, gdy jest najbardziej narażony i najmniej skłonny zauważyć cokolwiek nie tak.

Wątek wspólny: koszt nie jest abstrakcyjny. To karta lub logowanie prawdziwego klienta, przechwycone w najgorszym możliwym momencie, bez żadnego alarmu.

Czym to właściwie jest

Gdy przeglądarka prosi Twoją stronę o stronę, Twój serwer odsyła ją wraz z niewidzialnymi „nagłówkami” — dodatkowymi instrukcjami, które przeglądarka czyta, a odwiedzający nigdy nie widzi. HSTS to jeden z tych nagłówków:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Trzy części mają znaczenie:

• max-age — jak długo (w sekundach) przeglądarka ma pamiętać, by wymuszać HTTPS. 31536000 to jeden rok. To sedno: za krótko i ledwo pomaga.
• includeSubDomains — rozszerz regułę na każdą subdomenę (shop., app., mail. itd.), nie tylko na Twój główny adres.
• preload — zgłoś swoją domenę na główną listę wbudowaną w przeglądarki, by ochrona obowiązywała nawet przy samym pierwszym żądaniu odwiedzającego, zanim kiedykolwiek zobaczył Twoją stronę.

Dlaczego „pierwsza wizyta” ma znaczenie

HSTS ma jedno wrodzone ograniczenie: przeglądarka przestrzega reguły dopiero po tym, jak zobaczy nagłówek przynajmniej raz. Więc samo pierwsze połączenie zupełnie nowego odwiedzającego to wciąż maleńkie okno wystawienia. Dwie rzeczy je zwężają: przekierowanie HTTP na HTTPS (które szybko przenosi go na bezpieczną wersję) oraz preload (które całkowicie usuwa okno). Dlatego kompletna konfiguracja łączy HSTS z porządnym przekierowaniem.

Jak wygląda „dobrze” — i jak się to ocenia

Nasza kontrola czyta Twój żywy nagłówek i ocenia max-age:

Więc nagłówek, który istnieje, ale ustawiony jest na kilka minut, traktowany jest jako niezaliczony — wygląda na skonfigurowany, ale nie spełnia zadania. Celuj w jeden rok. Kontrola odnotowuje też, czy obecne są includeSubDomains i preload.

Jak to naprawić (za darmo, ~15 minut)

Przekaż tę sekcję osobie prowadzącej Twoją stronę — informatykowi, deweloperowi WWW lub wsparciu hostingu. Naprawa jest darmowa. To pojedynczy nagłówek albo przełącznik w Twojej platformie hostingowej. Nie ma nic do kupienia.

Najpierw jedna ważna reguła kolejności: HSTS jest lepki — gdy raz włączony, przeglądarki będą odmawiać zwykłego HTTP dla Twojej domeny przez pełny max-age. Więc potwierdź, że HTTPS działa poprawnie na Twojej głównej stronie i każdej subdomenie, zanim włączysz go szeroko. Bezpieczna droga to: przetestuj z krótką wartością → potwierdź, że nic się nie psuje → podnieś do jednego roku.

Krok 1 — Upewnij się, że HTTPS już działa wszędzie

Odwiedź swoją stronę i kluczowe subdomeny przez https:// i potwierdź, że wczytują się czysto z ważnym certyfikatem. Potwierdź też, że zwykłe żądania http:// przekierowują na https://. (Jeśli nie, najpierw napraw przekierowanie HTTP na HTTPS — HSTS zakłada, że jest na miejscu.)

Krok 2 — Dodaj nagłówek (wybierz swoją platformę)

Cloudflare (lub podobny CDN): To najłatwiejsze. Wejdź do SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) i włącz go. Ustaw Max-Age na 6 lub 12 miesięcy i włącz „Apply HSTS policy to subdomains”, gdy będziesz pewien, że wszystkie subdomeny są na HTTPS.

Nginx: dodaj wewnątrz bloku server dla HTTPS:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Apache: upewnij się, że mod_headers jest włączony, potem dodaj do swojego wirtualnego hosta HTTPS:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Microsoft IIS: dodaj do web.config wewnątrz <customHeaders>:

<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />

Uwaga o Google Workspace / Microsoft 365: te zasilają Twoją pocztę, nie hosting strony — HSTS ustawia się tam, gdzie faktycznie żyje Twoja publiczna strona (Twój CDN, serwer WWW lub kreator stron), a nie w panelu Workspace/365. Jeśli Twoja strona jest na kreatorze jak Squarespace, Wix czy Shopify, HSTS jest zwykle obsługiwane za Ciebie; sprawdź ich ustawienia SSL/bezpieczeństwa, jeśli nasza kontrola coś oznaczy.

Krok 3 — Przetestuj na małą skalę, potem zatwierdź

Zacznij od max-age=300 (5 minut). Potwierdź, że strona wciąż wczytuje się idealnie wszędzie. Potem podnieś do max-age=31536000 (jeden rok). To ustawienie z pełną punktacją.

Krok 4 (opcjonalnie, złoty standard) — preload

Gdy nabierzesz pewności i przez jakiś czas uruchomisz roczny nagłówek z includeSubDomains, możesz zgłosić swoją domenę na hstspreload.org, by została wpieczona w przeglądarki. To zamyka okno pierwszej wizyty całkowicie. Traktuj to jak celowe zobowiązanie — usunięcie domeny z listy jest powolne.

Częste błędy

• Ustawienie max-age zbyt krótko. Wartość kilku minut lub godzin wygląda na skonfigurowaną, ale daje niemal żadnej ochrony — a nasza kontrola traktuje wszystko poniżej dnia jako niezaliczone. Użyj roku.
• Włączenie includeSubDomains, zanim subdomeny będą gotowe na HTTPS. Jeśli subdomena nie jest w pełni na HTTPS, lepka reguła może uczynić ją nieosiągalną dla odwiedzających. Najpierw przenieś każdą subdomenę na HTTPS.
• Dodanie HSTS, ale brak przekierowania HTTP na HTTPS. HSTS zakłada, że odwiedzający docierają do bezpiecznej wersji; bez przekierowania pierwsza wizyta jest niepotrzebnie wystawiona. Napraw oba razem.
• Skok od razu na preload, by «być dokładnym». Preload jest trudny do cofnięcia. Zasłuż na niego stopniowo, po stabilnym rocznym nagłówku — nie spiesz się.
• Zakładanie, że kłódka oznacza, że jesteś zabezpieczony. Kłódka i HSTS to różne rzeczy. Możesz mieć idealny certyfikat, a wciąż nie przejść tej kontroli.

Najczęstsze pytania