nicht angemeldet
Hi Christian,
Nein, bei einem korrekt implementierten Challenge-Response-Verfahren wirst Du nur bei "Live-Angriffen" (d.h. jemand schneidet die Session-ID mit und nutzt diese sofort und nicht erst ein paar Stunden später) den Zugang zum System kompromittieren
Davon rede ich doch *g*
…solange du das nicht [SSL benutzt] haben alle Loginsystem mindestens eine Schwachstelle,
nämlich genau da wo Benutzername und Passwort übermittelt werden, in welcher Form auch immer
das konkret geschehen mag.
Wenn der Angreifer genau den Request mitschneidet, bei welchem Benutzername und Passwort übermittelt werden (den gibt es natürlich nur einmal, wenn der Benutzer sich einloggt), dann hat er alles, was er braucht um sich in Zukunft selber einloggen zu können. (Hierbei spielt es auch keine Rolle, ob man das Passwort im Klartext oder als MD5-Hash übermittelt.)
Wenn der Angreifer einen späteren Request mitschneidet, dann bekommt er nur die Session-ID, welche er benutzen kann, bis die Session abläuft.
Dem ersten Fall kannst du nur mit SSL entgegenwirken, letzterem Fall mit häufigem session_regenerate_id().
Beispiel: Ein Admin-Interface eines Weblogs. Da ist es relativ egal, ob jemand nun die Beiträge schon vorab lesen kann. Wenn er aber Zugriff darauf erlangt und dann seinen Unsinn treiben kann, wird's problematisch.
Ja, aber weil das Session-Cookie bei jedem Request vom Browser übermittelt werden muss, erhält der Angreifer auch in diesem Beispiel Vollzugriff auf das System, sofern er live agiert und nicht erst Stunden später handelt, sprich solange die Session-ID noch gültig ist (dies impliziert, dass der Benutzer sich noch nicht ausgeloggt hat).
Ob sich für ein bestimmtes Projekt der Aufwand der Einrichtung von SSL und die Verwendung von session_regenerate_id() lohnt, muss der Betreiber des Projekts selber entscheiden.
Viele Grüße,
~ Dennis.