Session Re-Loaden

[defabricator]

Zitat von rambi

Sollte dieses einfach so möglich sein, ist das System schlampig programmiert! Man läßt damit sogar die versehendliche Doppelvergabe von SessionIDs zu. Ich weiß, die Wahrscheinlichkeit für einen solche Zufall liegt irgendwo bei 1:16^32, aber Zufall bleibt Zufall.

Hä? Wie schließt Du von Sessionübernahme auf doppelte Id Vergabe? Völlig schleierhaft.

Zitat von rambi

Also, will man Sessions übernehmen können, dann muß das Script schlampig geschrieben worden sein.

Nochmal: Deine Skripte kommen immer an die Daten ran oder werden die nur noch magisch verarbeitet? Das Beispiel ist wie gesagt arg verkürzt, aber ob ich nun session_start(); print_r($_SESSION) oder

da_supermagic_session_starter_function( da_supersecret_password_getter() ); da_supersessiondata_getter();

o.ä. aufrufe, ist doch Jacke wie Hose (für dieses Problem hier).

Zitat von rambi

Sessionübernahmen sollten immer erkannt werden. Zumindest darf ein "Fremder" nicht ohne zusätzliche und hohe Hürden an Sessiondaten nutzen können.

Wer ist denn hier "der Fremde"? Niemand. Nochmal: Es geht um server-seitige Übernahme der Session. Das Skript wird dafür verändert. Wer ändert? Jemand mit der Rolle:Entwickler. Da gibt es keinen "Fremden", nur Skript und Entwickler. Das gilt eingeschränkt sogar, wenn man nicht den Quellcode sondern nur Obfuscatorzeugs oder ein verschlüsseltes Skript hat.

Ok, da scheins ja noch richtig an den Grundlagen/Einstellung zu fehlen.... ;-)

Wer ist denn hier "der Fremde"?

Eine Session ist ein Hilfsmittel um annähernd eine persistente Client-Server Verbindung nachzubilden. Und zwar genau und ausschließlich für eine einzige Client-Server Verbindung. Jeder welcher da von der Seite dran rumfumelt ist automatisch "fremd" und damit eine Gefahr. Und wer die Möglichkeit zuläßt ist d***!!

Wie schließt Du von Sessionübernahme auf doppelte Id Vergabe? Völlig schleierhaft.

Doppelte ID Vergabe kann/wird zu einer versehendlichen Sessionübernahme führen!
Was ist daran nicht zu verstehen?
Bin ich dumm, wenn ich das verhindere? Wenn ja, warum?

Das Skript wird dafür verändert.

Sach ich doch!! Bzw. Ist das eine der dümmsten Ideen die mal haben könnte...
Logging einbauen, das darf das einzige Ästlein sein, auf dem man sich bewegen kann.
Baust du jedoch in ein produktiv Script die Möglichkeit der Sessionübernahme ein, dann ist das prinzipiell auch jedem Besucher möglich!

oder werden die nur noch magisch verarbeitet?

Natürlich!!
Wobei magisch natürlich nur solange gilt, bis man geschnallt hat wie es funktioniert!

[defabricator]

Zitat von rambi

Ok, da scheins ja noch richtig an den Grundlagen/Einstellung zu fehlen.... ;-)

meinerseits definitiv nein.

Zitat von rambi

Eine Session ist ein Hilfsmittel um annähernd eine persistente Client-Server Verbindung nachzubilden. Und zwar genau und ausschließlich für eine einzige Client-Server Verbindung. Jeder welcher da von der Seite dran rumfumelt ist automatisch "fremd" und damit eine Gefahr. Und wer die Möglichkeit zuläßt ist d***!!

Nein. Mein Beispiel übernimmt die Session _server-seitig_ über die genau definierte Schnittstelle. Damit sind wie bei jedem anderen Aufruf von session_start() sowohl die Daten geschützt als auch die Eindeutigkeit der session-id gewährleistet (Du weisst, wie php die session_id erzeugt und kontrolliert?). Oder warum sollte dadurch plötzlich der gesamte Sessionmechanismus von PHP durcheinander geraten?

Zitat von rambi

Doppelte ID Vergabe kann/wird zu einer versehendlichen Sessionübernahme führen!

Ja, würde es. Passiert hier nur einfach nicht.

Zitat von rambi

Was ist daran nicht zu verstehen?
Bin ich dumm, wenn ich das verhindere? Wenn ja, warum?

Du schreibst nur einfach komplett am Thema vorbei, das ist das Problem. Du vermischt anscheinend den Zugriff und die Möglichkeiten von Clients, fremden shared-server Skripten und dem "eigenen" Skript.

Zitat von rambi

Sach ich doch!! Bzw. Ist das eine der dümmsten Ideen die mal haben könnte...

Es ist ein einfache Methode, nachträglich an die Daten zu kommen. Den Beweis, dass es dumm ist, bist Du immer noch schuldig. Vielleicht gibt es bessere, komplexere, durchdachtere usw Methoden. Aber Du sprachst von "böse" und "dumm" und "gefährlich". Sehe ich nicht.

Zitat von rambi

Baust du jedoch in ein produktiv Script die Möglichkeit der Sessionübernahme ein, dann ist das prinzipiell auch jedem Besucher möglich!

Nein, das ist es nicht. Wie gesagt: Du vermischt die Möglichkeiten. Seit wann ist einem Besucher alles möglich, was dem server-seitigen Skript möglich ist?

Zitat von rambi

Natürlich!!
Wobei magisch natürlich nur solange gilt, bis man geschnallt hat wie es funktioniert!

Laber laber.

Papperlapap ..... Laber laber.

Och nöö....
Deine Bockigkeit kann ich in Grenzen verstehen, aber das muß doch nicht sein.

[defabricator]

Och doch. Langsam nervt es mich halt wirklich.
Und "magisch bis man es versteht" ist doch nun wirklich laber laber, reiner Füllstoff ohne wirklich Inhalt.

>>Langsam nervt es mich halt wirklich.
Ärger hilft keinem, weder dir noch mir. Also werde ich mich von diesem Thema verabschieden und hoffe, dass dein Vertrauen in die Sicherheit der PHP Sessionverwaltung nicht irgendwann bitter enttäuscht wird.

[defabricator]

Gut, dann fasse ich die Ergebnisse nocheinmal zusammen.

Serverseitige Sessionübernahme ist kein Problem, auch wenn es bei rechtzeitiger Planung sicher elegantere Möglichkeiten gibt.
Die dabei eingesetzten Methoden haben nichts, aber auch garnichts mit client-seitig ausnutzbaren Lücken zu tun. Serverseitige Sessionübernahme zum Auslesen von Daten ermöglicht es Nutzern in keinster Weise automatisch Sessions zu übernehmen.
Serverseitige Sessionübernahme zum Auslesen von Daten ist nicht gleich benutzerseitige Sessionübernahme. Den selöben Begriff dafür zu verwenden, ist vermutlich ungünstig.
Die Applikation hat Zugriff auf die Daten, so toll sie zwischenzeitlich auch verschlüsselt und codiert sein mögen. Code, der im Kontext der Applikation läuft, hat also zwangsläufig den gleichen Zugriff auf die Daten. Das bedeutet nicht, dass beliebiger Code, insbesondere client-seitiger Code, deshalb Zugriff auf die Daten hat. Das Auslesen der Daten im Context der server-seitigen Applikation bedeutet daher nicht beliebigen Zugriff von irgendwoher auf diese Daten oder gar die Session im Ganzen. Serverseitige Übernahme heißt nicht "beliebiges Handeln mit der Session", insbesondere nicht "beliebieges Handeln von Clientseite her", sondern ermöglicht -genau wie die gesamte Applikation- nur genau das, was durch die Skripte festgelegt wird. Oder in Kurzform: Weder die Session noch die dafür erforderlichen Daten werden dadurch an einen anderen, beliebigen Nutzer transferiert.

[PHP-CODER]

Ich schliesse mich hier absolut der Meinung von defabricator an!

Rambi aus meiner Sicht hast du absulut keine Ahnung über was du eigentlich da redest !
Deine ganze Antworten bauen auf Vorurteile gegenüber PHP sowie total falsche Annahmen.
Zu diesen unvorteilhaften Voraussetzungen gesellt sich noch ein fehlendes Wissen und Können in der PHP Programmierung deinerseits.

Was du in dem Unterforum "PHP für Fortgeschrittenen" verloren hast ist mir echt schleierhaft. Dein Wissen und Können in der PHP programmierung wird es auf jeden fall nicht sein.

Zur Information:
Sessions sind nichts anderes als Serverseitige Cookies die den Vorteil bringen das man wenig bis praktisch gar nichts überprüfen muss was für Werte die Session Variabeln haben.

Grund dafür ist die Tatsache das der Entwickler selbst, also der besitzer des Server welcher die Daten lagert, entscheidet wie die Variabeln in der Session heissen sollen und welche Werte sie schlussendlich annehmen dürfen da alles das auf dem Server abgelegt wird und nicht wie bei einem normallen Cookie auf dem PC des Internetsurfers.

Zur widerholung noch einmal für dich !

Ich als Server Administrator entscheide wie die Variabeln in der aktuellen Session heissen sollen und welche werte sie Annehmen dürfen und sonst kein Anderer.

Aus diesem Grund kann ich diese Daten auch selbst auslesen, löschen oder modifizieren.

Stell dir Vor ich kann ebenfalls den Server vom Netz nehmen oder alles auf dem Server löschen. Wenn das für dich nicht noch mehr BÖSE ist dann weiss ich echt nicht !

Sessions sind Serverseitige Cookies die der entwickler der Seite anlegt um sich kontroll arbeit zu sparen was für Werte der Internet benutzer an die Seite sendet.

Über diese Serverseitige Cookies "Session" hat der entwickler der Seite die Volle Kontrolle.
Er entscheidet wann sie Angelegt werden, was für Namen sie haben, wie lange sie Leben und wann sie gelöscht werden.

Der Internet Benutzer einer Seite hat absolut kein zugriff auf diese Server seitigen
Cookies noch kann er sie beinflussen.

[PHP-CODER]

Zitat von defabricator

PHP-Code:

foreach(glob(ini_get('session.save_path').'/sess_*') as $sf) {
    session_id(substr(basename($sf), 5));
    session_start();
    print_r($_SESSION);
    session_write_close();
} 


Das funktioniert meiner Meinung nach nur wenn vorher nicht schon eine Session gestartet wurde.

Mit einer vorher schon gestarteten Session bewirkt der Code nur das die Daten der ersten Session ausgegeben werden.

Bsp. Code:

PHP-Code:

session_start();
$_SESSION['TEST']="TEST ZEICHENKETTE";
print_r($_SESSION);
foreach(glob(ini_get('session.save_path').'/sess_*') as $sf) {
    session_id(substr(basename($sf), 5));
    session_start();
    print_r($_SESSION);
    session_write_close();
} 


[defabricator]

Ja, ich habe doch geschrieben "arg verkürztes Beispiel".
So wie innerhalb der Schleife müsstest Du auch vor der Schleife die session (die Du für die Authorisierung verwenden kannst) mit session_write_close() beenden und nach der Schleife genau diese Session wieder aufnehmen. Performant ist das jetzt nicht gerade, aber wie häufig im Vergleich zum Regelbetrieb passiert das?
p.s.: Ob man nach dem write_close() noch $_SESSION=array() setzen sollte/muss, kann ich jetzt gerade nicht sagen. Wenn ich raten müsste, dann eher "nicht notwendig". Vielleicht mal ausprobieren.
p.p.s: Mit einem hat Rambi recht: Es gibt sicherlich bessere Methoden, wenn man es rechtzeitig eingeplant hat. Das ist in Deinem Fall nicht (mehr) gegeben.?.
Und ich denke schon, dass er weiss, was Sessions sind. Nur was genau im vorliegenden Fall genau wo gemacht wird, ist wohl etwas durcheinander geraten und hat sich dann wie Scheuklappen vor die (lesenden) Augen gelegt.