it-swarm-eu.dev

Warum ist die Übergabe der Sitzungs-ID als URL-Parameter unsicher?

Ich habe kürzlich eine Diskussion verfolgt, in der eine Person erklärte, dass das Übergeben der Sitzungs-ID als URL-Parameter unsicher ist und stattdessen Cookies verwendet werden sollten. Die andere Person sagte das Gegenteil und argumentierte, dass Paypal beispielsweise aus Sicherheitsgründen die Sitzungs-ID als URL-Parameter übergibt.

Ist das Übergeben der Sitzungs-ID als URL-Parameter wirklich unsicher? Warum sind Cookies sicherer? Welche Möglichkeiten hat ein Angreifer für beide Optionen (Cookies und URL-Parameter)?

59

Ist das Übergeben der Sitzungs-ID als URL-Parameter wirklich unsicher?

Obwohl es nicht von Natur aus unsicher ist, kann es ein Problem sein, es sei denn, der Code ist sehr gut gestaltet.

Angenommen, ich besuche mein Lieblingsforum. Es meldet mich an und hängt meine Sitzungs-ID bei jeder Anfrage an die URL an. Ich finde ein besonders interessantes Thema und kopiere die URL und füge sie in eine Sofortnachricht an meinen Freund ein.

Sofern die Anwendung keine Schritte unternommen hat, um sicherzustellen, dass die Sitzungs-ID einige Validierungsform enthält, erbt der Freund, der auf diesen Link geklickt hat darf meine Sitzung und dann wäre in der Lage, alles zu tun, was ich tun kann, wie ich.

Durch das Speichern von Sitzungskennungen in Cookies können Sie das Problem der Linkfreigabe vollständig beseitigen.

Es gibt eine Variation dieses Themas namens Sitzungsfixierung , die eine Absicht Freigabe einer Sitzungskennung für böswillige Zwecke beinhaltet. Der verlinkte Wikipedia-Artikel beschreibt ausführlich, wie dieser Angriff funktioniert und wie er sich von unbeabsichtigt Freigabe der Sitzungskennung unterscheidet.

Warum sind Cookies sicherer?

Cookies können sind hier sicherer, da sie nicht von normalen Benutzern kopiert und eingefügt oder sogar angezeigt und geändert werden können. Sie sind eine viel sicherere Standardeinstellung.

Welche Möglichkeiten hat ein Angreifer für beide Optionen?

Weder noch dieser Methoden ist vor Man-in-the-Middle-Angriffen über unverschlüsselte Kommunikation geschützt. Browser-Addons, Spyware und andere clientseitige Probleme können auch beide Methoden zum Speichern von Sitzungskennungen ausspionieren.

In beiden Fällen ist die serverseitige Überprüfung, ob der Client, der behauptet, eine Sitzungs-ID zu besitzen, eine bewährte Methode. Woraus diese Validierung besteht, steht zur Debatte. Beachten Sie, dass Benutzer hinter Unternehmens-Proxys zwischen Anforderungen zwischen IP-Adressen wechseln können. Wenn Sie also eine Sitzung an eine IP-Adresse sperren, können Personen versehentlich entfremdet werden. Der Artikel Sitzungsfixierung erwähnt einige andere hilfreiche Alternativen.

76
Charles

Die meisten Websites speichern den Anmeldestatus ihres Benutzers in der Sitzung. Wenn ein Angreifer die Sitzungs-ID hat, verfügt er auch über die Berechtigungen des angemeldeten Benutzers. Mit anderen Worten, die beiden Aspekte der Aufrechterhaltung der Sitzung und der Authentifizierung sind häufig miteinander verbunden.

Ein Problem ist, dass es einfach ist, Sitzungsfixierung Angriffe durchzuführen. In diesem Fall sendet ein Angreifer eine vorbereitete URL mit einer bekannten Sitzungs-ID an den Benutzer. Wenn der Benutzer auf diese URL klickt und sich anmeldet, hat der Angreifer eine Sitzung mit Berechtigungen. Wenn für die Website jedoch ein Cookie erforderlich ist, reicht eine vorbereitete URL in einer E-Mail nicht aus.

Wenn eine Site HTTP gemischt mit HTTPS verwendet, wird die ID in der URL für alle HTTP-Anforderungen (auch für eine Bildanforderung) im Klartext übertragen. Wenn der Angreifer also eine einzelne HTTP-Anforderung lesen kann, nachdem sich der Benutzer angemeldet hat, kennt er die Sitzungs-ID.

Ein Ausweg aus dem Problem wäre, die beiden Probleme zu trennen und die Sitzung und die Authentifizierung beizubehalten. Sie können dann die Sitzungs-ID ungeschützt lassen, nur um die Sitzung aufrechtzuerhalten, und ein separates Cookie verwenden, um den Anmeldestatus zu überprüfen. Dieses Cookie muss so konfiguriert sein, dass es nur an HTTPS-Seiten gesendet wird.

23
martinstoeckli

Zusätzlich zu dem, was Charles und Martin gesagt haben, erhöht das Einfügen von Elementen in die URL die Wahrscheinlichkeit, dass sie auslaufen. Dies kann über einen Referer-Header in einer verknüpften Ressource erfolgen, vom Zugriff auf den Endpunkt mit Browserverlaufsdatensätzen, vom Brute-Force-Verlaufs-Sniffing, unangemessen geschützten Webprotokollen usw. Daher ist es im Allgemeinen nicht ratsam, alles, was Sie geheim halten möchten, in eine URL/Abfragezeichenfolge einzufügen.

Ich habe nicht gesehen, dass Paypal Serversitzungs-IDs in URLs verwendet. Es gibt keine Möglichkeit, dass es wirklich sicherer ist als Cookies. Der Grund, warum dies in der Vergangenheit normalerweise gemacht wurde, war die Unterstützung von Browsern ohne aktivierte Cookies. Dies ist heutzutage immer weniger ein Problem, und die Usability-Probleme, keine Links gemeinsam zu nutzen, zusätzlich zu den Angriffen auf die Sitzungsfixierung, führen dazu, dass Session-in-URL heutzutage normalerweise vermieden wird.

15
bobince

Vor einigen Jahren habe ich gesehen, dass jemand eine URL (WITH sessionid) in Twitter kopiert hat. Alle Follower hatten dann vollen Zugriff auf dieses Personenkonto auf dieser Site.

Ja, es ist eine schlechte Idee, eine Sitzungs-ID in die URL einzufügen.

7
Niels Basjes