Czy ciąg zapytania HTTPS jest bezpieczny?

351

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?

Jan
źródło

Odpowiedzi:

452

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.

dr. zło
źródło
4
A co z polecającymi https do https ? Jeśli otrzymuję obraz z witryny innej firmy przy użyciu protokołu https? Czy przeglądarka wyśle ​​cały ciąg zapytania z mojego poprzedniego żądania do serwera zewnętrznego?
Jus12
4
@ Jus12 tak, to nie ma sensu, ale tak to zostało zaprojektowane.
dr. zło
2
Dlaczego więc ta specyfikacja OAuth2 nie jest zalecana do wysyłania wrażliwych danych w parametrach zapytania (w adresie URL)? Mimo, że zawsze zaleca się używanie TLS (HTTPS). Zobacz ostatni punkt w tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.3 CC @volka
gihanchanuka
@ dr.evil Czy mógłbyś wyjaśnić, na czym polega problem, History caches in browserslub dodać odniesienie do ir?
LCJ
1
Aby uzupełnić tę odpowiedź aktualnymi informacjami: securitynewspaper.com/2016/08/01/… (Hack Proxy PAC pozwala na przechwytywanie adresów URL HTTPS)
Tom
78

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.

VolkA
źródło
48

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.

Ruchira Randana
źródło
2
Ale zobacz odpowiedź @dr. zło, ciąg kamieniołomu może skończyć w plikach dziennika i pamięci podręcznej, więc może nie być bezpieczny na serwerze.
zaph 28.03.16
3
Cześć zaph, jeśli chodzi o bezpieczeństwo HTTPS, celem jest bezpieczne przesyłanie danych do serwera, a nikt w środku nie będzie mógł ich obwąchać. Chociaż jest to możliwe i odpowiada na pytanie, naprawdę trudno jest kontrolować, co serwer robi później. Właśnie dlatego wspomniałem, że to nie jest właściwy sposób. Dodając do tego, nigdy nie powinieneś wysyłać swojego hasła od klienta. Zawsze należy haszować go na urządzeniu i wysyłać wartość skrótu na serwer.
Ruchira Randana
Z punktu widzenia bezpieczeństwa wysyłanie poufnych informacji w ciągu kamieniołomu nie jest bezpieczne, najlepiej wysłać je w POST. Również hasło jest generalnie mieszane na serwerze, a nie przez klienta. Stwierdzenie „nigdy nie należy wysłać ur hasło z klientem” stoi w sprzeczności z odpowiedzią: (e.g http://example.com/login?username=alice&password=12345).
zaph 28.03.16
Hashowanie @RuchiraRandana na kliencie nie ma sensu, ponieważ klucz prywatny można następnie łatwo odzyskać z interfejsu użytkownika.
James W
@JamesW ” klucz prywatny można następnie łatwo pobrać z interfejsu użytkownika ” Jaki klucz?
ciekawy,
28

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.

buta
źródło
27
Bezpieczeństwo to coś więcej niż komunikacja między przeglądarką a serwerem
JoeBloggs,
26

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.

Aaron Digulla
źródło
3
„przeglądarka nadal będzie komunikować się z serwerem proxy”, co nie jest do końca prawdą, konieczne będzie przedstawienie przeglądarce ważnego certyfikatu, który serwer proxy może wygenerować tylko wtedy, gdy ma kontrolę nad urzędem certyfikacji, któremu ufa przeglądarka.
Pieter,
11

Tak, o ile nikt nie patrzy przez ramię na monitor.

Ali Afshar
źródło
13
a Twoja przeglądarka nie zapisuje historii :)
Rahul Prasad
10

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.

Arnout
źródło
2
Jest jeszcze takie słowo „powinien”. Czy zaufasz każdej wersji każdej przeglądarki hasłem?
JoeBloggs
1
Jak dokładnie to ma się do GET vs POST? Czy „każda wersja każdej przeglądarki” byłaby bezpieczna, jeśli używasz POST przez HTTPS?
Arnout,
2
Poza tym strona internetowa HTTPS może odzyskiwać obraz zewnętrzny przez HTTPS - w takim przypadku przeglądarka POWINIEN zawierać nagłówek strony odsyłającej, a tym samym odsłonić hasło ...
AviD
3
@Arnout: Proszę przeczytać ten dokument RFC, który mówi, co NIE POWINIEN znaczy: ietf.org/rfc/rfc2119.txt NIE jest to to samo, co NIE MOŻE, więc cytowana część nie jest tak naprawdę istotna, a agenci przeglądarki mogą nadal zawierać odnośnik do HTTP.
Andy,
8

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

Drejc
źródło
-4

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

Amareswar
źródło
11
MD5 nie nadaje się do funkcji skrótu dla haseł.
Sławek
1
Niezależnie od tego, czy jest to skrót, czy zwykły tekst, wysyłanie haseł w ramach parametrów GET jest złą praktyką. Wyjaśnienia znajdują się w najczęściej głosowanej odpowiedzi. Aaaand ... MD5 nie powinien już być nigdzie używany ...
Thomas
Nie nadaje się funkcja mieszania dla haseł ” Jeszcze lepszy niż wysyłanie haseł w postaci zwykłego tekstu do serwera, lol
curiousguy