Tobi2: Sessions und Sicherheit

Beitrag lesen

Nein, die üblicherweise richtige Konfiguration vorausgesetzt. Der Webserver gibt den Quellcode von Skripten generell nicht aus, sondern nur dass, was die Skripte ihrerseits ausspucken. Über anderweitige Zugänge (für fopen namentlich FTP) ist der Zugriff auf die Quellcodes nur mit Passwort möglich.

»»

Ist die Konfiguration über allow_url_fopen einzustellen?

Eine Sitzung wird nicht über den Cookienamen identifiziert, sondern über den Inhalt des Cookies, und dieser besteht automatisch aus einer zufälligen, jeweils nur eine einzelne Sitzung identifizierenden Zeichenfolge.

Cookies kannst du dir im Grunde einfach als Dateien vorstellen, jede Datei hat einen Namen, mit dem sie angesprochen wird, und einen Inhalt. Auf verschiedenen Rechnern kann es Dateien mit dem gleichen Namen, aber unterschiedlichem Inhalt geben.

Ja, das weiß ich. Das Problem ist ja nur, standardmäßig wird das Session-Cookie als PHPSESSID abgelegt, wenn das so in session.name in der php.ini konfiguriert wurde. Demnach könnte ja kein Cookie für einen zweiten Benutzer abgelegt werden.

Wenn im Cookie dauerhaftes Eingeloggt-bleiben vermerkt wurde, wie sieht es dann aus?

Die auf dem Server gespeicherten Sitzungsdaten verfallen entweder nicht oder nur nach langer Zeit (könnte zu unangehm viel Datenmüll führen), oder im Cookie ist der Benutzername zusammen mit einem geheimen Geheimcode gespeichert, dessen Geheimnis nur der Server entschlüsseln kann (ansonsten könnte sich jeder innerhalb einer Minute ein Cookie selbst basteln und anderer Leute Daten auslesen).

In einer WG benutzen verschiedene Personen denselben E-Mail-Provider oder Ebay und lassen den Einlogstatus vom Browser speichern

Und kluge Programmierer sorgen dafür, dass vor wichtige Funktionen im Webangebot in jedem Fall, egal ob dauereingeloggt oder nicht, eine weitere Passwortabfrage kommt (was natürlich nichts nützt, wenn das Passwort im Browser gespeichert ist).

Genau das war meine Frage. Also auf jeden Fall eine Paßwortabfrage, ob dauereingeloggt oder nicht. Irgendwie wird das Dauer-eingeloggt-sein damit sinnlos ..

(was natürlich nichts nützt, wenn das Passwort im Browser gespeichert ist).

Klar, soviel Verantwortung muß der User schon selbst übernehmen.

  1. Keine Frage zur Sicherheit, sondern zum Umgang mit Session-Cookies: Angenommen, Cookies sind abgeschaltet. Der User schickt das Einlogg-Formular ab. Das Skript prüft, ob ein Cookie gesetzt wurde. Wenn ja, findet die Überprüfung der Zugangsdaten statt. Wenn nein, wird der User auf die fehlende Cookie-Unterstützung hingewiesen und das Formular erneut ausgegeben. Der User schaltet Cookies ein und sendet das Formular ab. Nun wurde aber kein Cookie gesetzt (wenn der User das Formular nicht selbst nach Cookie-Einschaltung aktualisiert hat). Die Folge ist: Das Skript bemängelt wieder nicht eingeschaltete Cookies. Kann man das umgehen?

Ja, durch einen Zwischenschritt. Nach Absenden des Formulars wird der Inhalt geprüft, dann (bei korrekten Zugangsdaten) die Sitzung aufgemacht (nicht schon vor Schritt 1) und eine Zwischenseite ausgegeben, die a) den Keks setzt und b) automatisch zu einer Keksprüfseite weiterleitet, die ihrerseits die Keksexistenz prüft und je nach Ergebnis zur Kein-Keks-Korrekturklage oder zur gewünschten Inhaltsseite weiterleitet. Die Datenübergabe zwischen den einzelnen Schritten erfolgt durch Übermittlung der Sitzungskennung als URL-Parameter.

Daran hatte ich auch gedacht, mit header() weiterzuleiten. Ich dachte nur, es gäbe eine Alternative ohne Weiterleitung.

Diese Vorgehensweise hat unter Umständen gleichzeitig den Vorteil, dass man Leute, die kein Cookie brauchen, gar nicht erst mit Cookies belästigt.