Jepp, aber für ein Session-Management ist es nicht nötig die IP direkt zu speichern. Der einzige Fall bei dem es erlaubt ist, ist es die IP mit verschiedenen Faktoren in einer Session zusammenzufassen (mittels Hash-Funktion).

Jetzt kann man mit einem "IP-Check" überprüfen ob die Session zum Client passt. Eine direkte IP-Speicherung ist nicht nötig.

MfG Buergermaster

Wirklich empfehlen würde ich das Lesen des acros-Papers unter http://www.acros.si/papers/session_fixation.pdf. Es gibt konkrete Hinweise um ein eigenes Login ggf. noch sicherer zu gestalten.
Wenn man das Paper komplett gelesen und verstanden hat, sollte man auch in der Lage sein (mit Hilfe der Doku) die PHP-Einstellungen so zu wählen, dass sie perfekt (für den aktuellen Fall) sind.

Danach wird diese standardmäßig vom Server gelöscht. Nun gut, wenn Du in der Session her gehst und die IP Adresse speicherst sowie gegebenenfalls einen Browser Kennung, wird es schon bedeutend schwieriger an die Sessiondaten heranzukommen. Es ist natürlich nicht unbedingt die sicherste Variante, aber ich habe nicht behauptet, das die Session erstens solange verfügbar ist, zweitens keine IP Adresse sowie Browserkennung direkt in der Session gespeichert ist.

@GhostGambler

Wenn du so der PHP Profi im Bereich von Session bist, dann kannst du doch ganz einfach mal meine nachfolgenden PHP Einstellungen überprüfen und gegebenenfalls mir den einen oder anderen Ratschlag geben.

session.auto_start Off
session.bug_compat_42 On
session.bug_compat_warn On
session.cache_expire 180
session.cache_limiter nocache
session.cookie_domain no value
session.cookie_httponly Off
session.cookie_lifetime 0
session.cookie_path /
session.cookie_secure Off
session.entropy_file no value
session.entropy_length 0
session.gc_divisor 100
session.gc_maxlifetime 1440
session.gc_probability 0
session.hash_bits_per_character 4
session.hash_function 0
session.name PHPSESSID
session.referer_check no value
session.save_handler files
session.save_path /var/lib/php5 /
session.serialize_handler php
session.use_cookies On
session.use_only_cookies Off
session.use_trans_sid 0
suhosin.session.checkraddr 0
suhosin.session.cryptdocroot On
suhosin.session.cryptkey [ protected ]
suhosin.session.cryptraddr 0
suhosin.session.cryptua On
suhosin.session.encrypt On
suhosin.session.max_id_length 128

Wer keine Cookies aktiviert hat, bleibt eben draußen. Problematisch sind diese neuartigen Private-Browsing-Funktionen aktueller Browser. Ich kenne mich damit nicht so gut aus, aber ich glaube, damit werden keine Cookies gespeichert, oder?

Übrigens: Was ghostgambler in einem Nebensatz erwähnt hat, halte ich für extrem wichtig: Session-Cookies immer mit Secure-Flag ausstatten. Dann kann ein Angreifer nicht mehr per XSS-Angriff mittels JavaScript (oder anderer clientseitiger Sprachen) auf die Cookies zugreifen, sondern der Zugriff kann lediglich per HTTP erfolgen.

SSL bessert bei den komplizierten Verfahren wie Sniffing nach, aber bei den ganz einfachen Gefahren, dass ein Benutzer die URL von sich aus jemandem weiter gibt oder ohne Wissen die SID per Referer an einen fremden Host übergibt, bringt SSL rein gar nichts.

Die automatische Schließung einer Session erhöht die Sicherheit marginal. Es geht ja doch meist darum "akut" – heißt JETZT – eine Session zu knacken. Da interessiert es den Hijacker nicht, ob die Session in 2 Stunden abläuft.

Im aktuellen Jahrzehnt sehe ich keine Existenzberechtigung mehr für SIDs in URLs.

Dafür gibt es auch mehr als einen Beleg:
http://www.slideshare.net/guest0e6d5e/high-security-php-applications
Folie 18, einer/eine mit Commit-Recht für PHP auf Internationalen PHP-Konferenz über "High Security PHP Applications" empfiehlt offensichtlich "use_trans_id" abzuschalten.
http://www.acros.si/papers/session_fixation.pdf
Ein generell sehr lohnenswertes Paper. Wie dem geneigten Leser des Papers auffallen wird, ist nicht nur das Hijacken der Session-ID einfacher, sondern es erlaubt auch eine einfache neue Angriffsmöglichkeit der Fixation mit vorgegebenen SIDs. Im Vergleich dazu ist der Aufwand um eine rein auf Cookies basierende Session-Verwaltung dahingehend zu brechen, deutlich höher. Dem weniger geneigten Leser empfehle ich die kürzere Version: http://www.owasp.org/index.php/Session_fixation#Description

Vielleicht zum Abschluss noch ein Paper vom MIT
http://pdos.csail.mit.edu/cookies/pubs/webauth:tr.pdf
Seite 8, "A second method of setting an authenticator is to include it as part of the URL. Through the HTTP 1.1 specification [14] recommends against this, it [is] easy to do and sites still use this." und folgend. Hier ist sogar konkret der Vergleich von Cookie (im Paper der Absatz darüber) und URL via SSL, und auch bei der Variante rät das Paper offensichtlich davon ab die Session-IDs in URLs zu übergeben, während man bei den Cookies (nur) darauf achten muss, dass das sec-Flag gesetzt ist.

Wenn du jetzt immer noch der Meinung bist, dass SIDs in URLs nicht weiter schlimm ist, dann belege deine Aussage bitte entsprechend. Ansonsten gehe ich nicht davon aus, dass hier noch ein gemeinsamer Nenner gefunden wird.

Die einzige Möglichkeit die man hat, ist die Session direkt abzufangen und weiter zu verwenden. Bloß wenn standardmäßig der User sieht, dass sich was an seinen Daten geändert hat und automatisch die Session beendet. Dann kann man nichts mehr machen mit der Session. Natürlich muss man in dieser Geschichte den Aufwand, sowie die Sicherheitsrelevanten Aspekte beachten und sich Gedanken machen ob es überhaupt Sinn macht, einen solchen großen Aufwand zu betreiben ohne eine SSL Verbindung zu nutzen.

Ich würde an dieser Stelle mir auf jeden Fall Gedanken machen, über all wo man dementsprechend was bestellen kann. Dort würde ich jeden Betreiber einer Webseite, raten eine SSL Verbindung kostenlos für den User zur Verfügung zu stellen.

Auf jeden Fall kann man über dieses Thema sehr lange debattieren und würde wahrscheinlich früher oder später auf dem gleichen Nenner kommen, bloß ich muss sagen das ich gerade dafür nicht die Zeit und Lust habe.