Passwortseite mit Übergabe an .htaccess

[Michael Schröpl]

Hi Sven,

Der Angreifer sieht folgenden Referrer-Bestandteil:
?SESSID=lkgsedfzuiz2978swefhiase67aw4a8wrhiuaw4zp98zhuiaw4z879paw4
Frage: Welcher Teil dieses Strings ist die
eigentliche Session-ID, welcher Teil ist der
Timestamp, und welcher Teil ist der User-Agent?
Oder welche anderen Teile sind dort verwurstelt?
Die Antworten auf die Frage ist total egal.
Wenn man den Referrer im Browser aufruft, dann führt
diese Session-ID dazu, daß der Server eine Seite
ausliefert.

Das ist dann aber ein schlechter Session-Mechanismus.

Warum? Weil in der URL alle Informationen codiert
sind, die auch der reguläre Browser mitsenden würde.

Genau das ist der Fehler dabei.

Es ist vollkommen uninteressant, ob der Server die
ID zerlegt, einen Zeitstempel prüft, oder sonstwas
an den Browsereigenschaften (wobei die ja alle nicht
zuverlässig genug sind, weil entweder zu
veränderlich, wie die IP oder der User-Agent, oder
zu wenig verschieden, wie die Liste der akzeptierten
MIME-Typen): Diese komplette ID (sei sie nun
komplett oder bereits vorzerlegt) erlaubt den
Zugriff auf den Server - der reguläre Benutzer
kriegt ihn ja schließlich.

Nein. Der reguläre Benutzer bekommt den Zugriff genau
dann, wenn der Server ihm diesen erlaubt.
Und genau wie bei Server Authentication oder Content
Negotiation ist der URL eben _nicht_ eine hinreichende,
eindeutige Beschreibung der Ressource, sondern die
restlichen HTTP-Header können den Effekt der Anforde-
rung beliebig beeinflussen.

Wenn der Server die Session-ID so zerlegen kann, daß
er prüfen kann, ob die restlichen HTTP-Header dazu
passen, dann kann er dem normalen Benutzer den Zugriff
erlauben und dem Angreifer den Zugriff auf denselben
URL verbieten.

Erst vor ein paar Tagen hatte Sabine Pekarz einen
schönen langen Thread zu diesem Thema im Forum gestartet, wo wir darüber diskutierten, welche Felder des HTTP-Request als zusätzliche Prüfsummen taugen - mit dem Tenor "je variabler die Werte, desto besser".
Also in erster Linie der UserAgent. Daß der Benutzer
dessen Wert verändert kann, schadet doch nichts -
solange er das nicht innerhalb einer Session tut.

Viele Grüße
      Michael