Session Re-Loaden

Ob man nach dem write_close() noch $_S...

Nein, das muß nicht!

@PHP-CODER
Mindestens drei mal habe ich es gelesen.... und bin doch etwas verwundert...
Nunja.. dein Vertrauen in die PHP Sessionverwaltung und irgendwelche Admins die du noch nie gesehen hast, halte ich für arg überzogen.
Aber da ich ja keine Ahnung habe......

[defabricator]

Zitat von rambi

Nein, das muß nicht!

Getestet oder schreibst Du das nur aus dem Bauch heraus? Löschen oder Überschreiben session_write_close() und/oder ein erneutes session_start() $_SESSION sicher? Ich nehme es auch an, aber es geht um Gewissheit.
edit: getestet. Ja, session_start() weisst in jedem Fall $_SESSION ein komplett neues array zu, nach session_write_close() stehen die Daten allerdings weiter zur Verfügung.

Zitat von rambi

Nunja.. dein Vertrauen in die PHP Sessionverwaltung und irgendwelche Admins die du noch nie gesehen hast, halte ich für arg überzogen.

Was macht Dich denn so unglaublich mistrauisch der Sessionverwaltung gegenüber? Im Grunde dürftest Du dann Sessions unter PHP doch überhaupt garnicht einsetzen. Tust Du's? Genau was kann Deiner Meinung nach mit der Sessionverwaltung schief gehen? Die doppelte ID Vergabe ist es nicht.
Und was soll die Scheindiskussion um die Anzeige von Sessiondaten? Würde das von Dir vorgeschlagene Logging denn prinzipiell weniger Daten ausspucken?

Natürlich ist das getestet!
Wenn ich mir nicht !00% sicher bin, schreibe ich solche Wörter wie etl., bestimmt, wird wohl, müsste eigendlich ... usw.

Die Sessionverwaltung von PHP ist eigendlich ganz Klasse! Hat allerdings den kleinen Haken, dass man sich als Programierer um die Sicherheit selber kümmern muß. Eingebaute Unterstützung, seitens PHP gibts da so direkt nicht. Sie ist als Basis OK, aber mit der Pflicht sie auszubauen. Eine selbstgebastelte Sessionverwaltung wird immer ähnlich aussehen bzw. dieselbe Grundfunktionalität beinhalten müssen. Dann kann man doch auch die Vorhandene nehmen und etwas aufblasen..

Wie du schon sagst: Die doppelte ID Vergabe ist so selten, dass man sie fast vernachlässigen kann. Aber auch nur fast. Und der Schutz dagegen, fällt bei den zu treffenden Maßnahmen automatisch mit ab. also kein Mehraufwand nötig.

Und ja, ich bin ein gebranntes Kind. Damals war ich noch so blauäugig wie ihr... session_start() an den Anfang und evtl noch für User mit Adminrechten Cookies vorraussetzen. Aus die Laube!
Wie man sich doch täuschen kann!

[defabricator]

Zitat von rambi

Wie du schon sagst: Die doppelte ID Vergabe ist so selten, dass man sie fast vernachlässigen kann. Aber auch nur fast. Und der Schutz dagegen, fällt bei den zu treffenden Maßnahmen automatisch mit ab. also kein Mehraufwand nötig.

Und "der Schutz" wird bei "unserer" Maßnahme nicht verringert. Das hat also einfach nichts mit dem Thema zu tun. Wenn doch, dann belege das bitte. Nicht nur behaupten, belegen.

Zitat von rambi

Und ja, ich bin ein gebranntes Kind. Damals war ich noch so blauäugig wie ihr... session_start() an den Anfang und evtl noch für User mit Adminrechten Cookies vorraussetzen. Aus die Laube!
Wie man sich doch täuschen kann!

Ach ja, damals, zu Kaisers Zeiten. Los jetzt, endlich was handfestest. Was genau passiert schlimmes? Was geht schief? Belege, Argumente, Quellen, Beweise, kein Gossip bitte. Und btw ich kenne php noch aus den 3er Zeiten.

p.s.: Deine Texte lesen sich so, als ob Du immer noch glaubst, mehreren Clients wird "mutwillig" die selbe Session Id übermittelt, um "unser" Vorhaben zu realisieren. Das ist nicht nicht so vorgesehen. Dafür muss man sorgen, dafür kann man sorgen. Die Eindeutigkeit der Client<->Session Id bleibt erhalten, die Ids der übernommenen Sessions werden nicht, ich wieder holte werden nicht an den Client übertragen. Wie bereits auf der ersten Seite deutlich gesagt wurde, geht es nicht um eine Übernahme aus Benutzersicht. Ich bitte das beim Belegen Deiner Bedenken zu berücksichtigen.

[PHP-CODER]

Hallo defabricator !

Zuerst vielen dank für deine äusserst Hilfreichen antworten.
Ich könnte nun mittels dem Befehl "session_write_close" die bestehende Session abschliessen und mit "session_set_id" sowie "session_start" die neue Session laden.

Es funktioniert alles bestens. Vielen dank noch einmal an dir.

Was ich noch fragen würde ist ob vielleicht jemand weiss was es mit den Warnungen auf sich hat.

Jedesmal wenn ich den Code ausführe bekomme ich folgendes zu sehen.
Ich kann die Warnungen abstellen würde jedoch trotzdem wissen ob es eine Möglichkeit gibt diese zu vermeiden.

Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /opt/htdocs/xyz.php:9) in /opt/htdocs/xyz2.php on line 5463

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /opt/htdocs/xyz.php:9) in /opt/htdocs/xyz2.php on line 5463

Was mir ebenfalls noch aufgefallen ist das in dem "PHP-Self" Befehlsverzeichniss die Funktion
"session_write_close()" fehlt.
http://www.selfphp.de/befehlsverzeic...zeichnis_s.php

[PHP-CODER]

Zitat von rambi

Und ja, ich bin ein gebranntes Kind. Damals war ich noch so blauäugig wie ihr... session_start() an den Anfang und evtl noch für User mit Adminrechten Cookies vorraussetzen. Aus die Laube!
Wie man sich doch täuschen kann!

Hallo Rambi !

Ich würde jetzt auch mal gerne ein paar code zeilen sehen aus denen hervorgeht das die Session Verwaltung nicht so sicher ist.

Bis jetzt sehe und lese ich deinerseits nichts anderes als Behauptungen ohne irrgendwelche
Beweise sowie andauernd Vorgefasste Dogmatische Vorurteile gegenüber PHP.

Man könnt dem auch RUFMORD sagen welcher mit ganz grosser wahrscheinlichkeit darauf zurückzuführen ist das du selbst überhaupt nicht in PHP programmieren kannst.

Ich freue mich nun auf ein handfestes Beispiel mit richtigen PHP Code deinerseits der uns allen zeigt das die PHP-Session Verwaltung unsicher ist.

aus denen hervorgeht das die Session Verwaltung nicht so sicher ist.

Ganz sicher werde ich hier kein Sessionhackscript publizeren.....

Da du mir nicht glaubst, hier mal ein paar Artikel zur Sicherheit mit Sessions:
http://www.linux-konkret.de/security...okies-url.html
http://de.wikipedia.org/wiki/Session_Fixation
http://www.cms-sicherheit.de/module-...-1-pid-30.html

Vorgefasste Dogmatische Vorurteile gegenüber PHP.

Etwas dogmatisch, kann schon sein..
Aber keine Vorurteile!! Sondern Urteile!
Und wieso sollte ich was gegen PHP haben??
Die Probleme sind doch völlig unabhängig von der verwendeten Sprache ;-)

[defabricator]

Zitat von PHP-CODER

Es funktioniert alles bestens. Vielen dank noch einmal an dir.

Das tut es noch nicht, da ich bei Dir noch garnicht angelangt bin, sondern eigetnlich erstmal rambi abhandeln wollte ;) Das Beispiel ist nicht gebrauchsfertig.
Die Warnungen, die Du bekommst, rühren daher, dass PHP eben doch noch versucht die id der übernommenen Session an den Client zu propagieren. Würde das klappen, hättest Du in der Tat ein Problem. Das muss also erstmal unterbunden werden.

PHP-Code:

<?php
// Authentifiziereun, Authorisierung
session_start();
if (!isset($_SESSION['privlevel']) || $_SESSION['privlevel']&PRIV_ADMIN==0) {
    die('nur Admins');
}


$original_values = array();
$original_values['session_id'] = session_id();
session_write_close();

// Verhindern, dass die Session-Id oder session-header
// an den Client gesendet werden
ini_set('session.use_cookies', false);
ini_set('session.cache_limiter', '');
ini_set('session.use_trans_sid', 'false');
// die Rückgabewerte von ini_set könnte man auch in $original_values speichern
// und später wiederherstellen.
// Ist aber (sehr) unnötig.

echo '<div>Übernehme alle handler=files sessions</div>';
flush();
foreach(glob(ini_get('session.save_path').'/sess_*') as $sf) {
  session_id(substr(basename($sf), 5));
  if (session_start()===false) {
      echo '<p>failed to load session</p>';
  }
  else {
      echo '<pre>'; print_r($_SESSION); echo '</pre>';
      session_write_close();
  }
}

session_id($original_values['session_id']);
session_start();
// und weiter mit der Admin Session, wenn noch Daten benötigt oder geändert werden sollen
// sonst nicht nocheinmal starten und nur
// $_SESSION = array();
// setzen, damit nicht ausversehen Daten aus der letzten übernommenen Session angezeigt werden.

[defabricator]

Zitat von rambi

Da du mir nicht glaubst, hier mal ein paar Artikel zur Sicherheit mit Sessions:
http://www.linux-konkret.de/security...okies-url.html
http://de.wikipedia.org/wiki/Session_Fixation
http://www.cms-sicherheit.de/module-...-1-pid-30.html

Keiner der Artikel hat mit unserem Kernthema hier zu tun, das sich nicht darum dreht, wie Sessions allgemein festgemacht werden.
Wenn Du das anders siehst, belege das bitte genau. Ansonsten ist die Relevanz nämlich genauso groß wie bei der Aussage "echo ist böse, weil damit XSS Attacken möglich sind" ;)

Mein letztes Posting war ausschließlich an PHP-CODER gerichtet!
Welcher ja scheinbar die Notwendigkeit der Absicherungen grundsätzlich in Frage stellt.