Czy łańcuch zapytań HTTPS jest bezpieczny?

Z punktu widzenia "sniff the network packet" żądanie GET jest bezpieczne, ponieważ przeglądarka najpierw ustanowi bezpieczne połączenie, a następnie wyśle żądanie zawierające parametry GET. Ale GET url ' s będą przechowywane w historii przeglądarki użytkowników / autouzupełnianie , co nie jest dobrym miejscem do przechowywania np. danych hasła. Oczywiście ma to zastosowanie tylko wtedy, gdy przyjmiesz szerszą definicję "Webservice", która może uzyskać dostęp do usługi z przeglądarki, jeśli uzyskasz do niej dostęp tylko z niestandardowej aplikacji to nie powinno być problemem.

Więc używanie post przynajmniej dla okien dialogowych haseł powinno być preferowane. Również jak wskazano w linku littlegeek opublikował GET URL jest bardziej prawdopodobne, aby być zapisane w logach serwera.

Tak. Cały tekst sesji HTTPS jest zabezpieczony protokołem SSL. Obejmuje to zapytanie i nagłówki. Pod tym względem POST I GET byłyby dokładnie takie same.

Jeśli chodzi o bezpieczeństwo Twojej metody, nie ma prawdziwego sposobu, aby powiedzieć bez odpowiedniej kontroli.

Tak , Twoje ciągi zapytań zostaną zaszyfrowane.

Powodem jest to, że ciągi zapytań są częścią protokołu HTTP, który jest protokołem warstwy aplikacji, podczas gdy część bezpieczeństwa (SSL/TLS) pochodzi z warstwy transportowej. Najpierw zostanie ustanowione połączenie SSL, a następnie parametry zapytania (które należy do protokołu http) zostaną wysłane do serwera.

Podczas ustanawiania połączenia SSL, twój Klient wywoła następujące kroki w kolejności. Załóżmy, że próbujesz zalogować się na stronę o nazwie example.com {[28] } i chcesz wysłać swoje poświadczenia za pomocą query params . Twój kompletny URL może wyglądać następująco.

(e.g https://example.com/login?username=alice&password=12345) 

Przeglądarka / aplikacja mobilna) najpierw rozwiąże nazwę domeny (example.com) na adres IP (124.21.12.31) za pomocą żądania DNS. Podczas odpytywania tych informacji używane są tylko informacje dotyczące domeny. ie: tylko example.com będzie używane.
1. teraz twój Klient spróbuje połączyć się z serwerem z adresem IP 124.21.12.31 i spróbuje połączyć się z portem 443 (SSL Port serwisowy nie jest domyślnym http port 80).
2. teraz serwer w example.com wyśle swoje certyfikaty do twojego klienta.
3. twój Klient zweryfikuje certyfikaty i rozpocznie wymianę wspólnego tajnego klucza dla twojej sesji.
4. Po pomyślnym ustanowieniu bezpiecznego połączenia, tylko parametry zapytania będą wysyłane za pośrednictwem bezpiecznego połączenia.

Dlatego ty nie ujawni poufnych danych. Jednak wysyłanie poświadczeń przez sesję https przy użyciu tej metody nie jest najlepszym sposobem. Powinieneś wybrać inne podejście.

SSL najpierw łączy się z hostem, więc nazwa hosta i numer portu są przesyłane jako czysty tekst. Gdy host odpowie, a wyzwanie powiedzie się, klient zaszyfruje żądanie HTTP za pomocą rzeczywistego adresu URL (tj. czegokolwiek po trzecim ukośniku) i wyśle je do serwera.

Istnieje kilka sposobów na złamanie tego zabezpieczenia.

Możliwe jest skonfigurowanie proxy jako "człowiek w środku". Zasadniczo przeglądarka wysyła żądanie połączenia z rzeczywistym serwerem do Pełnomocnik. Jeśli serwer proxy jest skonfigurowany w ten sposób, połączy się przez SSL z prawdziwym serwerem, ale przeglądarka nadal będzie rozmawiać z serwerem proxy. Jeśli więc atakujący może uzyskać dostęp do serwera proxy, może zobaczyć wszystkie przepływające przez niego dane w wyraźnym tekście.

Twoje żądania będą również widoczne w historii przeglądarki. Użytkownicy mogą pokusić się o dodanie zakładek do strony. Niektórzy użytkownicy mają zainstalowane narzędzia do synchronizacji zakładek, więc hasło może skończyć się na deli.ci.us albo w innym miejscu.

Wreszcie ktoś może włamał się do komputera i zainstalował rejestrator klawiatury lub skrobak ekranu(i wiele wirusów typu koni trojańskich). Ponieważ hasło jest widoczne bezpośrednio na ekranie (w przeciwieństwie do " * " w oknie dialogowym hasła), jest to kolejna luka bezpieczeństwa.

Wniosek: jeśli chodzi o bezpieczeństwo, zawsze polegaj na utartej ścieżce. Jest zbyt wiele rzeczy, o których nie wiesz, o których nie pomyślisz i które skręcą ci kark.

Tak, dopóki nikt nie patrzy ci przez ramię na monitor.

Nie zgadzam się z twierdzeniem o [...] Wyciek http referrer (zewnętrzny obraz na stronie docelowej może wyciekać hasło) w odpowiedzi Slougha .

HTTP 1.1 RFC jawnie stwierdza :

Klienci nie powinni zawierać Referera pole nagłówka w (niezabezpieczonym) HTTP wniosek, jeżeli strona odsyłająca była przesłane bezpiecznym protokołem.

W każdym razie, logi serwera i historia przeglądarki to więcej niż wystarczające powody nie umieszczać poufnych danych w łańcuchu zapytania.

Tak, od momentu ustanowienia połączenia HTTPS wszystko jest bezpieczne. Ciąg zapytania (GET) jako POST jest wysyłany przez SSL.

Możesz wysłać hasło jako MD5 hash param z dodatkiem soli. Porównaj go po stronie serwera dla auth.