Moin!
session_regenerate_id(); // erneuert die Session-ID,
# // erschwert Session-Hijacking
>
> > Inwiefern sollte es gegen Session-Hijacking nützlich sein, bei jedem Request eine weitere gültige Session zu erzeugen? Das ist geradezu eine Einladung für Angriffe dieser Art.
>
> Danke für den konstruktiven Hinweis. Ich habe der Funktion session\_regenerate\_id() den Parameter true hinzugefügt (damit wird seit PHP 5.1. die alte Session gekillt) und mir auf den Zettel geschrieben, dass dieses, so die Diskussion hier nichts besseres ergibt, an die Nicht-Nutzung von https gebunden wird.
Session-Fixation geht auch mit HTTPS. Es ist eine gute Idee, bei HTTPS ebenso neue Session-IDs zu erzeugen, wenn der User seine Rechte in seiner Session erhöht, d.h. vom unangemeldeten User zum angemeldeten User wird, und von dort evtl. nochmal zum Admin. Jede Erhöhung der Rechte sollte eine neue Session-ID ergeben.
> Es ist IMHO durchaus nicht ganz sinnlos. Zumindest wenn der Angreifer versucht, die Session-ID durch Mitschneiden des Netzverkehrs (tcpdump, wireshark, ...) zu "klauen" und dann manuell(!) versucht, diese zu übernehmen, ist es ziemlich wahrscheinlich, dass diese Session-ID auf Grund einer Aktion des berechtigten Benutzers inzwischen nicht mehr gültig ist. Es gibt auch einen Sicherheitsgewinn, weil der Angreifer den Netzverkehr zum Zeitpunkt der Anmeldung mitschneiden muss um an die Login-Daten zu kommen. Irgendwer mag mit Statistiken fummeln und was zu Prozentzahlen sagen.
Unverschlüsselte Kommunikation ist sowieso anfällig gegen alles. Der Knackpunkt ist, dass auch Verschlüsselung nicht gegen Angriffe schützt!
> Bei der Verwendung von https muss man sich hingegen fragen, ob die dadurch erhöhte Serverlast im Hinblick auf den Rest des noch zu erwartenden Sicherheitsgewinns vertretbar ist. Deshalb wäre ich beim Stand der bisherigen Diskussion für:
>
> https: keine Umbennnung
Falsch.
> http: Umbenennen mit session\_regenerate\_id(true)
Richtig.
- Sven Rautenberg