[BUG?] Sicherheitsloch: Session von Contenido entführbar?!

[rethus]

Soeben habe ich durch Zufall festgestellt, das die Session in Contenido entführbar ist.Ich habe im Firefox einen Link aus dem Adminbereich kopiert, und diesen dann in meinem Konqueror (Browser) eingegeben.

Davon abgesehen, das meine htaccess-Passwortabfrage angeschlagen hat, konnte ich mich mit dem kopierten String aus der Adresszeile ohne Probleme einloggen.

Dies kann insbesondere eine Gefahr darstellen, wenn man von seinem Adminbereich auf eine andere Webseite wechselt. Wenn diese Seite ein Script nutzt, welches den Referer ausließt, ist der Zugang zu Eurer Seite schon geknackt... ohne das der Angreifer Eurer Passwort zu kennen muss.

Ein Lösungsansatz wäre entweder ein weiteres Cookie auf dem Clientrechner abzulegen, das in regelmäßigen Zeitabständen erneuert wird und die Session validiert, oder im Sessionhandling ein Refferer-Check einzubauen (so nach dem Motto, wenn der User die ganze Zeit von IP 1.2.3.4 gekommen ist, und jetzt von 2.3.4.5 kommt, lass ihn lieber nochmal neu einloggen).

Also die Empfehlung - wie sie ja immer gegeben wird ... verwendet htaccess zusätzlich zum Contenido-Passwortschutz!

[emergence]

eigentlich muss ich sagen, das ist ne bekannte sache...

verschoben...

[OliverL]

War mir zwar auch schon bekannt, aber:

1. das mit der IP des Client finde ich ne gute Idee
2. wenn man das System korrekt benutzt (mit Logout) stellt das kein Problem da

mfg oli

[Dodger77]

Abfragen der IP-Adresse und des Referers sind IMO nicht sinnvoll. Die IP-Adresse kann sich bei manchen Nutzern auch schon mal bei jedem einzelnen Aufruf ändern (habe ich schon bei Firmen- oder Universitätsproxies erlebt). Da leidet dann etwas die Bedienbarkeit.

Mehr dazu:

http://www.php-faq.de/q/q-sessions-ip.html

Und Referer werden ja auch nicht von jedem Browser gesendet.

Das mit dem Cookie fände ich da auch am besten. Das lässt sich im Übrigen auch jetzt schon nutzen. In der "conlib/local.php" kann man in der Klasse "Contenido_Session":

Code: Alles auswählen

  var $mode           	= "get";              ## We propagate session IDs with cookies

umstellen auf:

Code: Alles auswählen

  var $mode           	= "cookie";              ## We propagate session IDs with cookies

So sollte dann die SessionID nicht mehr an die URL angehängt werden. Ob das Backend dann aber zu 100% funktioniert, kann ich nicht sagen. Ich werde das aber selbst mal testen.

[rethus]

Naja, das mit dem Cookie war eigentlich anders gedacht, da man ja auch Cookies entführen kann.

Die Session nur als Cookie auszulagern bringt da meines erachtens nicht viel.

Ich dachte mehr daran, dass es ein Cookie als Validierungs-Flag genutzt wird.
Also die sessino weiter über GET, dann ein Cookie, das mit einer Zerfallszeit von xy belegt ist. Danach wird es erneuert.

Die Session in Verbindung mit dem Cookie ist valide.. wenn jetzt jemand versucht die Session zu kapern (SessionHijacking), und das System sieht, das kein Validierungs-Cookie da ist, wird die Session direkt abgeschossen.

Soweit zumindest zum teoretischen Ansatz

[Dodger77]

Naja, das mit dem Cookie war eigentlich anders gedacht, da man ja auch Cookies entführen kann.

Die Session nur als Cookie auszulagern bringt da meines erachtens nicht viel.

Nur: dein Szenario oben war ja, dass jemand anders deine SessionID aus der URL auslesen kann. Das wird durch die Umstellung auf Session-Cookies wohl schon verhindert.

[delinquent]

Sessions kann man immer entführen. Was ist denn, wenn ich keine Cookies akzeptiere? Hmmm.

[OliverL]

Ich denke solangsam das es so schon gut ist wie es ist.
Wenn mann sich an die Standard Funktinen hält: Einloggen und AUSLOGGEN.
Ist es gut.

@delinquent:
Dodger77's Post ist ein schon fertiger weg für den Referer und keine neue Idee. Zu den Grundregeln gehört bei mir nicht nur das ausloggen sondern auch wer mit einem CMS arbeitet sollte JS und Cookies akzeptieren.
(Bei Website's für den Endbenutzer/User finde ich JS immer noch nicht gut)

[delinquent]

Ja, ich weiß, dessen bin ich mir schon bewusst. Das ist nur immer ein Für und Wider. Immerhin bedeutet sowas immer mehr Support im Forum und Erklärungen, wenn Neulinge (nicht abwertend gemeint) eben durch solche Einstellungen in die Falle tappen. Ich meine nur, dass alles eben zwar präventiv ist, aber kein Allerheilmittel.

[wosch]

... wer mit einem CMS arbeitet sollte JS und Cookies akzeptieren.

Aber keine permanent-Cookies! Die gehören sowieso verboten.
Solange wie es bei temporären Cookies bleibt spricht nichts dagegen.

JS muß man leider akzeptieren, da es keine andere sinnvolle Technik gibt die Funktionalität zu erreichen.