molily: Session hijacking verhindern

Beitrag lesen

Hallo,

Nein, wieso? $_SESSION ist für den Angreifer nicht einsehbar.

Wozu auch wenn er sich darauf verlassen kann, dass der Token dort drin steht?

Er kann sich zumeist darauf verlassen, ja. So ist es schließlich in großen Web Application Frameworks implementiert.

Wo genau der Token serverseitig abgespeichert ist, ob in einer Datei oder in einer Datenbank, oder ob er sogar im Cookie steht, ist eigentlich irrelevant. Ohne weiteres kann eine fremde Site den Token eines Users nicht einsehen.

Die Gefahr besteht dann wenn der Angriff auf der Seite mit dem Formular stattfindet.
Dann steht der Token nämlich in der Session und gleichzeitig im Formular.

Von was für einen Angriff genau sprichst du. Reden wir noch von CSRF?

Und wenn der Token in der Session gespeichert ist, kann der Angreifer unter der Session Formulare absenden.

Durch CSRF kann der Angreifer zwar POST-Requests mit gewissen Formulardaten abschicken (z.B. ein POST-Request mit application/x-form-urlencoded). Bei reinem CSRF ist dem Angreifer der CSRF-Token aber nicht einsehbar. Also ist es ihm nicht möglich, den Token in die gefälschten Formulardaten zu schreiben. Der Browser sendet zwar automatisch den Cookie-Header mit der Session-ID, aber nicht den CSRF-Token. Der muss Teil des POST-Bodys sein (= der übertragenen Formulardaten).

Von XSS und MITM-Angriffen abgesehen kann ein Angreifer nicht Formulare auslesen und absenden, wie sie vom Ursprungsserver generiert werden. Im Browser kann ich nicht einfach eine andere Site in einem iframe laden, dort Quatsch in ein bestehendes Formular schreiben und es absenden. Das verhindert die Same-Origin-Policy. Ich kann nicht auf die DOM-Objekte der fremden Site zugreifen.

Wenn der Angreifer hingegen die Session-ID aus dem Cookie ergattern kann, hat er so gut wie gewonnen. Dann braucht er kein CSRF zu versuchen, welches ja immer ein Opfer benötigt, das mit seinem Browser die präparierte Site des Angreifers öffnet und gleichzeitig bei der Zielseite eingeloggt ist. Sondern er kann direkt Requests an die Zielseite schicken und die Session übernehmen.

Mir scheint, du unterliegst einem ähnlichen Missverständnis wie Norman.

Grüße,
Mathias