INI-Einstellungen für die Sicherheit von Sessions
Durch die Absicherung der für Sessions relevanten INI-Einstellungen können Entwickler die Sicherheit von Sessions verbessern. Für einige wichtige INI-Einstellungen gibt es keine empfohlenen Einstellungen. Für die Absicherung der Session-Einstellungen sind die Entwickler verantwortlich.
-
0
hat eine besondere Bedeutung. Es teilt den Browsern mit, dass das Cookie nicht dauerhaft gespeichert werden soll. Daher wird das Cookie für die Session-ID sofort gelöscht, wenn der Browser geschlossen wird. Wenn Entwickler diese Einstellung auf einen anderen Wert als 0 setzen, kann dies dazu führen, dass andere Benutzer die Session-ID verwenden können. Die meisten Anwendungen sollten dafür "0
" verwenden.Wenn eine automatische Anmeldung erforderlich ist, müssen die Entwickler ihre eigene sichere Funktion für die automatische Anmeldung implementieren. Verwenden Sie dafür keine langlebigen Session-IDs. Weitere Informationen sind oben im entsprechenden Abschnitt zu finden.
-
Obwohl HTTP-Cookies einige Probleme aufweisen, bleiben Cookies die bevorzugte Methode zur Verwaltung von Session-IDs. Wenn möglich, sollten nur Cookies für die Verwaltung der Session-IDs verwendet werden. Die meisten Anwendungen sollten ein Cookie für die Session-ID verwenden.
Bei
session.use_only_cookies
=Off verwendet das Session-Modul, falls das Cookie für die Session-ID nicht initialisiert ist, die von GET/POST/URL gesetzten Werte. -
Obwohl die Aktivierung von
session.use_strict_mode
für sichere Sessions zwingend erforderlich ist, ist es standardmäßig deaktiviert.Dies verhindert, dass das Session-Modul eine nicht initialisierte Session-ID verwenden kann. Anders ausgedrückt, akzeptiert das Session-Modul nur gültige Session-IDs die vom Session-Modul erzeugt wurden. Es lehnt jede vom Benutzer vorgegebene Session-ID ab.
Aufgrund der Cookie-Spezifikation sind Angreifer in der Lage, durch Anlegen einer lokalen Cookie-Datenbank oder durch eine JavaScript-Injection nicht entfernbare Cookies für die Session-ID zu platzieren.
session.use_strict_mode
kann verhindern, dass eine vom Angreifer initialisierte Session-ID verwendet wird.Hinweis:
Angreifer können mit ihrem Gerät eine Session-ID initialisieren und die Session-ID des Opfers setzen. Sie müssen die Session-ID aktiv halten, um sie zu nutzen. In diesem Szenario benötigen Angreifer zusätzliche Schritte, um einen Angriff durchzuführen. Daher funktioniert
session.use_strict_mode
als Schutzmaßnahme. -
Verweigert den Zugriff auf das Session-Cookie durch JavaScript. Diese Einstellung verhindert das Abgreifen von Cookies durch eine JavaScript-Injection.
Es ist möglich, eine Session-ID als CSRF-Token zu verwenden, aber dies wird nicht empfohlen. Zum Beispiel können HTML-Quellen gespeichert und an andere Benutzer gesendet werden. Um die Sicherheit zu erhöhen, sollten Entwickler keine Session-IDs in Webseiten schreiben. Fast alle Anwendungen müssen das httponly-Attribut für das Cookie der Session-ID verwenden.
Hinweis:
Das CSRF-Token sollte genau wie die Session-ID regelmäßig erneuert werden.
-
Den Zugriff auf das Cookie für die Session-ID nur dann zulassen, wenn das Protokoll HTTPS ist. Wenn eine Webseite nur über HTTPS zugänglich ist, sollte diese Einstellung aktiviert werden.
HSTS sollte für Webseiten in Betracht gezogen werden, die nur über HTTPS zugänglich sind.
-
session.cookie_samesite="Lax" or session.cookie_samesite="Strict"
Ab PHP 7.3 kann das
"SameSite"
-Attribut für das Cookie der Session-ID gesetzt werden. Dieses Attribut ist eine Möglichkeit, CSRF-Angriffe (Cross Site Request Forgery) zu entschärfen.Der Unterschied zwischen Lax und Strict ist die Verfügbarkeit des Cookies in Anfragen, die von einer anderen registrierbaren Domain stammen und die HTTP-GET-Methode verwenden. Cookies, die Lax verwenden, stehen in einer GET-Anfrage, die von einer einer anderen registrierbaren Domain stammen, zur Verfügung, während Cookies, die Strict verwenden, nicht zur Verfügung stehen.
-
session.gc_maxlifetime=[kleinstmöglichen Wert wählen]
session.gc_maxlifetime
ist eine Einstellung zum Löschen veralteter Session-IDs. Es wird empfohlen, sich nicht auf diese Einstellung zu verlassen. Entwickler sollten die Gültigkeitsdauer von Sessions mit einem Zeitstempel selbst verwalten.Die Session-GC (Garbage Collection) wird am besten mit der session_gc() durchgeführt. Die Funktion session_gc() sollte von einem Taskmanager, z. B. cron auf UNIX-ähnlichen Systemen, ausgeführt werden.
Die GC wird standardmäßig mit einer gewissen Wahrscheinlichkeit durchgeführt. Diese Einstellung garantiert nicht, dass eine veraltete Session gelöscht wird. Obwohl sich Entwickler nicht auf diese Einstellung verlassen können, wird empfohlen, sie auf den kleinstmöglichen Wert einzustellen. Die Einstellung von session.gc_probability und session.gc_divisor ist so anzupassen, dass veraltete Sessions in angemessenen Abständen gelöscht werden. Wenn eine automatische Anmeldung erforderlich ist, müssen die Entwickler ihre eigene sichere Funktion für die automatische Anmeldung implementieren. Siehe oben für weitere Informationen. Für diese Funktion darf keine langlebige Session-ID verwendet werden.
Hinweis:
Einige Module zur Speicherung von Sessions verwenden diese Einstellung für die wahrscheinlichkeitsbasierte Verfallszeit nicht, z. B. memcached, memcache. Details sind der Dokumentation des Session-Save-Handlers zu entnehmen.
-
Die Verwendung einer transparenten Verwaltung von Session-IDs ist nicht verboten. Entwickler können sie verwenden, wenn sie erforderlich ist. Die Deaktivierung der transparenten Verwaltung von Session-IDs verbessert jedoch die allgemeine Sicherheit von Session-IDs, indem die Möglichkeit einer Session-ID-Injection und/oder eines Session-ID-Lecks ausgeschlossen wird.
Hinweis:
Eine Session-ID kann von URLs in Lesezeichen, URLs in E-Mails, gespeicherten HTML-Quellen usw. nach außen dringen.
-
session.trans_sid_tags=[eingeschränkte Tags]
(PHP 7.1.0 >=) Entwickler sollten nicht benötigte HTML-Tags nicht umschreiben. Der Standardwert sollte für die meisten Anwendungen ausreichend sein. Ältere PHP-Versionen verwenden stattdessen url_rewriter.tags.
-
session.trans_sid_hosts=[eingeschränkte Hosts]
(PHP 7.1.0 >=) Diese INI-Einstellung definiert Whitelist-Hosts, die trans-sid-Rewrite erlauben. Fügen Sie niemals nicht vertrauenswürdige Hosts hinzu. Wenn diese Einstellung leer ist, erlaubt das Session-Modul nur
$_SERVER['HTTP_HOST']
. -
session.referer_check=[Ursprungs-URL]
Wenn session.use_trans_sid aktiviert ist, verringert diese Einstellung das Risiko der Injektion von Session-IDs. Wenn die Webseite http://example.com/ ist, dann setzen Sie diese Option auf http://example.com/. Beachten Sie, dass Browser bei HTTPS keine Referrer-Header senden. Je nach Einstellungen des Browsers werden möglicherweise keine Referrer-Header gesendet. Es handelt sich also nicht um eine zuverlässige Sicherheitsmaßnahme, aber es wird empfohlen, diese Einstellung zu verwenden.
-
session.cache_limiter=nocache
Stellt sicher, dass HTTP-Inhalte für authentifizierte Sessions nicht zwischengespeichert werden. Erlaubt die Zwischenspeicherung nur, wenn der Inhalt nicht privat ist. Andernfalls kann der Inhalt offengelegt werden. Der Wert "private" kann verwendet werden, wenn HTTP-Inhalte keine sicherheitsrelevanten Daten enthalten. Zu beachten ist, dass "private" private Daten übertragen kann, die von gemeinsam genutzten Clients zwischengespeichert werden können. "public" darf nur verwendet werden, wenn HTTP-Inhalte überhaupt keine privaten Daten enthalten.
-
session.sid_length="48"
(PHP 7.1.0 >=) Je länger eine Session-ID ist, desto stärker ist sie. Entwickler sollten in Erwägung ziehen, die Länge der Session-IDs auf mindestens 32 Zeichen zu erhöhen. Bei session.sid_bits_per_character="5" sind mindestens 26 Zeichen erforderlich.
-
session.sid_bits_per_character="6"
(PHP 7.1.0 >=) Je mehr Bits ein Zeichen einer Session-ID enthält, desto stärker ist die vom Session-Modul generierte Session-ID bei gleicher Länge der Session-ID.
-
session.hash_function="sha256"
(PHP 7.1.0 <) Eine stärkere Hash-Funktion erzeugt eine stärkere Session-ID. Obwohl eine Hash-Kollision selbst mit dem MD5-Hash-Algorithmus unwahrscheinlich ist, sollten Entwickler SHA-2 oder einen stärkeren Hash-Algorithmus wie sha384 und sha512 verwenden. Die Entwickler müssen sicherstellen, dass sie eine ausreichend lange Entropie für die verwendete Hashing-Funktion angeben.
-
session.save_path=[nicht allgemein lesbares Verzeichnis]
Wenn dies auf ein für die Allgemeinheit lesbares Verzeichnis gesetzt wird, z. B. /tmp (der Standard), können andere Benutzer auf dem Server in der Lage sein, Sessions zu kapern, indem sie die Liste der Dateien in diesem Verzeichnis auslesen.