Wer schaut schon so genau auf den Link, den er in einem Forum zu einem Produkt findet? Und wer prüft die ZielURL einer KurzURL, die er auf Twitter gesehen hat? Kaum jemand! Und wer kennt es nicht, man bekommt im Chat einen Link und nach dem Aufruf ist man plötzlich eingeloggt, obwohl man die Seite bisher noch nie gesehen hatte?!

Ein session=1d9a3bb5ab01785e1cf3a1bqf029a580 welches in einer URL steckt, sieht irgendwie auch nicht wirklich gefährlich aus!? Oder doch?! Gibt es Sicherheitslücken in einer Webanwendung, so kann diese Lücke schon dazu führen, dass ein Angreifer in den Account seines Opfers eindringen kann.

Bei Session Fixation (de.wikipedia.org) wird die Session-ID vorgegeben, d.h. der Angreifer muss keine Session ausspähen, er braucht kein Cross-Site Scripting (de.wikipedia.org) um per document.cookie an die Session zu gelangen oder sonstige Methoden zum ausspähen der Session – er kennt sie ja.

Gegenmaßnahmen sind:

• Keine Session-ID per GET oder POST entgegennehmen.
• Eine Session sollte erst vergeben werden wenn es sinnvoll ist.
• Eine bestehende Session-ID nach dem Login erneuern.

Es ist schon interessant zu beobachten; obwohl ich vor vielen Jahren (Chat… Freund… etc.) eher per Zufall über solche Lücken gestolpert bin – es gibt sie noch immer – auch in neuen Seiten.


Was ich in “Session Hijacking verhindern” geschrieben habe, war zwar nicht kompletter Unsinn, aber der Punkt 4… naja… ein großer Haufen Bullshit, so einfach ist es nun doch nicht, Session Hijacking zu verhindern. :O)

Wenn man erfolgreich Session Fixation und Cross-Site Scripting verhindert, so sollte man damit auch Session Hijacking fast unmöglich gemacht haben.