SSL stripping wykorzystuje moment, w którym użytkownik albo strona wpada jeszcze w HTTP. Atakujący próbuje utrzymać połączenie po swojej stronie jako nieszyfrowane, mimo że właściwa witryna powinna działać po HTTPS. Dla użytkownika wygląda to czasem jak zwykła strona. Różnica jest taka, że dane mogą przejść przez cudze ręce.

Ten temat brzmi technicznie, ale dotyczy bardzo zwykłych miejsc: formularza kontaktowego, panelu logowania, checkoutu, resetu hasła, panelu WordPressa i każdej strony, która przyjmuje dane użytkownika.

Jak działa SSL stripping w uproszczeniu?

Użytkownik wpisuje adres albo klika link zaczynający się od http://.
Strona normalnie powinna przekierować go na https://.
Atakujący będący między użytkownikiem a stroną próbuje zatrzymać użytkownika na słabszym połączeniu.
Użytkownik widzi stronę, ale jego przeglądarka nie ma prawdziwego szyfrowanego kanału do celu.

W praktyce nowoczesne przeglądarki i dobre konfiguracje mocno ograniczają ten scenariusz. Problem wraca przy starych linkach, źle ustawionych redirectach, mieszanej zawartości, braku HSTS albo panelach dostępnych pod wieloma wariantami domeny.

HTTPS na całej stronie, również poza logowaniem

Dawniej często szyfrowano wyłącznie koszyk albo formularz logowania. To słaby model. Strona powinna wymuszać HTTPS wszędzie: homepage, blog, formularze, panel, zasoby statyczne i endpointy API. Jeśli część zasobów ładuje się po HTTP, przeglądarka może blokować elementy albo obniżać zaufanie do strony.

Przekierowanie z HTTP do HTTPS ma być proste i jednoznaczne. Nie powinno prowadzić przez kilka etapów, wersję www, starą domenę i dopiero finalny adres. Im więcej przeskoków, tym więcej miejsca na błędy.

HSTS: przeglądarka ma pamiętać, że ma używać HTTPS

HSTS to nagłówek, który mówi przeglądarce: z tą domeną łącz się tylko po HTTPS. Dzięki temu po pierwszej poprawnej wizycie przeglądarka nie próbuje wracać do HTTP. Dla stron z logowaniem, płatnościami albo danymi użytkowników to jeden z podstawowych nagłówków do sprawdzenia.

Trzeba jednak wdrażać go świadomie. Jeśli domena ma subdomeny, stare aplikacje albo nietypowe środowiska, zbyt agresywny nagłówek może odciąć coś, co nadal działa tylko po HTTP. Najpierw audyt, potem konfiguracja.

Cookies też muszą być dobrze ustawione

Przy logowaniu ważne są flagi ciasteczek. Secure ogranicza wysyłkę cookie do HTTPS. HttpOnly utrudnia odczyt przez JavaScript. SameSite pomaga przy części ataków opartych o kontekst innej strony. To nie są magiczne talizmany, ale bez nich bezpieczeństwo sesji jest słabsze.

sesyjne cookies powinny mieć Secure,
panel admina nie powinien być dostępny przez HTTP,
linki w mailach powinny prowadzić od razu do HTTPS,
formularze nie mogą wysyłać danych na adres HTTP,
stare mixed-content assety trzeba wymienić albo przepiąć.

Co sprawdzić na swojej stronie?

Wejdź na http://twojadomena i sprawdź, czy kończysz na właściwym https://.
Sprawdź wersję z www i bez www.
Przejdź formularz kontaktowy, logowanie i checkout.
Sprawdź w narzędziach deweloperskich, czy nie ma mixed content.
Zweryfikuj nagłówek HSTS, jeśli strona obsługuje konta lub płatności.
Upewnij się, że stare adresy i redirecty nie cofają użytkownika do HTTP.

Na stronach po migracji to szczególnie ważne. Certyfikat może być poprawny, a mimo tego stare reguły przekierowań potrafią zostawić dziwne ścieżki z HTTP, pętle albo adresy prowadzące przez niepotrzebne warianty domeny.

Kiedy problem jest pilny?

Jeśli strona ma logowanie, płatności, dane osobowe albo panel klienta, konfigurację HTTPS trzeba traktować jako podstawę, nie kosmetykę. Przy zwykłej stronie wizytówkowej ryzyko jest mniejsze, ale błędny HTTPS nadal obniża zaufanie i może psuć formularze, analitykę oraz integracje.

Dobra konfiguracja nie musi być widowiskowa. Użytkownik ma po prostu trafić na właściwy adres, po szyfrowanym połączeniu, bez myślenia o tym, co dzieje się po drodze.

Źródła pomocnicze: OWASP TLS Cheat Sheet, MDN: Strict-Transport-Security.