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.
Die Kombination Username/Passwort bei .htaccess ist nicht besser. Statt einer Session-ID wird eben diese Info übermittelt, und der Server liefert was aus. Ist .htaccess etwa auch schlecht?
Warum? Weil in der URL alle Informationen codiert
sind, die auch der reguläre Browser mitsenden würde.
Genau das ist der Fehler dabei.
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.
Das bietet aber keine zusätzliche Sicherheit. Wenn der Angreifer ganz stumpf den kompletten HTTP-Header des Browsers kopiert (was ja nicht ausgeschlossen werden kann, vor allem, wenn dieser Mechanismus bekannt ist - Security by Obscurity war noch nie ein guter Ratgeber), dann kriegt er ebenso Zugriff.
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.
Es wurde vermutet, daß Proxyserver möglicherweise einen Zeitstempel irgendwo reinsetzen könnten. Wäre dann nicht gut für die Funktionalität, und Benutzer könnten darauf möglicherweise keinerlei Einfluß haben, weil sie den Proxy zwingend benutzen müssen.
Wie gesagt: Man kann Session-IDs raten. Man kann Username/Paßwort raten. Wer ungestört andere eine Million mal raten läßt, ist selber Schuld. Bei der nur vierstelligen Geldautomaten-PIN hat man drei Versuche bei 10.000 Möglichkeiten. Es wäre kein Beinbruch, bei 10^38 Session-IDs einfach 10 Rateversuche zu erlauben, und danach die Kommunikation einzustellen. Hattest du ja aber schon selbst gefordert. Ich denke nicht, daß zusätzliche Merkmalsprüfung die Sicherheit wirklich qualitativ erhöht - sie erhöht den Rateaufwand, weil mehr gesendete Informationen übereinstimmen müssen. Wer die Session-ID mittels Referrer auf seinen Server locken kann, kriegt grundsätzlich alle HTTP-Header des Browsers übermittelt und kann sie zum Angriff einsetzen - wo ist da die zusätzliche Sicherheit?
- Sven Rautenberg