Czy ciąg zapytania HTTPS jest bezpieczny?

Tworzę bezpieczny internetowy interfejs API korzystający z HTTPS; jeśli jednak pozwolę użytkownikom go skonfigurować (w tym wysyłanie hasła) za pomocą ciągu zapytania, czy będzie to również bezpieczne, czy też powinienem to zrobić za pomocą testu POST?

Tak to jest. Ale używanie GET do poufnych danych jest złym pomysłem z kilku powodów:

• Wyciek głównie strony odsyłającej HTTP (obraz zewnętrzny na stronie docelowej może wyciec hasło [1])
• Hasło będzie przechowywane w logach serwera (co jest oczywiście złe)
• Pamięć podręczna historii w przeglądarkach

Dlatego, mimo że Querystring jest zabezpieczony, nie jest zalecane przesyłanie wrażliwych danych przez Querystring.

[1] Chociaż muszę zauważyć, że RFC stwierdza, że ​​przeglądarka nie powinna wysyłać stron odsyłających z HTTPS na HTTP. Ale to nie znaczy, że zły pasek narzędzi przeglądarki innej firmy lub zewnętrzny obraz / flash z witryny HTTPS go nie wycieknie.

Z punktu widzenia „wąchania pakietu sieciowego” żądanie GET jest bezpieczne, ponieważ przeglądarka najpierw ustanowi bezpieczne połączenie, a następnie wyśle ​​żądanie zawierające parametry GET. Ale adresy URL GET będą przechowywane w historii przeglądarki / autouzupełnianiu przeglądarki, co nie jest dobrym miejscem do przechowywania np. Danych hasła. Oczywiście dotyczy to wyłącznie szerszej definicji usługi internetowej, która może uzyskać dostęp do usługi z przeglądarki, jeśli uzyskasz do niego dostęp tylko z niestandardowej aplikacji, nie powinno to stanowić problemu.

Dlatego korzystaj z posta przynajmniej w oknach dialogowych z hasłami. Jak wskazano w linku opublikowanym przez littlegeek, istnieje większe prawdopodobieństwo, że adres GET URL zostanie zapisany w logach serwera.

Tak , ciągi zapytania zostaną zaszyfrowane.

Powodem jest to, że ciągi zapytania 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 nawiązywane jest połączenie SSL, a następnie parametry zapytania (które należą do protokołu HTTP) są wysyłane do serwera.

Podczas nawiązywania połączenia SSL klient wykona kolejno następujące kroki. Załóżmy, że próbujesz zalogować się na stronie o nazwie example.com i chcesz wysłać swoje poświadczenia przy użyciu parametrów zapytania. Twój pełny adres URL może wyglądać następująco:

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

1. Twój klient (np. Przeglądarka / aplikacja mobilna) najpierw rozpozna nazwę domeny example.comna adres IP (124.21.12.31)za pomocą żądania DNS. Podczas sprawdzania tych informacji używane są tylko informacje specyficzne dla domeny, tzn. example.comBędą używane tylko.
2. Teraz twój klient spróbuje połączyć się z serwerem za pomocą adresu IP 124.21.12.31i spróbuje połączyć się z portem 443 (port usługi SSL nie jest domyślnym portem HTTP 80).
3. Teraz serwer at example.comwyśle ​​swoje certyfikaty do twojego klienta.
4. Twój klient zweryfikuje certyfikaty i rozpocznie wymianę współdzielonego tajnego klucza dla twojej sesji.
5. Po pomyślnym ustanowieniu bezpiecznego połączenia tylko wtedy parametry zapytania zostaną wysłane przez bezpieczne połączenie.

Dlatego nie ujawnisz wrażliwych danych. Jednak przesłanie poświadczeń w sesji HTTPS przy użyciu tej metody nie jest najlepszym sposobem. Powinieneś wybrać inne podejście.

Tak. Cały tekst sesji HTTPS jest zabezpieczony przez 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 na powiedzenie bez odpowiedniej kontroli.

SSL najpierw łączy się z hostem, więc nazwa hosta i numer portu są przesyłane jako zwykły tekst. Gdy host zareaguje i wyzwanie się powiedzie, klient zaszyfruje żądanie HTTP za pomocą rzeczywistego adresu URL (tj. Cokolwiek po trzecim ukośniku) i wyśle ​​je na serwer.

Istnieje kilka sposobów na złamanie tego bezpieczeństwa.

Możliwe jest skonfigurowanie serwera proxy, aby działał jako „człowiek pośrodku”. Zasadniczo przeglądarka wysyła żądanie połączenia z prawdziwym serwerem do serwera proxy. Jeśli serwer proxy jest skonfigurowany w ten sposób, będzie łączyć się za pośrednictwem protokołu SSL z prawdziwym serwerem, ale przeglądarka nadal będzie komunikować się z serwerem proxy. Jeśli więc osoba atakująca może uzyskać dostęp do serwera proxy, może zobaczyć wszystkie przepływające przez niego dane w postaci zwykłego tekstu.

Twoje żądania będą również widoczne w historii przeglądarki. Użytkownicy mogą mieć ochotę dodać zakładkę do zakładek. Niektórzy użytkownicy mają zainstalowane narzędzia do synchronizacji zakładek, więc hasło może znaleźć się na deli.ci.us lub w innym miejscu.

Wreszcie ktoś mógł włamać się do komputera i zainstalować program rejestrujący klawiaturę lub skrobak ekranu (i robi to wiele wirusów typu koń trojański). Ponieważ hasło jest widoczne bezpośrednio na ekranie (w przeciwieństwie do „*” w oknie dialogowym hasła), jest to kolejna dziura w zabezpieczeniach.

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, o ile nikt nie patrzy przez ramię na monitor.

Nie zgadzam się ze stwierdzeniem o [...] wyciekaniu strony odsyłającej HTTP (obraz zewnętrzny na stronie docelowej może wyciec hasło) w odpowiedzi Slougha .

HTTP 1.1 RFC wyraźnie stwierdza :

Klienci NIE POWINNI zawierać pola nagłówka odsyłacza w (niezabezpieczonym) żądaniu HTTP, jeśli strona odsyłająca została przesłana za pomocą bezpiecznego protokołu.

W każdym razie dzienniki serwera i historia przeglądarki to więcej niż wystarczające powody, aby nie umieszczać poufnych danych w ciągu zapytania.

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

Możesz wysłać hasło jako parametr skrótu MD5 z dodatkiem soli. Porównaj to po stronie serwera dla uwierzytelnienia.