Get oder Post

[Christian Seiler]

Hallo Reiner,

Wieso denn das? Natürlich wirkt SSL, auf dem Übertragungsweg kann die angeforderte URL von niemand Drittem mitgelesen und ermittelt werden.

Echt? Ich werden die Parameter abgetrennt? Die müssen doch für das Ziel weitergegeben werden, oder? Also, alle Router müssen den URL lesen können. Die Parameter werden anders behandelt?

Wovon redest Du bitte? HTTP funktioniert so: Der Browser löst der Hostnamen im URI auf und verbindet sich dann zu dieser IP-Adresse per TCP (angegebener Port oder Port 80 als Default). Über diese TCP-Verbindung (die jeder auf dem Weg mitlesen kann, per default aber nicht mitgelesen wird!) werden dann HTTP-Requests gesendet, der Form:

------------------- schnipp -----------------------------------------
METHODE /pfad/zur/resource?parameter=wert HTTP/1.1
Host: hostname_des_requests.example
Weitere-Header: bla

Request-Body (bei GET nicht vorhanden, bei POST sind hier die POST-Daten)

------------------- schnapp -----------------------------------------

Kein einziger Router bekommt einen vollen URI mit (außer er würde den Inhalt der Pakete inspizieren, was Router per Default nicht tun), die Router interessieren nur exakt vier Angaben: Quell-IP, Quell-Port, Ziel-IP, Ziel-Port.

HTTPS funktioniert nun so: Der Browser löst den Hostnamen im URI auf und Verbindet sich dann zu dieser IP-Adresser per TCP (angegebener Port oder Port 443 als Default). Über diese TCP-Verbindung wird nun ein TLS/SSL-Handshake durchgeführt und somit ein verschlüsselter, authentifizierter (!) Tunnel zwischen Browser und Server aufgebaut. Über diesen Tunnel wandern dann ganz normale die HTTP-Requests.

Router dazwischen bekommen wieder nur Quell-IP, Quell-Port, Ziel-IP, Ziel-Port mit. Wenn sie bei HTTPS jedoch in die Pakete schauen, sehen sie nur Zeichensalat, ohne den richtigen Schlüssel können sie den Inhalt des Datenstroms nicht entschlüsseln und der HTTP-Request bleibt ihnen komplett verborgen. Um Man-in-the-Middle-Attacken vorzubeugen (der Router klinkt sich in die Kommunikation ein und baut zwei Tunnel auf: einen zwischen Browser und ihm selbst und einen zwischen ihm selbst und dem eigentlichen Server) gibt's bei SSL/TLS Zertifikate, um sein Gegenüber zu verifizieren.

Außer Routern gibt's noch die Frage nach Proxies. Bei unverschlüsselten HTTP-Proxies laufen *alle* Angaben über den Proxy: Der Browser verbindet sich per TCP mit dem Proxy und sendet einen Request à la:

------------------- schnipp -----------------------------------------
METHODE http://hostname:port/pfad/zur/resource?parameter=wert HTTP/1.1
Weitere-Header: bla

Request-Body (bei GET nicht vorhanden, bei POST sind hier die POST-Daten)

------------------- schnapp -----------------------------------------

Der Proxy kann hier also alles mitschneiden. Verwendet man dagegen HTTPS über einen Proxy sendet der Browser folgenden Request:

------------------- schnipp -----------------------------------------
CONNECT hostname:port HTTP/1.1

------------------- schnapp -----------------------------------------

Daraufhin baut der Proxy selbst eine direkte Verbindung zu hostname:port auf und kopiert Daten zwischen den beiden Verbindungen hin- und her. Diese Daten sind dann wieder der SSL/TLS-Handshake + anschließende verschlüsselte Daten. Hier bekommt der Proxy also auch nur Zielhostnamen und Zielport mit, nicht jedoch irgendwas näheres zum Request, der über die Leitung geht. Auch hier kann der Proxy nicht eingreifen und Man-in-the-middle spielen, da hier genauso wie vorher SSL/TLS-Zertifikate überprüft werden können.

GET/POST geben sich also sicherheitstechnisch in _dieser_ Hinsicht nichts. URL-Parameter haben jedoch einen anderen Nachteil: Wenn z.B. in der URL sensitive Daten übermittelt werden (Passwörter, Session-IDs, etc.) und jemand klickt auf einer Seite, die solche Daten in der URL enthält, einen Link an, dann wird die komplette Adresse samt Parametern als Referer an das Link-Ziel übertragen - jemand, der seine Server-Logs beobachtet, könnte damit einiges an Schaden anstellen. Deswegen verwenden diverse Webmail-Dienste Mechanismen, um bei Links eine weitere Seite dazwischenzuschalten, die "sauber" ist und die dann selbst als (harmloser) Referer im Serverlog des verlinkten auftaucht.

Viele Grüße,
Christian