Cookie Syndrom

[mt2]

So, ich muß da mal meinem Unmut Luft machen.

Session-Cookies.
Für normale Besucher.
Nicht gut.

Es ist sicher super bequem, wenn man einfach session_start() aufrufen kann, um dann ein paar Daten von Seite zu Seite zu schauffeln. Aber ich bin da ein bißchen eigen, und find das mal caching- und datenschutztechnisch bedenklich.
Ich will auf meiner Seite überhaupt niemandem eine Tracking-ID verpassen. Wozu auch? Die Leute sollen ja nur gucken, und interaktive Spiränzchen brauch ich im Moment keine.

Ich hab mal versucht diese Sessions abzuschalten (außer für mich, das ging ja noch). Aber ohne $_SESSION ist dann scheinbar die Kommentarfunktion ins Wanken gekommen. "Kommentar wurde gespeichert" aber in der DB tat sich nichts.
Ich geb zu, ich hab mir jetzt die comment-Funtionen nicht angeschaut, und wo und wie und ob wirklich auf irgendwelche $_SESSION-Felder zugegriffen wird.
Bei der Kommentarbox ist es natürlich verständlich, daß die womöglich von Cookies abhängig ist. Gut find ich das aber nicht. Das CAPTCHA war nicht eingeschalten, und selbst wenn, sollte es auch ohne funktionieren.

Ich hab gerade die beta-3.
Wo und was muß ich denn anpassen?

Und zweite Geschichte zu den Cookies. Der Patch gegen session fixation ist auch nicht ganz ok. Bei mir schickt der auf jeden Fall zu viele Cookies raus:

Code: Select all

  HTTP/1.1 200 OK
  Date: Mon, 16 Jul 2007 18:25:38 GMT
  Server: aEGiS_nanoweb/2.2.8 (Linux; PHP/5.2.1)
  Content-Type: text/html; charset=UTF-8
  X-Powered-By: PHP/5.2.1
  Set-Cookie: PHPSESSID=00baa10b1629f80d619257a1f1cd386f; path=/
  Set-Cookie: PHPSESSID=37d597eca6cc0113e13b6d604d9471da; path=/
  X-Session-Reinit: true
  X-Blog: Serendipity
  Cache-Control: private, pre-check=0, post-check=0, max-age=0
  Expires: 0
  Pragma: no-cache
  Connection: close

Scheint zwar zu klappen, aber besser wär hier natürlich wenn der Code nicht so unbedacht eine neue ID generiert, sondern erstmal schaut, ob es sich tatsächlich um eine böse von draußen eingeschleuste ID handelt:

Code: Select all

    // Patch by David Vieira-Kurz of majorsecurity.de
    if (isset($_COOKIE["PHPSESSID"]) && !isset($_SESSION['SERVER_GENERATED_SID'])) {
        session_destroy();

Aber für "PHPSESSID" gabs wohl mal irgendne Konstante, oder ini-Wert, ..?

[garvinhicking]

Hi!

Session-Cookies werden für Captchas benötigt, die oft im Einsatz sind. Auch wenn Du den XSRF-Schutz im Spamschutz-Plugin aktiviert hast ist eine Sesion benötigt.

Sessioncookies sind aber nicht notwendig für den normalen Besuch, also können deine Besucher sie ja selber ablehnen. Eine Session zu haben, in die man Daten packen kann, ist halt für viele Plugins von großem Vorteil.

Auch werden die sessions genutzt, um einen eingeloggten Benutzer zu identifizieren. Einen Patch, die sessions zu deaktivieren, kann ich daher nicht liefern ohne dass Du dir damit Funktionalität zerschießt.

Die Session-Fixation Sache wurde in der 1.2-Beta4 nochmal etwas überarbeitet. Aber ein "PHPSESSID" war niemals im Code drin: http://svn.berlios.de/viewcvs/serendipi ... iew=markup -- kann es sein dass Du die $_COOKIE['PHPSESSID']-Variable selbst da in den Code eingebastelt hast?

[mt2]

Die Session-Fixation Sache wurde in der 1.2-Beta4 nochmal etwas überarbeitet. Aber ein "PHPSESSID" war niemals im Code drin: http://svn.berlios.de/viewcvs/serendipi ... iew=markup -- kann es sein dass Du die $_COOKIE['PHPSESSID']-Variable selbst da in den Code eingebastelt hast?

Ja. Den Test mit isset($_COOKIE) von oben hatte ich dort reingebastelt. Das hatte das Doppel-Cookie-"Problem" für mich behoben. Aber wenn ich's mir nochmal genau ansehe, wird damit das doppelte session_start() einfach nur auf die zweite Anfrage vertagt.

Beta4a hab ich mir gerade eingebaut, und auch da seh ich immer zwei Set-Cookie header.
Aber andererseits könnte man das wohl als weitestgehend und sowieso unsichtbaren Schönheitsfehler abtuen. Denn Firefox scheints ja auch nicht zu beeinflussen.

Session-Cookies werden für Captchas benötigt, die oft im Einsatz sind. Auch wenn Du den XSRF-Schutz im Spamschutz-Plugin aktiviert hast ist eine Sesion benötigt.

Na ok, das CAPTCHA läßt sich ja einfach ersetzen. Und dann schalt ich den CSRF-Test halt erstmal aus..

Aber wofür genau ist der 'serendipity[token]' gut?
Beeinflusst der Token wirklich nur ein abgesendetes Comment-Formular?
Oder blockt der z.B. auch die (Delete)-Links der einzelnen Kommentartexte?
Und dient das nur dem Schutz meines Usernamens, oder hat der Token [an dieser Stelle] noch andere Aufgaben?
Und wird der doch in der Datenbank gespeichert? Ich find da irgendwie gerad keine Referenz zu $_SESSION in spamblock-plugin.

(P.S. Ansonsten wärs mir persönlich wieder relativ egal, weil ich benutze eh Opera; und der sendet BasicAuth&Cookies erst in der zweiten Anfrage nach einem Redirect und Domain-Wechsel. Und BBcode verbitt ich mir ohnehin in den Kommentaren..

Grüße und Danke für any Hinweise!
mario

[garvinhicking]

Hi!

Beta4a hab ich mir gerade eingebaut, und auch da seh ich immer zwei Set-Cookie header.
Aber andererseits könnte man das wohl als weitestgehend und sowieso unsichtbaren Schönheitsfehler abtuen. Denn Firefox scheints ja auch nicht zu beeinflussen.

Hm, das müsste ich mir nochmal ansehen, bei mir erhalte ich nur einen Set-Cookie-Header! Hast Du evtl. noch andere Stellen gepatcht, aufgrund dem das Verhalten auftreten könnte?

Zwar ist es nur ein Schönheitsfehler, aber auch das wäre natürlich nicht so schön. Ich schau mal, ob ich das irgendwie reproduzieren kann.

Aber wofür genau ist der 'serendipity[token]' gut?
Beeinflusst der Token wirklich nur ein abgesendetes Comment-Formular?
Oder blockt der z.B. auch die (Delete)-Links der einzelnen Kommentartexte?

Der Token schützt nur das Übermitteln eines Kommentares. Ist kein Token gesetzt, kann man schließen dass ein Besucher vorher nicht auf der Kommentarseite war und einen Kommentar automatisiert versucht zu übermitteln. Oder halt keine Cookies aktiviert hat.

Die Delete-Links werden leider noch nicht durch den Token gesichert. Das ist aber ein guter Hinweis, darum werde ich mich kümmern müssen!

Und wird der doch in der Datenbank gespeichert? Ich find da irgendwie gerad keine Referenz zu $_SESSION in spamblock-plugin.

Nein, der token wird nur in der Session gespeichert! In der serendipity_event_spamblock.php folgende Funktion:

Code: Select all

 serendipity_setFormToken('form');

Das ist eine zentrale Funktion (aus der include/functions_config.inc.php

Der Token wird an anderen Stellen im s9y Backend immer wieder genutzt, dafür ist er eigentlich gedacht. Im Spamblock-Plugin wird das eher als 'Nebeneffekt' eingesetzt.

Den Sicherungsmechanismus von Opera kannte ich garnicht, das ist natürlich auch ein sehr effektiver Schutz vor CSRF. Hoffentlich wird so etwas ähnliches (konfigurierbar) auch mal in Firefox Einzug halten, denn da ist mir sowas noch unbekannt.

Viele Grüße,
Garvin

[mt2]

Hey,
Danke für die flinke Antwort!

Hm, das müsste ich mir nochmal ansehen, bei mir erhalte ich nur einen Set-Cookie-Header! Hast Du evtl. noch andere Stellen gepatcht, aufgrund dem das Verhalten auftreten könnte?

Nee, sonst hab ich nix angepasst.
Aber das mit den Doppel-Cookies tritt natürlich nur auf, wenn man als nicht-eingeloggter User auf die Seite zugreift. Dann exisitert noch kein Cookie, das erste session_start() erzeugt und sendet eins, dann prüft der fixation-test und erzeugt den zweiten Cookie mit session_wasauchimmer... oder so.

wget -S localhost -O /dev/null # ist natürlich zum Testen auch nicht so der Bringer, weil speichert ja eh keine Kekse; und ist also nur für den ersten Aufruf nützlich.

Code: Select all

 serendipity_setFormToken('form');

Das ist eine zentrale Funktion (aus der include/functions_config.inc.php

Aha. Ich glaub jetzt hab ich's geschnallt

Aber mir fällt gerad ein, mit quasi jedem Captcha wird sowieso irgendeine ID mitgesendet, und dann ist es ja weniger schlimm, wenn ich das S9Y-Token auslasse.

(Und CSRF-Spambots gibt's ja zum Glück eh noch nicht.)


Beste Grüße!