Frage:
Warum ist die Übergabe der Sitzungs-ID als URL-Parameter unsicher?
Jonathan Egerton
2012-04-23 23:37:22 UTC
view on stackexchange narkive permalink

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 die Übergabe 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)?

Fünf antworten:
Charles
2012-04-24 00:03:30 UTC
view on stackexchange narkive permalink

Ist die Übergabe der Sitzungs-ID als URL-Parameter wirklich unsicher?

Obwohl sie nicht inhärent unsicher ist, kann dies ein Problem sein, es sei denn, der Code ist sehr gut gestaltet.

Nehmen wir an, 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 &, ​​füge die URL in eine Sofortnachricht an meinen Freund ein.

Es sei denn, die Anwendung hat Schritte unternommen, um sicherzustellen, dass eine Validierungsform aktiviert ist Die Sitzungs-ID, der Freund, der auf diesen Link geklickt hat, erbt möglicherweise meine Sitzung und kann dann alles tun, was ich als ich tun kann.

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

Es gibt eine Variation dieses Themas mit dem Namen Sitzungsfixierung, bei der absichtlich eine Sitzungskennung für freigegeben wird böswillige Zwecke. Der verlinkte Wikipedia-Artikel befasst sich ausführlich mit der Funktionsweise dieses Angriffs und dem Unterschied zur unbeabsichtigten Freigabe der Sitzungskennung.

Warum sind Cookies sicherer? P. >

Cookies können hier sicherer sein, da normale Benutzer & nicht einfügen oder sogar anzeigen und ändern können. Sie sind eine viel sicherere Standardeinstellung.

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

Keine 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.

Beachten Sie auch, dass Cookies auf der Festplatte gespeichert werden und weitaus mehr Spuren hinterlassen.
@ewanm89 und URLs werden im Browserverlauf (und in den Lesezeichen) gespeichert.
Und natürlich ist beides nicht der Fall, wenn Ihr Browser so konfiguriert ist, dass er entweder keine Historie / Cookies speichert oder in einem Datenschutzmodus ausgeführt wird. Dies verhindert jedoch nicht, dass MitM-Angriffe über unverschlüsselte Kanäle ausgeführt werden, und ist nur ein geringfügiges Hindernis für Spionage oder an den Browser angeschlossene Malware, die ohnehin nicht ausspioniert werden kann.
-1 Sie haben die Sitzungsfixierung nicht erwähnt.
@ratchetfreak hängt von anderen Einstellungen ab. Vielleicht landet ein Cookie zumindest für die Sitzung immer auf der Festplatte.
@Rook, Ich bevorzuge konstruktives Feedback gegenüber Abstimmungen. Ich habe einen Verweis auf Angriffe zur Sitzungsfixierung hinzugefügt.
Ok, ich bin mit diesem Beitrag im Allgemeinen nicht einverstanden. Wen interessiert es, wenn reguläre Benutzer es ändern? Es gibt echte Angriffe, die durch das Weitergeben des Cookies mit GET aufgedeckt werden. Niemand sollte diese Methode verwenden. Dieser Beitrag ist nur irreführend.
Sie können gerne Ihre eigene Antwort geben, wenn Ihnen meine fehlt. Ich spreche aus umfangreicher Erfahrung in der realen Welt, nicht nur aus rein sicherheitsorientierter Sicht. Bei der Unterstützung von Anwendungen, die entwickelt wurden, bevor die Entwickler die Auswirkungen solcher Dinge verstanden haben, war das * versehentliche * Übergeben von Sitzungskennungen weitaus sichtbarer und weitaus problematischer als der tatsächliche Angriffsvektor. Jetzt, da es sich um einen Angriffsvektor handelt, müssen Schritte unternommen werden, um ihn zu mildern.
Es sind nicht nur Benutzer hinter Unternehmens-Proxys, die IP-Adressen ändern.Ein häufigeres Szenario ist heutzutage, dass mobile Benutzer WLAN-Netzwerke wechseln oder zwischen Mobilfunkdaten und WLAN wechseln.
martinstoeckli
2012-04-24 00:50:17 UTC
view on stackexchange narkive permalink

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 Probleme der Aufrechterhaltung der Sitzung und der Authentifizierung sind häufig miteinander verbunden.

Ein Problem besteht darin, dass es einfach ist, Sitzungsfixierung -Angriffe durchzuführen. In diesem Fall würde ein Angreifer dem Benutzer eine vorbereitete URL mit einer bekannten Sitzungs-ID senden. 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 Website mit HTTPS gemischtes HTTP verwendet, wird die ID für alle HTTP-Anforderungen im Klartext in der URL übertragen (auch für eine Bildanfrage). 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 besteht darin, 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.

bobince
2012-04-24 18:33:13 UTC
view on stackexchange narkive permalink

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 zur Sitzungsfixierung, führen dazu, dass Session-in-URL heutzutage normalerweise vermieden wird.

"aus der Brute-Force-Geschichte schnüffeln _" wie?
Am wichtigsten ist gutes altes CSS: Besuch des Linkverlaufs. Es gab andere Probleme mit Leckagen in der Vergangenheit (z. B. Timing-Angriffe), die jedoch viel schwieriger durchzuführen sind.
Niels Basjes
2012-04-30 23:58:51 UTC
view on stackexchange narkive permalink

Ich habe vor einigen Jahren 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 also eine schlechte Idee, eine Sitzungs-ID in die URL einzufügen.

LongTime
2018-03-15 07:52:12 UTC
view on stackexchange narkive permalink

Die Sitzungs-ID erhöht die Sicherheit, wenn bereits Cookies verwendet werden. Stellen Sie sich vor, es gibt einen Link, über den Geld von Ihrer Bank überwiesen wird:

https://mybank.com/transferMoney?sum=10000&destAccount=someAccount

Wenn Sie sich nur auf Cookies verlassen, können Sie diesen Link in einer betrügerischen E-Mail erhalten. Wenn Sie es öffnen und auf diesen Link klicken, ist es tatsächlich funktionsfähig, da Sie ein Cookie in Ihrem Browser haben. Sie werden erfolgreich (und unabsichtlich) Geld von Ihrem Konto auf ein anderes Konto überweisen.

Wenn der Link wie folgt lautet:

https://mybank.com/transferMoney?sum = 10000&destAccount = someAccount&sessionId = jow8082345hnfn9234

Dann konnte ein böswilliger Betrüger Ihnen die E-Mail wie oben nicht senden, da das Erraten Ihrer aktuellen Sitzungs-ID nahezu unmöglich ist.

Die Frage ist * warum ist es unsicher *?.Sie scheinen zu antworten * warum ist es sicher *?


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...