Meine Herren!

@bubble: Auf solche unsauberen Hacks mit IP-Adressen würde ich mich nicht einlassen.

Bevor ich gefragt hab, dachte ich das einer der beiden Wege der Richtige sei. Mittlerweile vertrau ich keinem von beidem so wirklich.

Die Schuld liegt auch ein bischen bei mir. Ich denke gerade drei Schritte weit und schreibe davon nur Schritt zwei auf. Ich versuche es mal langsamer:

Also, wenn du mit Sessions hantierst, besteht natürlich immer das potenzielle Risiko, dass ein Angreifer die Sitzung eines Opfers übernimmt (Session-Hijacking) oder dass ein Angreifer einem fremden Nutzer eine Sitzung unterjubelt (Session-Fixation). Das ist ein Risiko, das ohne Sitzungen nicht auftritt, aber das macht Sitzungen nicht automatisch zu einer Bedrohung. Umgekehrt ist eine Seite ohne Sitzungen übrigens auch nicht automatisch „sicher“, was man immer man sich darunter vorstellen mag. Aber es müssen natürlich Vorkehrungen getroffen werden.

Die Session-ID ist aus kryptographischer Sicht ein »Geheimnis«, das sich Server und Client teilen und worüber sie sich identifizieren. Geheimnis ist in der Kryptographie tatsächlich ein sehr bedeutungsschwangerer Terminus, aber dass es _geheim_ gehalten werden sollte, sagt uns auch der gesunde Menschenverstand.

Wenn wir das Geheimnis also an den URL kleben, müssen wir dafür sorgen, dass dieser ebenfalls geheim bleibt. Falls wir das Geheimnis im Cookie speichern, müssen wir eben zusehen, dass der Cookie geheim bleibt. Der URL steht i.A. in der Adresszeile des Nutzers und der naive Nutzer kann überhaupt nicht wissen, dass wir da putze lustig sicherheitskritische Daten speichern. Der Cookie ist vor einer solchen „Fehl“-Bedienung durch den Nutzer wesentlich unanfälliger. Wann teilt man schon mal einen Mitschnitt seines HTTP-Netzwerk-Verkehrs oder seine Cookies-Dateien?

Nun gehen wir davon aus, dass der Nutzer selbst keine Gefahr für sich selbst mehr darstellt. Aber was ist, wenn es einem Angreifer gelingt, sich irgendwo in der Verbindung zwischen Client und Server einzuhängen und mitzuhören, was die sich so zu sagen haben? In dem Fall spielt es keine Rolle, ob die Session-ID im Cookie oder URL transportiert wird, der Angreifer kann sie lesen. Die Lösung ist so simpel wie effektiv: Man verschlüsselt die Verbindung. Das kann zum Beispiel mit HTTPS geschehen. Aber HTTPS kann auch mehr, es kann über Server-Zertifikate, die oft von einer dritten unabhängigen Partei ausgestellt werden, dem Client eine gewisse Garantie geben, dass es wirklich der Server ist, mit dem er reden möchte. Der umgekehrte Weg kann auch gegangen werden, dann spricht man analog von Client-Zertifikaten.

Interessant ist nun, dass wir eine Session-ID direkt mit einem Client, der sich zertifiziert! hat, in Verbindung bringen können. In diesem Fall haben wir tatsächlich eine verlässliche Methode, um die Sitzung einem Client zuzuordnen und haben damit eine viel stärkere Identifizierungsmöglichkeit als über die Session-ID alleine. Theoretisch können wir nun die Session-ID auch über den URL transportieren, weil unser Server nur noch das Tupel aus Session-ID und zertifiziertem Client toleriert (natürlich nicht automatisch, dass muss unsere Anwendungsschicht implementieren). Client-Zertifikate sind leider ein selten genutztes Feature und erfordern manuelle Installtions-Schritte des Nutzers, die nicht ganz einfach sind.