nicht angemeldet
Hi Sven,
dran zu kommen müßte man nicht nur an irgendwelche
Logfiles kommen, sondern an einem der Rechner oder
irgendwo dazwischen lauschen, was meiner Meinung
nach ein ganz erheblicher Unterschied ist!
dasselbe gilt aber auch für den UserAgent - beides
sind HTTP-Header.
EBEN NICHT!!! Der USer-Agent wird oft in Logfiles direkt
neben dem referer geschrieben, da hat man ja direkt beides
zusammen, da braucht man dann nicht mehr viel raten, daher
meine Bedenken in diese Richtung!
Der Cookie dagegen kann nur durch lauschen "abgefangen"
werden, IMHO ein erhebliche Unterschied! Oder wo werden
cookies geloggt????
Man kann Cookies auch loggen. Man kann so ziemlich alles loggen,
was der Webserver erfährt. Apache ist da sehr flexibel.
das ist wahr - aber in diesem Falle nicht relevant.
Richtig ist, daß der Betreiber eines Webservers sein Log-Format so
definieren kann, daß jeder einzelne HTTP-Header dort geloggt wird.
Was den Cookie allerdings von anderen Headern - auch dem UserAgent
- unterschiedet, das ist, daß er eben _nicht_ an _jeden_ Server
gesendet wird, sondern nur gemäß seiner Definition (und diese kann
und wird normalerweise so lauten, daß der Cookie nur an denjenigen
Server zurück gesendet wird, der ihn erzeugt hat).
Insofern unterschiedet sich der Cookie tatsächlich von anderen
HTTP-Headern, weil er auf der Maschine eines Angreifers nicht an-
kommt und _deshalb_ dort nicht gelogt werden kann.
Was natürlich nicht bedeutet, daß der Cookie _nirgendwo_ geloggt
werden kann.
Er wäre beispielsweise dann zu loggen, wenn auf dem Weg zwischen
Client und Server ein Netzknoten (Proxy etc.) existiert, der unter
der Kontrolle des Angreifers steht.
_Dort_ kann _alles_ geloggt werden - auch ein Cookie.
ich gehe jetzt von dem Szenario aus, das ich mit SSL
verschlüssel. Das heißt, lauschen ist wirklich nur mit
sehr hohem Aufwand möglich, denke ich.
Aber für einen professionellen Angreifer ist auch SSL nicht
unknackbar.
Eine man-in-the-middle-Attack würde dem Angreifer möglicherweise
erlauben, sich auch in eine SSL-Kommunikation einzuklinken und
diesen Dialog "zu übernehmen", d. h. nach beiden Seiten das SSL-
Protokoll korrekt zu bedienen, aber alles mitzuschreiben (oder
sogar direkt seine eigenen Änderungen auf den Dialog anzuwenden).
Jetzt ist nur noch die Frage, ob es noch Sinn macht zu der
Session ID, die wenn möglich auch in einem cookie übertragen
wird, noch den User-Agent zu verwenden - bringt das noch
einen großen Gewinn an Sicherheit?
Gemäß Deinem Szenario, in dem der Angreifer perfekt rät, auf
welchen Informationen Dein Verfahren beruht, nein.
Ich weiß jetzt nicht wie groß sich der Aufwand eine SessionId
aus Logfiles oder wie auch immer zu bekommen, vom Aufwand die
SessionID + dazugehörigen User-Agent zu bekommen, unterscheidet.
Dieser Aufwand ist auch nicht in CPU-Ticks zu messen, sondern in
Meta-Wissen über Dein Verfahren zur Erzeugung der Session-ID.
Wenn Du dieses Verfahren offen legst, dann ist der zusätzliche
Aufwand gleich Null. Wenn nicht, dann nicht ...
get_browser() untersucht den User-Agent und zieht aufgrund dessen
Informationen aus einer lokalen Datenbank.
Damit gewinnst du nichts, sondern generalisierst.
Full ACK.
Viele Grüße
Michael