Session-ID über GET übergeben

[Dynamite]

Hallo zusammen,
wie unsicher ist es eine Session_ID über den Get-Parameter zu übergeben??? Speichere die ID normalerweise im Cookie, müsste Sie aber für eine AJAX-Funktion in eine ausgelagerte Datei übergeben, da ich sie in dem ausgelagertem Script brauche, Sie aber da nicht vorhanden ist wenn das Script aktualisiert wird. Und ich lese ständig das man die Session_ID möglichst nicht über die URL mitsenden sollte.

Gruß
Dynamite

PS: wusste nicht welches Thema ich wählen sollte, da das ausgelagerte Script auf PHP-basiert, habe ich es mal hier gepostet

[Bernie]

Hi,

kannst du in dem ausgelagerten Script nicht einfach auch eine Session starten?
dann hättest du da auch die Session-ID.

[Dynamite]

Hi,
das geht afaik leider nicht, da das Script ja beim ersten Aufruf der Seite auch eingebunden ist, und "nicht aus dem Fluss ausgelagert" ist. Das heißt ich hätte in einer PHP-Datei zwei gestartete Sessions.

Gruß
Dynamite

[Beat]

Hallo zusammen,
wie unsicher ist es eine Session_ID über den Get-Parameter zu übergeben???

Nicht unsicherer als über POST oder Cookies.
Der einzige Lapsus mit Get ist der User, der seinen Link mit SID in einem frequentierten Forum postet, und es besteht ausser der Abfrage der SID keine weitere Identitätsprüfung.

Als zusätzliche ID Prüfungen könnte ein zusätzlicher Cookie Requestcounter gelten. Ist die Serienummer falsch, ist es der falsche Client.

mfg Beat

[Dynamite]

Als zusätzliche ID Prüfungen könnte ein zusätzlicher Cookie Requestcounter gelten. Ist die Serienummer falsch, ist es der falsche Client.

Hört sich interessant an, aber wie mache ich so einen Cookie Requestcounter ? Hast Du da irgendeinen Link für mich wo man sich zumindestens das Grundprinzip anschauen kann?

Gruß
Dynamite

[Beat]

Als zusätzliche ID Prüfungen könnte ein zusätzlicher Cookie Requestcounter gelten. Ist die Serienummer falsch, ist es der falsche Client.

Hört sich interessant an, aber wie mache ich so einen Cookie Requestcounter ? Hast Du da irgendeinen Link für mich wo man sich zumindestens das Grundprinzip anschauen kann?

Du machst ihn so, wie jeden Cookie, der keine SID ist, in PHP.
ich selbst programmiere in Perl. Da musst du dich also selber schlau machen.

PS: die sicherere Variante eines Requestcounters verlangt, dass er nicht vorhersagbar ist, das heisst, aus Zufallsdaten erstellt wurde und anschliessend mit einer Prüfsummenfunktion behandelt.

mfg Beat

[Dirk Dorweiler]

Hoi.

wie unsicher ist es eine Session_ID über den Get-Parameter zu übergeben???
Nicht unsicherer als über POST oder Cookies.

Einspruch. Ein Möglichkeit wäre: Sagen wir mal, Du hast ne Community und sowas hier:
www.example.org/meinprofil?SESSIONID=XYZ1234

Erlaubt diese Seite nun dem Community Mitlied z.B. externe Links einzustellen, so kann die SESSIONID durch den vom Client womöglich gesendeten referrer im accesslog des Fremdservers auftauchen.

Das lässt sich dann zwar mit weiteren Mechanismen prüfen / verhindern, erhöht aber die Komplexität und damit potentiell die Fehleranfälligkeit.
Insofern möchte ich schon sagen: "Cookie only" ist sicherer... und natürlich für den Benutzer wie auch Suchmaschinen praktikabler, aber das war ja nicht gefragt...

Grüße

[Beat]

wie unsicher ist es eine Session_ID über den Get-Parameter zu übergeben???
Nicht unsicherer als über POST oder Cookies.

Einspruch. Ein Möglichkeit wäre: Sagen wir mal, Du hast ne Community und sowas hier:
www.example.org/meinprofil?SESSIONID=XYZ1234

Erlaubt diese Seite nun dem Community Mitlied z.B. externe Links einzustellen, so kann die SESSIONID durch den vom Client womöglich gesendeten referrer im accesslog des Fremdservers auftauchen.

Das ist richtig. Allerdings gibt es noch mehr Gründe, auf die GET Methode zugunsten der POST Methode zu verzichten. Diese aber erhöhen alle nicht die Sicherheit, sondern verringern nur die Wahrscheinlichkeit dass eine Unsicherheit ausgebeutet werden kann.

Die primäre Unsicherheit, die für alle gilt, ist die sichtbare Datenübertragung. Dem kann man mit SSL entgegenwirken.
Wenn aber SSL keine Option ist, dann muss man man SIDs zusätzlich absichern...

Das lässt sich dann zwar mit weiteren Mechanismen prüfen / verhindern, erhöht aber die Komplexität und damit potentiell die Fehleranfälligkeit.
Insofern möchte ich schon sagen: "Cookie only" ist sicherer... und natürlich für den Benutzer wie auch Suchmaschinen praktikabler, aber das war ja nicht gefragt...

Das problem ist, dass Cookies ein Browser+Domain <-> Server Identifikationsystem darstellen, kein User <-> Server System.
Der Browser sendet alle Cookies an die passende Domain.

Verwende ich SIDs in Links oder Formularen, dann kann ich auf die Useraktion ganz exakt eingehen.

Will man hier das Optimum errreichen, dann braucht man eigentlich eine:
CID (ClientID via Cookies = SID)
RID (RequestID via Content)

Im Optimum lassen sich dadurch Mehrere Sessions gleichzeitig betreiben, Onetime RIDs betreiben (zusätzliche Sicherheit) und die möglichen Lecks via Referer (wie du oben gesagt hast) oder Links in Foren gepostet aushebeln, indem man CID und RID gemeinsam validiert.

Sicherheit geht immer auf Kosten von Komplexität. Es bedarf ein mehrfaches ans Tests. Das ist klar. Aber Cookies alleine sind schlicht nicht für sichere Systeme mit Schreibrechten tauglich.

Und klar: Wer SSL benutzen kann, ist klar im Vorteil.

mfg Beat

[Dynamite]

Hi,
nochmal ne ganz andere Möglichkeit, die mir eingefallen ist:
Ich habe die Session ja in der Datenbank, wenn ich die Session jetzt auch nochmal md5 verschlüsselt in die Datenbank lege und in an das Script den md5 hash schicke und mit dem in der Datenbank vergleiche, dann müsste das doch sicher genug sein, oder?

Gruß
Dynamite

[Beat]

Ich habe die Session ja in der Datenbank, wenn ich die Session jetzt auch nochmal md5 verschlüsselt in die Datenbank lege und in an das Script den md5 hash schicke und mit dem in der Datenbank vergleiche, dann müsste das doch sicher genug sein, oder?

Eine SessionID sollte immer nicht vorhersagbar sein
Das ist quasi Basics.
Also in etwa so etwas:
$SID = sha1_hex( time() . rand() . $ENV{REMOTE_HOST} .'SALTSTRING' );

sha1 oder md5 garantiert keine Unvorhersagbarkeit. Diese wird aus time() . rand() einigermassen hergeleitet.

Aber ansonsten hat das äussere Gesicht der SID wenig mit besonderer Sicherheit zu tun. Hacker können immer vermuten, dass eine SID aufgrund von zu unzufälligen Inputdaten generiert wurde, und entsprechend vorbereitete Checksummen senden.

mfg Beat