Niestety, jedynym ogólnym rozwiązaniem tego problemu jest zapewnienie użytkownikom https://jedynego i upewnienie się, że oczekują tylko tego. Ostatecznym obowiązkiem użytkownika jest sprawdzenie, czy korzysta on z SSL / TLS, zgodnie z oczekiwaniami.
Inne rozwiązania są podatne na ataki typu man-in-the-middle, nawet jeśli witryna akceptuje tylko połączenia SSL / TLS. Atakujący mogą przechwycić ruch do http://example.com(zgodnie z żądaniem użytkownika, nawet jeśli nawet example.comnie nasłuchuje na tym porcie) i zastąpić go, nawiązując własne połączenie z https://example.comserwerem proxy i przesyłając go z powrotem do użytkownika.
Z tego powodu istniała reguła OWASP przeciwko automatycznym przekierowaniom. Został usunięty, prawdopodobnie dlatego, że przekierowania nie są złym sposobem na ograniczenie ryzyka (szczególnie w przypadku pasywnego podsłuchiwania), ale nie rozwiązują podstawowego problemu.
Istnieją różne techniki, których można użyć, aby poprowadzić użytkownika do strony HTTPS, i nie jest to zły pomysł, aby z nich korzystać (chociaż nie ochroni ich przed aktywnymi atakującymi MITM).
Po pierwsze, jeśli nie masz w ogóle niczego, co powinno być podawane w zwykłym HTTP na serwerze WWW, wyłącz port 80 (np. Usuń Listen 80w konfiguracji Apache Httpd). Użytkownicy będą musieli korzystać https://przez cały czas, co może być niewygodne.
Po drugie, w sekcji konfiguracji Apache Httpd dla konkretnej ścieżki (albo Locationalbo Directory), użyj SSLRequireSSLdyrektywy : będzie wymagało użycia SSL / TLS (nawet jeśli skonfigurowałeś go na alternatywnym porcie). Inne serwery sieciowe prawdopodobnie mają podobne dyrektywy.
Po trzecie, możesz użyć przekierowania, używając mod_rewritelub w kodzie (jeśli jest to aplikacja). Coś takiego powinno być zrobione dla konkretnej lokalizacji ( zobacz HTTPSzmienną specjalną ; możesz także użyć 302, ale 301 jest lepsze, jeśli ma to być bardziej trwałe):
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(samples/.*)$ https://example.com/$1 [R=301,L]
Co ważniejsze, upewnij się, że wszystkie linki do tej bezpiecznej sekcji korzystają https://. Nigdy nie polegaj na automatycznym przekierowaniu, aby wykonać zadanie za Ciebie. Z tego powodu odradzam używanie go w ogóle na etapie programowania .
Zauważyłem jednak, że nadal mogę bezpiecznie uzyskiwać dostęp do witryny, tj. za pomocą httpzamiast https.
Brzmi to również tak, jakbyś używał tej samej konfiguracji zarówno dla, jak httpi dla https. Jeśli używasz Apache Httpd, sugerowałbym podzielenie konfiguracji na dwa odrębne VirtualHosts: jeden dla portu 80 i jeden dla portu 443. Nie muszą mieć dokładnie tej samej konfiguracji: po prostu nie umieszczaj tego, co jest tylko dla HTTPS w ogóle wirtualnego hosta HTTP.
Sposobem na złagodzenie wyżej wymienionych problemów jest użycie protokołu HTTP Strict Transport Security w przeglądarkach, które go obsługują (o ile wiem, dotyczy całego hosta). Pierwsze połączenie może być nadal widoczne, jeśli https://nie jest używane bez przekierowania, ale możliwe jest, aby mieć wstępnie załadowaną listę witryn, które i https:// tak oczekują (i włączone dla HSTS).
https://mail.google.com. Jeśli, jako użytkownik, widzisz, że to działahttp://mail.google.com, prawdopodobnie istnieje MITM pośredniczący w żądaniach do oryginałuhttps://mail.google.com. Niestety Gmail nie może wiele z tym zrobić, jeśli sami użytkownicy nie sprawdzą. Ta sama zasada, co w prawdziwym życiu: jeśli Alice chce porozmawiać z Bobem, ale rozmawia z Chuckiem (który twierdzi, że jest Bobem) zamiast weryfikować identyfikator, Bob nie będzie wiedział o tej rozmowie i nie będzie mógł cokolwiek na ten temat. Odpowiedzialność Alice.Wystarczy przekierować ruch HTTP na https - patrz ten artykuł „Przekieruj http na https bezpieczne połączenie Apache - wymuś połączenia HTTPS” .
W przypadku podkatalogu umieść go w pliku htaccess w samym katalogu.
źródło
Wymuszanie dostępu przez HTTPS jest w rzeczywistości możliwe, oprócz tego, że jest to konieczny krok, aby Twoja witryna była odporna na MITM, snooper i PEBKAC. To nie powinno być obowiązkiem użytkownika, to nie działa . Zachęć użytkowników do korzystania z bezpiecznych przeglądarek.
Wymuszanie HTTPS odbywa się za pomocą HSTS ( HTTP Strict-Transport-Security ). Podstawowy HSTS jest bezpieczny po pierwszym wejściu na twoją stronę przez HTTPS (we wszystkich obsługiwanych przeglądarkach; IE nie ma takiej możliwości ). Fabrycznie załadowany HSTS jest zawsze bezpieczny i obejmuje nowoczesne przeglądarki z szybkim wydaniem (Chromium i pochodne, Firefox).
Aby uzyskać pełniejszy przegląd zabezpieczeń HTTP (adresy URL, przekierowania, pliki cookie i mieszane treści), zapoznaj się z tym poradnikiem dotyczącym migracji HTTPS . HSTS to ostatni krok w stopniowej migracji. Naprawdę nie musisz przestrzegać kolejności, jeśli Twoja witryna jest nowa.
Powiązane standardy: bezpieczne pliki cookie (ważne, jeśli pliki cookie żyją dłużej niż nagłówek HSTS), pliki cookie HttpOnly ( podczas zabezpieczania plików cookie), HPKP (dla nowoczesnych przeglądarek i bardziej zasobnych osób atakujących).
źródło