Bla: Sessions und Sicherheit

Beitrag lesen

  1. Ist es möglich, von einem fremden Server aus PHP-Skripte (z. B. Konfigurationsdateien, in denen die Zugangsdaten für die Datenbank stehen) mit fopen auszulesen und den Quellcode anzuzeigen?

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.

  1. Wie verhält es sich, wenn von einem Rechner zwei Logins mit unterschiedlichen Benutzerangaben stattfinden (unterschiedliche Personen)? Muß vor session_start() mit session_name() eine Name gesetzt werden, damit unterschiedliche Cookies gesetzt werden?

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.

Wenn diese Vorgehensweise richtig ist, kann dann ein zweiter Benutzer desselben Rechners trotzdem irgendwie in die Session des ersten Benutzer reinkommen?

Jeder kann anderer Leute Sitzungen kapern, allerdings braucht er dazu die Kennung, also besagte Zeichenfolge.

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

Deswegen nutzt der kluge Nutzer diese Funktion niemals auf Rechnern, auf die andere Zugriff haben. 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).

  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.
Diese Vorgehensweise hat unter Umständen gleichzeitig den Vorteil, dass man Leute, die kein Cookie brauchen, gar nicht erst mit Cookies belästigt.