nicht angemeldet
Hi Sven,
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?
für ein Szenario, in dem HTTP-Header belauschbar sind,
ist Server Authentication nicht toll.
"Basic" ist ganz mies; "Digest" ist immerhin kopierbar,
ohne daß auf dem Server noch irgend eine Plausbibili-
tätsprüfung erfolgt (denke ich - oder?).
Bei beiden muß ein Angreifer, der lauschen kann, über-haupt nicht würfeln; von einer Session-ID erwarte ich
eigentlich mehr.
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.
Dazu muß er aber den HTTP-Header des normalen Besu-
chers belauscht haben! Wenn er das nicht kann, dann
kann er tausend Jahre lang erfolglos Passworte würfeln.
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.
Eben - deshalb ist das Mitsenden von Informationen,
von denen der Angreifer gar nicht weiß, daß er sie
auch noch fälschen, d. h. auswürfeln muß, durchaus
eine Verbesserung des Verfahrens.
Die Session-ID zeigt dem Angreifer doch durch ihre
Länge immerhin die Größe des auszuwürfelnden Pass-
wort-Raums - falls jedoch weitere Anforderungen not-
wendig sind, von denen der Angreifer nichts weiß,
würfelt er automatisch falsch.
Ich denke nicht, daß zusätzliche Merkmalsprüfung
die Sicherheit wirklich qualitativ erhöht
Ich schon - allerdings nicht in beliebigen Szenarien.
Wenn der Angreifer mitlauschen kann, dann nützt so
etwas natürlich weniger.
Deshalb meinte ich ja, daß für den Aufbau einer Ver-teidigungsstrategie immer auch eine Vorstellung über
die Art des Angriffs notwendig ist.
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?
Daß er wissen muß, daß er diese Information braucht.
Er muß den Original-Request so genau nachbauen wie
möglich, weiß aber nicht, wie das geht. Und vor allem
erfährt er während seines Würfelns nicht, daß sein
Verfahren hoffnungslos ist.
Er hat keine exakte Aufgabenstellung - ginge es nur
darum, eine Session-ID zu brechen, dann hätte er eine.
Viele Grüße
Michael