Druckbare Version
Hallo ihr,
eine mehr oder wenige einfache Frage: Würde es die Sicherheit von Contao erhöhen, wenn man die das httponly-Flag setzt für Session-Cookies (siehe hier)? Also gibt es irgendeinen Fall, wo man als JS-Entwickler die SID wirklich benötigt? Wenn nicht könnte man überlegen, ob man evtl. dieses Flag vom Core aus setzt. Was meint ihr? Bzw. habt ihr damit Erfahrung?
Gruß
SunBlack
Also 1. ist die Session vor allem in Verbindung mit Ajax Wichtig. Die Session ist ja nicht nur für die Anmeldedaten, sondern auch für sonstige Daten die man während des Besuchs speichern will wichtig und vor allem in Verbindung mit Ajax kann das sehr wichtig sein. Ich speicher schon mal bei Ajax Requests Daten in der Session zwischen.
Und 2. ist das laut Doku ein Feature, dass nicht jeder Browser unterstützt und damit keine wirkliche Verbesserung der Lage.
Also rundum, wenn man mal von der Benutzeranmeldung absieht ist die Session vor allem in Verbindung mit Ajax eher mal interessant, als ohne Ajax, daher halte ich von dem Flag nicht sehr viel, ob man das als System-Setting einbauen könnte wäre unter Umständen zu diskutieren. Hier würde ich es davon abhängig machen, wie viele Browser das tatsächlich unterstützen?!
Die ändert sich doch erst, wenn die Session zerstört oder der Browser neu gestartet wird, ansonsten ist und muss die Session ID für die Dauer des Website Besuchs ja gleich bleiben.Zitat:
Zitat von leo.unglaub
@leo: Contao verwendet das regenerieren selber nicht. Was mir heute aber auch aufgefallen ist: Contao überschreibt ja nicht einmal den normalen Session-handler (session_set_save_handler), sondern überlasst die Speicherung auch dem Server. Soweit ich weiß legt der Server somit irgendwo lokal die Sitzungsdaten ab (also was in $_SESSION gespeichert wird), anstatt man dem Server sagt, dass alles über die DB geregelt wird. Oder täusche ich mich da gerade irgendwo? (Es ist schon spät...) Bei einem Kumpel führte die serverseitige Speicherung letztens für Probleme (war aber nicht Contao, sondern ein eigenes Projekt von ihm, das lokal problemlos lief, auf dem Server aber die Sessions vergaß, da standardmäßig eine Session bei php nur 3 Minuten gültig ist). Mir sind bei Contao zwar keine Probleme damit bekannt, aber man sollte vlt. trotzdem überlegen, ob man dem Server mitteilt, dass man sich selber darum kümmert.
@tril: Wenn du einen Request an den Server schickst, sollte der Cookie trotzdem mitgesendet werden. Bei httponly geht es ja nur darum, dass Ajax die SID nicht auslesen kann - und für dieses auslesen sehe ich keinen Usecase. Ansonsten: Auch wenn es nicht alle Browser unterstützen - wenn man auf irgendeinen Browser damit einen solchen Angriff verhindern kann ohne das es uns was kostet - wieso dann nicht? Mir sind präventive Sicherheitsmaßnahmen lieber, als irgendwann mal einen Schaden beheben zu müssen, den man davor hätte verhindern können...
PS: Falls nichts gegen die Verwendung spricht, würde ich es im Ticketsystem anregen.
Also Mitglieder/User-Session-Daten werden tatsächlich in der Datenbank gespeichert, alles was du über die Session Klasse machst. In $_SESSION wird von Contao selber glaube ich kaum was gespeichert, da speicher ich selbst vielleicht mal was rein und eventuell die ein oder andere Extension. Ganz genau kann ich das aber auch nicht sagen. Und was deinen Kumpel schief gelaufen ist ist ganz einfach, der Server wahr fehlkonfiguriert. Eine Session in PHP ist standardmäßig zwar 3 Minuten gültig (bei Nichtbenutzung), aber das lässt sich alles Konfigurieren.Zitat:
Zitat von SunBlack
Also ich denke vor allem in Verbindung mit dem Cache ist es nicht unbedingt Sinnvoll die Session in eine DB zu schreiben, bei Contao gilt afaik das Prinzip "Seite aus dem Cache == kein DB Zugriff erforderlich".
Ah ok, also wird lediglich der Zugriff über window.cookie verhindert? Das klingt ja gar nicht mal schlecht, wenn das auch noch die meisten Browser unterstützen dann gibts dafür ein +1 ;)Zitat:
Zitat von SunBlack
https://www.owasp.org/index.php/HTTP...rting_HttpOnlyZitat:
Zitat von tril
+2 ;)
Wg. AJAX in diesem Zusammenhang nicht sinnvoll. -1
Wenn man es richtig machen möchte (IMO): Session-Cookie HTTP-Only markieren plus kurzlebiges (einmal-)Token-Cookie für AJAX/JS. Aber das ist viel Aufwand für vergleichsweise wenig Effekt.
Zitat:
Zitat von FloB
@FloB ich hoffe du hattest das gelesen? In diesem Zusammenhang entsteht nämlich kein wirklicher Nachteil in Verbindung mit Ajax, ich dachte auch das die Cookies dann bei Ajax Request nicht übermittelt werden, aber es geht nur um den Zugriff über window.cookie via JavaScript.Zitat:
Zitat von SunBlack
Was sagt dann die 5. Spalte in dem bereits genannten Dokument (https://www.owasp.org/index.php/HTTP...rting_HttpOnly)?
Das geht dabei um document.cookie. Also Cookies werden weiterhin gesetzt und übermittelt, nur kannst du eben nicht mit document.cookie in JS darauf zugreifen. Ein Cookie wird ja sowieso nicht an anderslautende Domains verschickt, daher ist deine einzige Möglichkeit ein Cookie zu klauen, in dem du von einer präparierten Seite einen Ajax-Request an den richtigen Server sendest, dabei wird der Cookie übertragen. Aber halt nur zum Client, also musst du am Client mittels JavaScript den Cookie auslesen. Und dann kannst du den Cookie erst weiter senden und "klauen". Das soll soweit ich das jetzt verstanden habe HttpOnly verhindern.Zitat:
Zitat von FloB
http://www.gnucitizen.org/blog/why-h...t-protect-you/Zitat:
HttpOnly is a an option which specifies that the cookie (session identifiers included) should not be accessed from the application DOM. In that case the attacker cannot hijack the session because document.cookie will not return anything useful.
Zu den einzelnen Spalten aus der Tabelle:
Prevents Reads -> Verhindert lesen bei regulärem Aufruf -> ohne Ajax
Prevents Writes -> Verhindert schreiben bei regulärem Aufruf -> ohne Ajax
Prevents Read within XMLHTTPResponse* -> Verhindert lesen bei regulärem Aufruf -> via Ajax
Kleine Randsache: Wenn man dieses Flag setzt, könnte man noch den Domainpfad einschränken, also dass z.B. nur über localhost/contao/ auf das Cookie zugegriffen werden darf, aber nicht mehr über localhost/typolight.
Wie handelt die FE Vorschau das denn? Ich weiß, die ist nur eine Datei in contao/ aber wenn man z.B. versteckte Elemente anzeigen lässt, da muss das FE außerhalb von contao/ doch Zugriff auf das AUTH Cookie haben?! Würde das nicht dadurch verhindert?Zitat:
Zitat von SunBlack
Ok, das Beispiel war nicht perfekt, da es missverstanden werden kann. Die beiden Beispielpfade sollte Pfade zu verschiedenen Installationen sein und kein Pfad aufs Backend. Also Cookiepfad ist bisher "/" angegeben. Ich würde ihn halt auf $GLOBALS['TL_CONFIG']['websitePath'] setzen
http://dev.contao.org/issues/3334 +1 :)Zitat:
Zitat von SunBlack
Das andere steht jetzt als Ticket #3335 drin, inkl. Patch für beide Tickets.
Die Domain habe ich freigelassen, da eine Webseite ja durchaus über mehrere (Sub-)Domains erreichbar sein kann - von daher überlasse ich diese Einstellung dem Browser.
Interessant daran ist: Wenn man einen falschen Pfad angibt, gibt Contao immer eine "Invalid Request Token"(IRT)-Fehlermeldung - und das, obwohl nur das Cookie kaputt ist (gebt als Pfad einfach mal 0 oder so an^^) und ich dann ja eigentlich nur ausgeloggt sein müsste. Aber den IRT-Check habe ich mir eh noch nicht angeschaut, wie der funktioniert.