session_id() und Sicherheit

[Marko]

Hallo Forum,

ich gehe doch richtig in der Annahme, dass die Session ID in PHP nicht von aussen manipuliert werden kann, oder ?

Hintergrund: die Session ID kommt in einem Aufruf eines externen Programms zum Einsatz. Eigentlich wird sie ja vom Client übermittelt, aber PHP sollte ja dafür sorgen, dass nur eine gültige von PHP selbst vergebene Session ID akzeptiert wird. Ich benötige also keine zusätzlichen Massnahmen (z.B. Check mit Regular Expression) an dieser Stelle, Richtig ?

Gruss

Marko

[Sven Rautenberg]

Moin!

ich gehe doch richtig in der Annahme, dass die Session ID in PHP nicht von aussen manipuliert werden kann, oder ?

Falsch. PHP nimmt grundsätzlich alles entgegen, was ein String ist und als Session-ID brauchbar scheint. Es ist nicht notwendig, dass die Session-ID die Hex-Darstellung des 128-Bit-MD5-Wertes ist, auch Session-IDs wie "hasilein" funktionieren.

Insofern solltest du darauf hinarbeiten, dass der externe Programmaufruf sowohl "eigenartige" Session-IDs verarbeitet - im gegenteiligen Fall müßtest du an dieser Stelle filtern - und dass es zu keiner Code-Injection kommen kann (passendes Escaping des Strings notwendig - das aber sowieso unabhängig von der möglichen Session-ID).

- Sven Rautenberg

[wahsaga]

hi,

Falsch. PHP nimmt grundsätzlich alles entgegen, was ein String ist und als Session-ID brauchbar scheint.

Und was nicht "brauchbar" erscheint, erzeugt beim session_start() Warnungen in etwa á la:

Warning: session_start(): The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in [...]
Warning: Unknown: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in Unknown on line 0
Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (...) in Unknown on line 0

Dass kein Session-Cookie mehr gesetzt werden konnte, weil obige Meldungen bereits die Header ausgelöst haben, kommt ggf. noch dazu.

PHP prüft also, wie Sven ja auch schon andeutete, erst mal selber - aber im Zweifelsfalle würde ich mich da nicht drauf verlassen, und lieber selber noch mal einen Check vorschalten.

gruß,
wahsaga

[Cheatah]

Hi,

ich gehe doch richtig in der Annahme, dass die Session ID in PHP nicht von aussen manipuliert werden kann, oder ?

*jede* Information, die von einem Client kommt, kann manipuliert sein. Die Frage ist, was mit einer solchen Manipulation erreicht werden kann.

Hintergrund: die Session ID kommt in einem Aufruf eines externen Programms zum Einsatz.

Was kann hier passieren, und wann bzw. basierend auf welchen Erkenntnissen wird die Übergabe durch PHP oder ein anderes System entschieden?

Cheatah

[fanelf.de]

session_id und sicherheit: was hat das gemeinsam???

da http zustandslos ist, ist jeder request eine in sich abgeschlossene sache. möchte man aber eine folge von requests als eine geschlossene transaktion haben, benötigt der server eine wiedererkennung des clients. dies ist der zweck einer session_id.

daher muß der client diese kennung (session_id) bei jedem request mitschicken, damit der server den client wiedererkennt. diese kennung erzeugt der server und schickt sie in jedem fall zumindest bei dem 1. request mit an den client. damit erübrigt sich die frage, ob diese von außen manipuliert werden kann.

schickt ein client eine kennung welche der server nicht vergeben hat, kann natürlich auch keine wiedererkennung erfolgen.

schicken mehrere clients die gleiche kennung kann der server die clients nicht unterscheiden. daher ist es wichtig eindeutige kennungen zu erzeugen. sonst entsteht ein durcheinander.

im ergebnis soll die kennung eine stateful http verbindung ermöglichen. dies hat mit den daten der session nichts zu tun. diese müssen auf dem server vorgehalten werden.

was hat die wiedererkennung des clients aber nun mit sicherheit zu tun ????

stellt der client nun seine arbeit ein (weil der benutzer nach hause geht, oder der pc abstürzt) bekommt der server davon nichts mit.
startet nun ein anderer client einen request mit der kennung, glaubt der server mit dem abgestürzten client zu kommunizieren. daher ist es wichtig eine abmeldeprozedur zu haben welche die kennung als nicht mehr benutzt deklariert. sonst könnte ein mißbrauch stattfinden.

es hindert aber auch nichts daran, neben der kennung zusätzlich ein passwort bei jedem request mitzuschicken. dann ist die kennung allein wertlos.

[Sven Rautenberg]

Moin!

schickt ein client eine kennung welche der server nicht vergeben hat, kann natürlich auch keine wiedererkennung erfolgen.

Der Sessionmechanismus arbeitet aber anders. Jede vom Client gesendete Session-ID, die keine unerlaubten Zeichen enthält, wird umgesetzt in einen Zugriff auf die zwischengespeicherte Session-Datei, welche dann u.U. neu angelegt wird und ein leeres $_SESSION zur Folge hat. Jeder weitere Zugriff mit dieser frei gewählten Session-ID hat Wiedererkennung zur Folge.

- Sven Rautenberg

[fanelf.de]

Der Sessionmechanismus arbeitet aber anders. Jede vom Client gesendete Session-ID, die keine unerlaubten Zeichen enthält, wird umgesetzt in einen Zugriff auf die zwischengespeicherte Session-Datei, welche dann u.U. neu angelegt wird und ein leeres $_SESSION zur Folge hat. Jeder weitere Zugriff mit dieser frei gewählten Session-ID hat Wiedererkennung zur Folge.

sessionmechanismus ?????

neu angelegt ist keine wiedererkennung! daher gibt auch keine datei!

wiedererkennung setzt eine solche datei nicht voraus.

sollen sessiondaten wiederhergestellt werden, hat dies nichts mit wiedererkennung zu tun.

der interpreter versucht aus einer gleichnamigen datei variablen wiederherzustellen und bei schluß des scriptes in eine solche zu schreiben. gibts diese datei nicht, wird diese erzeugt. egal wann.

[wahsaga]

hi,

sessionmechanismus ?????

Wir reden hier über den _Mechanismus_, über den PHP _Sessions_ bereits implementiert hat, und seine Standard-Funktionsweisen.

Worüber redest du?
(Ja, ich weiß - über das Konzept einer "Session" allgemein. Nur wozu? Danach gefragt war eigentlich nicht.)

neu angelegt ist keine wiedererkennung! daher gibt auch keine datei!

wiedererkennung setzt eine solche datei nicht voraus.

Nein, vom allgemeinen Konzept der "Session" her nicht.

Von der Standardumsetzung in PHP, die die Session-Daten aber in Session-Dateien ablegt, die über die Session-ID identifiziert werden, schon.

sollen sessiondaten wiederhergestellt werden, hat dies nichts mit wiedererkennung zu tun.

Ach nein?
Wie stellst du denn etwas wieder her, das du nicht identifizieren kannst?

der interpreter versucht aus einer gleichnamigen datei variablen wiederherzustellen und bei schluß des scriptes in eine solche zu schreiben. gibts diese datei nicht, wird diese erzeugt. egal wann.

OK, dann besteht über die Funktion von einer Standard-Session in PHP ja Einigkeit.

Nur, was willst du uns dann eigentlich mitteilen?

Gefragt war, welche Gefahr eine manipulierte Session-ID darstellen kann - und in welchem Umfeld war auch genau definiert, nämlich PHP.

Nun, wenn PHP automatisch versucht, auf eine zur ID passende Datei zuzugreifen oder sie gar anzulegen, dann könnte eine manipulierte Session-ID, die beispielsweise '/../irgendwas' enthält, potentiell gefährlich sein - eventueller Wechsel aus dem definierten Temp-Verzeichnis für Session-Dateien heraus, in übergeordnete, etc.

Dass PHP dies aber zu unterbinden versucht, in dem es die vom Client übergeben Session-ID auf "unerlaubte" Zeichen prüft, haben wir ebenfalls bereits festgestellt.

gruß,
wahsaga

[Marko]

Also mal vielen Dank für die hilfreichen Antworten. Wie der Sessionmechanismus an sich funktioniert war mir ja durchaus klar :-) Ich hätte allerdings auch spontan angenommen dass PHP eine vorher unbekannte Session ID zurückweist. Da aber glücklicherweise nur ungefährliche Zeichen akzeptiert werden bin ich dann aber doch ganz beruhigt.

Gruss

Marko