it-swarm-eu.dev

SSL s GET a POST

Jsem docela nová v zabezpečení, takže odpusť mé základní otázce, ale SSL šifruje POST žádosti, ale nikoli GET požadavky?

Například, pokud mám dvě žádosti

GET: www.mycoolsite.com/index?id=1&type=xyz

POST

site: www.mycoolsite.com/index {Params: id = 1 & type = xyz}

Lze bezpečně předpokládat, že někdo dokáže zachytit celý požadavek GET (ID a typ čtení), ale pokud zachytí POST), uvidí cestu k webu, ale protože prochází SSL, nevidí parametry id a type?

58
TomJ

Nyní je otázkou, víte, jak vypadá požadavek HTTP ?

No, za předpokladu, že ne, tady je příklad jednoho:

GET /test?param1=hello&param2=world HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

Všechny tyto informace jsou zapouzdřeny v rámci přenosu SSL - jak říká laskavý komentář k vaší odpovědi. To znamená:

  • Získané parametry jsou šifrovány.
  • Tělo HTTP (parametry post) jsou šifrovány.

Co není nutně bezpečné:

  • Hostitel, kterého žádáte. Většina webových serverů dnes podporuje Host: something parametry, takže jeden webový server může spravovat více domén na jednom rozhraní a IP adrese. Je zřejmé, že tato záhlaví je šifrováno, ale pokud provozujete provoz mimo https, mělo by být jasné, ke kterým hostitelům se můžete připojit. I když tomu tak není, reverzní DNS vám určitě řekne, co je hostitelem této IP adresy, a pravděpodobně odtud můžete udělat přiměřený odhad.
  • Informace o vašem prohlížeči/klientovi. Každý klient https je bohužel odlišný a jeho proces vyjednávání může potenciálně poskytnout informace o platformě, na které běží, nebo o jaký prohlížeč se jedná. To není v žádném případě konec světa, je to jen fakt, kterému musíme rozumět.

POST požadavky vypadají podobně jako požadavky, kromě toho, že obsahují tělo. Může to vypadat takto:

POST /testpost HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

param1=hello&param2=hello

Samozřejmě existují i ​​komplikovanější varianty, ale v zásadě je to stejně šifrované.

59
user2213

Neviděl jsem to zmínit v ostatních odpovědích, ale obecně byste neměli vkládat tajné informace (hesla) do požadavků GET ani s SSL, ale místo toho použijte POST). Proč? URL s citlivé informace budou obvykle zaznamenány na obou koncích, např. v seznamu historie vašeho prohlížeče (https://www.example.com?user=me&password=MyPassword), stejně jako protokoly na serveru. POST informace (zejména s hesly) se obvykle nezapisují do protokolů webového serveru, ale samozřejmě lze nakonfigurovat tak, aby byly protokolovány - takže je nejlepší nepoužit (nebo používat podobná) hesla na různých webech.

36
dr jimbob

SSL šifruje a zajišťuje autentičnost celého připojení, včetně požadované metody a adresy URL. GET je stejně dobře chráněn jako POST.

Když SSL pracuje tak, jak bylo zamýšleno, může odposlouchávač vidět, jaká IP adresa se připojuje k které IP adrese (a na jakém portu, ale obvykle je to 443), v kolik hodin a kolik. Pokud na stejném počítači existuje více virtuálních hostitelů, útočník nemůže vědět, s kým kontaktujete (avšak odposlouchávač může vidět vaše požadavky DNS těsně před požadavkem HTTPS a provést hodnověrný odhad). Všechny tyto informace jsou také ověřeny: aktivní útočník nemůže hrát man-in-the-middle a měnit data v přenosu.

Věci, které mohou způsobit, že SSL nebude fungovat tak, jak bylo zamýšleno:

  • Zneužití aplikace, kdy jsou některá data náhodně odesílána přes prostý HTTP.
  • Jedna ze vzácných zranitelností v protokolu SSL, jako je nedávná chyba BEAST .
  • Špatná manipulace s certifikátem, která útočníkovi umožňuje předávat serverem, a to buď z důvodu úniku certifikátu serveru, certifikační autority nesprávně doručila certifikát útočníkovi, nebo proto, že klient nekontroluje certifikát serveru správně.
    • V této poznámce nezapomeňte, že SSL, protože se používá po většinu času, ověřuje server, ale ne klienta. Server nemůže o klientovi nic předpokládat.
  • útok na postranní kanál může odhalit některé informace odposlouchávacímu zařízení. Například přesné načasování, ve kterém účastníci odesílají data, může odhalit něco o tom, jak jsou data počítána, a tedy o povaze dat. Útočník také zná velikost každého paketu. Jak to může odhalit, záleží na tom, zda účastníci přijmou preventivní opatření, a na povaze informací. Konverzace v reálném čase je mnohem náchylnější k takové analýze provozu než stahování souboru.

Viz také Jak je možné, že lidé, kteří sledují navázané připojení HTTPS, by nevěděli, jak je dešifrovat? pro určité pozadí.

Stačí přidat ještě jeden malý detail, jak se to dosahuje pomocí HTTP.
Pravděpodobně jste zvědaví (nebo byste měli být, pokud víte, že znáte SSL handshake ), jak je vytvořen kanál SSL, aniž by byl požadavek GET odeslán nezašifrovaný? A co když můj požadavek musí projít proxy - jak je to možné?

HTTP v1.1 představil CONNECT HTTP metodu, která v podstatě odesílá zjednodušený požadavek na server přes proxy, obsahující pouze nejjednodušší hostitelskou URL (bez jakýchkoli dalších parametry, záhlaví nebo tělo). Na základě této žádosti je vytvořen tunel SSL a poté je přes něj odeslán původní požadavek GET (nebo POST).

6
AviD

Dalším bodem, který není uveden, je to, že pokud používáte GET a máte jakýkoli vložený nebo propojený obsah třetích stran (například reklamy na web), pak tento web třetí strany získá úplnou adresu URL (s citlivými parametry parametrů) v záhlaví Odkazující strana.

Tím jsou údaje vystaveny třetím stranám, které by je neměly mít.

4
Rodney

Zdroj: Odpověď na přetečení zásobník

metoda GET je určena pouze pro získávání dat a neměla by mít žádné vedlejší účinky . Ale POST je určen pro tento konkrétní účel: změna dat na straně serveru.

Požadavky GET lze snadno vzdát (viz Padělání požadavků na více stránek ) pouhým umístěním obrázku na stránku, zatímco kování POST požadavky nejsou tak snadné (to je také důvod, proč byste měli povolit pouze autorizované POST žádosti).

4