Safari 3.1.x: PHP Session Cookie Handling

[2nd]

Hi,

ich sitze seit 1 Stunde an einem blöden Problem:

Ich starte eine via session_start(); eine Session und fülle das Array mit Werten.

Bis jetzt war es immer so, dass PHP und die Browser automatisch regelten, wie die Session-ID übertragen wird: Per default via Cookie, wenn das nicht geht, wird die ID an den URL gehängt. So ist das ja auch gedacht.

Hat auch immer blendend funktioniert. Heute aber nicht mehr, zumindest im Safari.

Wenn ich einen HTTP-Request mit gefüllter $_SESSION ausführe (laden eines anderen Dokuments per Link) ist $_SESSION leer. Hänge ich die Session-ID explizit an den URL, ist das drin, was ich reingetan habe.

Mache ich das Ganze mit Firefox, brauche ich die ID nicht an den URL hängen, hier funktioniert es per Cookie.

Ich habe mal in beiden Browser die Cookies durchsucht: In Safari gibt es keinen Cookie für meine Domain mit PHPSESSID, im Firefox schon.

Nun habe ich das hier gefunden: http://bugs.caucho.com/bug_view_advanced_page.php?bug_id=2649

Hat sonst noch jemand diese Erfahrungen gemacht? Bzw. wie kann ich das Problem so umgehen, dass ich nicht extra für Safari die SID an den URL anhängen oder per HIDDEN-Field mitgeben muss?

 

[2nd]

So, ich habe das Problem eingegrenzt und gefixt:

Entweder man setzt per PHP Konfig Direktive TransSID auf ON (per php.ini, htaccess oder im PHP Code):

ini_set("session.use_trans_sid", 1);
session_start();

Damit erkauft man sich aber zwei Nachteile:

1. fkt. das evtl. nicht bei allen Providern
2. wird die SID im URL übertragen, obwohl das nicht sein muss (bei Safari)

Etwas besser ist es, man fixiert die aufrufende Domain für alle Cookies - dann wird auch der/das PHPSESSID Cookie korrekt an Safari übertragen:

session_set_cookie_params(60*n, '/', '.domain.tld', FALSE, FALSE);
session_start();

Ist das ein Bug oder ein Feature von Safari? Eigentlich wollte ich heute voran kommen und mich nicht mit so einem Mist auseinandersetzen

Wie macht Ihr das mit Sessions, der ID und Cookies im Allgemeinen? Setzt Ihr immer eine Domain für Cookies?

 

[Atarimaster]

Ist das ein Bug oder ein Feature von Safari?

Das ist meiner Meinung nach ein echter Bug -- der zudem (so geht es zumindest auch dem verlinkten Bugreport hervor) in der aktuellen Safari-Version 3.2.1 gefixt zu sein scheint.

 

[2nd]

Danke für Deine Antwort. Das habe ich natürlich auch vermutet und einen Rechner auf 3.2.1 geupdatet - keine Besserung.

Im Netz gibt es auch einige Berichte, dass sich User nicht mehr einloggen (z. B. Drupal Backend) können bzw. Entwickler ihre Skripte umschreiben müssen.

An sich dachte ich, dass wir im Jahre 2008 Bugs solcher Art hinter uns gelassen haben

 

[Atarimaster]

Das habe ich natürlich auch vermutet und einen Rechner auf 3.2.1 geupdatet - keine Besserung.

Na super.

Im Netz gibt es auch einige Berichte, dass sich User nicht mehr einloggen (z. B. Drupal Backend) können bzw. Entwickler ihre Skripte umschreiben müssen.

Wenn das so ist, sehe ich mich demnächst auch schon an einigen Scripten rumschrauben...

 

[UDH5]

Taucht das Problem bei all deinen Websites auf?
Bislang hatte ich auch in Safari 3.1x keine Session-Probleme.

Ich nutze session.use_trans_sid = 1 und schon aus diesem Grund für Website-Administration immer XHTML 1.0 Transitional.

Ich kann mir vorstellen, dass dein Provider dir nicht erlaubt diese Einstellung zu verändern. Es ist zwar unter PHP_INI_ALL angegeben,
aber, meiner Erfahrung nach, geht das nicht immer. Ich habe jedenfalls diesbezüglich immer beim Provider vorgesprochen - ausgenommen 1und1, die machen es dir mit einer Ergänzungs-"php.ini" leicht.

Gegen XSS sollte man seine Session sowieso durch eine "Kennung" und einen Vergleich mit den gespeicherten "Session-Kennungs-Daten" absichern. Stimmt die Kennung nicht, wird eine neue ID und damit eine leere Session vergeben, d.h. der Angreifer kann die Session nicht verwenden oder einsehen; er sieht allenfalls seine eigene Session. Wird die Session im Web hinterlegt (z.B. durch Google) ist sie tot, wenn die Kennung nicht stimmt - Wie man diese Kennung bastelt, kann sich ja eder selbst überlegen - (Tipp: AOL-Kunden bekommen ständig eine neue IP zugewiesen, bzw. die letzte IP-Dezimal-Stelle. Überprüft man die vollständige IP beim Login, werden AOL-User in der Regel nach erfolgreichem Login gleich wieder ausgeloggt).

Wenn der Domainname einen Unterstrich enthält, dann kann Safari kein Session-Cookie anlegen -
selbst wenn Cookies akzeptiert werden, läuft die ID-Übergabe nur über URL; also session.use_trans_sid = 1. Bei Ajax-Anwendungen gibt es in diesem Fall (und bei deaktiviertem Cookie) Cache-Probleme, wenn man die Session-ID nicht als globale JS-Variable übergibt.

 

[2nd]

UDH5: Ich bin mein eigener Provider. Aber um das Setzen von bestimmten Direktiven geht es gar nicht, eher um das Problem im Allgemeinen.

Der Hinweis bzgl. der Sicherheit ist natürlich richtig, aber das berührt das Thema nur am Rande.

Ganz ohne Session in Safari brauche ich mir auch keine Gedanken um die Sicherheit dieser machen