PHP Session-IDs. Grundsätzliche und sicherheitsrelevante Fragen

[Duftox]

Ich weiß, ich könnte mir das vermutlich auch alles selbst irgendwo anlesen und habe daher Verständnis, wenn Ihr meine Fragen mit Missachtung strafen würdet. Ich versuche es mir aber trotzdem einmal einfach zu machen und lade meine Fragen hier einfach ab ;-)

Es geht um Session-IDs. Meinem Verständnis nach ist dies eine Funktion von z.B. PHP, die bewirkt, dass jeder Client eine eindeutige ID zugewiesen bekommt und alle Variablen-Werte über diese ID irgendwo in einer Datei oder evtl. auch einer Datenbank-Tabelle abgespeichert werden, sodass der PHP-Entwickler sich um nichts kümmern muss und bei einem Server-Request des Clients sofort wieder alle Werte parat hat, richtig? Also welcher User angemeldet ist usw...

Meinstens wird diese Session-ID doch mit GET im Link übertragen, oder? Also Klartext!?

Wäre es denn hierbei nicht für subversive Subjekte relativ einfach, eine Session-ID aus irgendeinem Link einfach abzufischen und unter dieser Session-ID dann einfach weiter zu arbeiten, bzw. Daten zu klauen, manipulieren, löschen, etc.?

Danke im Voraus,
Duftox

[Christian Marquardt]

"Meinstens wird diese Session-ID doch mit GET im Link übertragen, oder? Also Klartext!?" -> Nur wenn keine Cookies erlaubt sind und im Server URLRewriting aktiviert ist. Weitere Themen für dich: HTTPS, Cookiehandling, Sitzungscookie, Session-IDs Man in the Middle, Browsersicherheit.

[Falk Prüfer]

Hallo,

...Meinstens wird diese Session-ID doch mit GET im Link übertragen, oder? Also Klartext!?

Wie Christian schon sagte ist es der üblichere Weg die Session-ID in einem Cookie, also dem HTTP-Header zu übermitteln. Auch wenn Cookies einen schlechten Ruf haben, hier tragen sie üblicherweise zu mehr Transparenz und Sicherheit bei.

... Wäre es denn hierbei nicht für subversive Subjekte relativ einfach, eine Session-ID aus irgendeinem Link einfach abzufischen und unter dieser Session-ID dann einfach weiter zu arbeiten, bzw. Daten zu klauen, manipulieren, löschen, etc.?

Viel wahrscheinlicher ist eigentlich, dass Nutzer einfach einen Link kopieren und per Mail an Andere verschicken oder das natürlich auch eine Suchmaschine Links mit Session-ID angeboten bekommt und diese dann öffentlich für Alle und Jeden zugänglich sind. (Mal abgesehen davon, dass die Suma im Laufe der Zeit eine Menge Links zu ein- und derselben Seite - mit unterschiedlicher Session-ID - sammelt und dann ggfs. als doppelten Content wertet)

Gruß Falk

[Duftox]

Und schon wieder bekomme ich wertvolle Anregungen von Euch. Das wird ja schon innerhalb von zwei Tagen zur regelrechten Gewohnheit Euch Danke zu sagen ;-) Sobald ich etwas mehr Zeit habe, werde ich mich mit den genannten Stichworten mal ein bisschen auf die Suche machen. Eine Sache aber doch noch:

Viel wahrscheinlicher ist eigentlich, dass Nutzer einfach einen Link kopieren und per Mail an Andere verschicken oder das natürlich auch eine Suchmaschine Links mit Session-ID angeboten bekommt und diese dann öffentlich für Alle und Jeden zugänglich sind. (Mal abgesehen davon, dass die Suma im Laufe der Zeit eine Menge Links zu ein- und derselben Seite - mit unterschiedlicher Session-ID - sammelt und dann ggfs. als doppelten Content wertet)

Die hier geschilderten Fälle sind zwar durchaus ernst zu nehmen, aber doch nicht wirklich ein Sicherheits-Risiko, oder? Wenn ich einen Link mit einer Session-ID verschicke, dann wird der Empfänger ja wahrscheinlich nicht gleich meine Daten wegputzen. Und auch wenn eine Suchmaschine eine Session-ID irgendwo darstellt, dann ist das zwar äußerst unschön, sollte aber auch keine Tragödie sein, da diese sicher schon seit Tagen oder Wochen timed-out ist?

Ihr habt mir zwar nun erklärt, dass es viel bessere Möglichkeiten gibt, Session-IDs zu übertragen, Cookies, Post-Methode usw. aber wenn sie denn nun mal im Link drinsteht, ist das nun als riesiges Sicherheits-Risiko zu werten oder nicht? Ich stelle mir das so vor, dass ein Hacker einfach auf gut Glück irgendwelche Datenströme durchscannt und dabei automatisch web-adressen mit Session-IDs rausfiltert. Das sollte ja nicht so schwer sein? Dann könnte er doch ohne Probleme die Session kapern, oder nicht?

Viele Grüße
Duftox

[Christian Marquardt]

Beschäftige dich damit, wie das Internet funktioniert. Dann sind solche Aussagen wie "auf gut Glück irgendwelche Datenströme durchscannt" nicht nötig. Und wenn "es nicht so schwer" ist, dann teste es doch einfach mal aus...

[Falk Prüfer]

Hallo,

...Die hier geschilderten Fälle sind zwar durchaus ernst zu nehmen, aber doch nicht wirklich ein Sicherheits-Risiko, oder? Wenn ich einen Link mit einer Session-ID verschicke, dann wird der Empfänger ja wahrscheinlich nicht gleich meine Daten wegputzen.

Wenn Nutzer A in einem Shop eingeloggt ist, eine günstige CD sieht und seinem Kumpel per IM den Link (mit Session-ID) zu dieser CD schickt, dann kann der Kumpel die CD und (noch mehr Sachen) auf Namen und Rechnung von Nutzer A kaufen, da er in der gleichen Session arbeitet.

...Und auch wenn eine Suchmaschine eine Session-ID irgendwo darstellt, dann ist das zwar äußerst unschön, sollte aber auch keine Tragödie sein, da diese sicher schon seit Tagen oder Wochen timed-out ist?

Wenn dann jeder, der auf einen solchen Link klickt, eine "Ihre Sitzung ist abgelaufen!"-Meldung bekommt, statt der erhofften Infos aus der Suche, dann ist das zwar kein Sicherheitsrisiko, aber der Usability und Akzeptanz der Seite sicherlich nicht zuträglich.

...aber wenn sie denn nun mal im Link drinsteht, ist das nun als riesiges Sicherheits-Risiko zu werten oder nicht?

Ob nun Sicherheit eine Rolle spielt oder nicht, Session-IDs gehören NICHT in die URL.

...Ich stelle mir das so vor, dass ein Hacker einfach auf gut Glück irgendwelche Datenströme durchscannt und dabei automatisch web-adressen mit Session-IDs rausfiltert. Das sollte ja nicht so schwer sein? Dann könnte er doch ohne Probleme die Session kapern, oder nicht?

Wenn ein Hacker in der Lage ist, die Datenströme zwischen einem Client und dem Server abzuhören, dann ist es völlig egal ob die Session-ID in der URL steht oder im HTTP-Header (Cookie, POST) übertragen wird. Hier hilft dann nur Verschlüsselung (https).

Gruß Falk

[Duftox]

Hallo Christian, Falk,

Beschäftige dich damit, wie das Internet funktioniert. Dann sind solche Aussagen wie "auf gut Glück irgendwelche Datenströme durchscannt" nicht nötig. Und wenn "es nicht so schwer" ist, dann teste es doch einfach mal aus...

Nun ja, das liegt in der Natur der Sache, dass man keine dummen Fragen mehr stellen oder falsche Annahmen mehr treffen muss, wenn man einen Sachverhalt sehr gut beherrscht. Ich habe mir halt vorgestellt, dass es nicht soooo schwer sein kann, Datenströme zu scannen und www-adressen heraus zu filtern. Wenn Ihr mir sagt, dass das anders ist, dann war meine Annahme offensichtlich falsch und ich habe wieder etwas dazu gelernt. Ist doch super.

Ob nun Sicherheit eine Rolle spielt oder nicht, Session-IDs gehören NICHT in die URL.

Das habe ich auf jeden Fall jetzt verstanden und bei nächster Gelegenheit sehe ich zu, dass die bei mir aus den Links verschwinden. Wobei ich das selbst von professionellen Produkten so kenne, z.B. PHPmyAdmin. Warum machen die das? Kann man das einfach als 'unprofessionell' abtun, oder gibt es doch irgendwelche Gründe oder Situationen, wann es sinnvoll ist?

Wenn ein Hacker in der Lage ist, die Datenströme zwischen einem Client und dem Server abzuhören, dann ist es völlig egal ob die Session-ID in der URL steht oder im HTTP-Header (Cookie, POST) übertragen wird. Hier hilft dann nur Verschlüsselung (https).

Das habe ich vorher eben nicht gewusst, ich dachte, es ist vielleicht einfacher diese Daten aus dem Link zu extrahieren. Aber prinzipiell ist diese Aussage auf jeden Fall einleuchtend.

Viele Grüße
Duftox

[Falk Prüfer]

Hallo,

...Das habe ich auf jeden Fall jetzt verstanden und bei nächster Gelegenheit sehe ich zu, dass die bei mir aus den Links verschwinden. Wobei ich das selbst von professionellen Produkten so kenne, z.B. PHPmyAdmin. Warum machen die das? Kann man das einfach als 'unprofessionell' abtun, oder gibt es doch irgendwelche Gründe oder Situationen, wann es sinnvoll ist?

OK, dann muss ich meine Aussage etwas korrigieren . "Session-IDs gehören NICHT in öffentlich sichtbare URLs." Und auch bei "internen" URLs sollte dann Sorge getragen werden, dass Sessions nicht nach aussen getragen werden können - z.B. durch zusätzliche Überprüfung der IP.

Was du bei phpMyAdmin in der URL siehst, ist übrigens keine Session-ID. Diese steht im Cookie "phpMyAdmin". Was in der URL übertragen wird, sind s.g. Tokens und ein zusätzliches Sicherheitsfeature. Tokens haben eine sehr viel kürzere "Lebenszeit" als normale Session-IDs und sollen den "normalen Ablauf" der Anwendung validieren. Dieses Verfahren wird auch in anderen Bereichen eingesetzt, z.B. beim Versenden von E-Mail, Blog-Einträgen etc. Den Hintergrund könnte man vereinfacht so erklären:
Um aus Sicht der Anwendung eine bestimmte Aktion durchzuführen, muss vorher ein Formular zum Eintragen der Daten angezeigt werden. Allerdings ist es prinzipiell auch immer möglich, die Daten direkt (ohne Formular) durch einen einfachen GET oder POST an das betreffende Script zu schicken. Die App gibt jetzt dem Formular ein zufällig generiertes Token mit und "merkt" sich dieses selbst in einer Session. Bei der jeweiligen Aktion (Datenbankeintrag, Mail verschicken, etc.) wird jetzt geprüft, ob in den Daten auch genau dieses Token enthalten ist - also vorher das Formular abgerufen wurde. Ist das Token nicht da oder falsch, stammt der Aufruf der Aktion NICHT aus dem Formular und wird verweigert. Ist es korrekt, wird die Aktion ausgeführt und das Token aus der Session gelöscht, so dass es nicht ein weiteres Mal verwendet werden kann.
Dieses Token kann man jetzt noch mit einem Timestamp kombinieren. Ist zuviel Zeit zwischen dem Erstellen des Token und seiner Nutzung vergangen, wird es ungültig und die Aktion verweigert, ist zuwenig Zeit vergangen (z.B. viel zu wenig um als Mensch das Formular auszufüllen), dann wird die Aktion ebenfalls verweigert, da hier ggfs. ein Bot am Werk ist. Hmmm.... ich hoffe ich das halbwegs verständlich erklärt.
Solche Tokens MÜSSEN also in der URL stehen und funktionieren nur zusammen mit einer Session, deren ID NICHT in der URL stehen sollte.

Gruß Falk

[Duftox]

Yes Sir, perfekt erklärt. Das ergibt alles Sinn. Vielen Dank!