Hi!
Danke, etwas für die Sammlung ;)
Den Eindruck gewinnst Du deshalb, weil ich mich neben der Sicherheit, auch um die Performance kümmere. Ich will also die Sicherheit, aber nur mit der bestmöglichen Performance. Daher überdenke ich aktuell alle bestehenden Routinen.
Ich kenne mich im Hacking ganz gut aus. Also external file inclusion, internal file inclusion, xss oder mysql injection ist alles kein Thema. Ich weiß auch worauf es bei Cookies ankommt, habe nur aktuell Probleme mit FF3 und Opera 9, weil bei mir die Autologin-Cookies (aus Sicherheitsgründen) bei jedem View überschrieben werden. Die beiden Browser mögen das nicht. FF3 nimmt irgendwann identische Cookies doppelt an und Opera 9 sperrt gänzlich den Zugriff auf das Cookie. Beides vermutlich Browser-Bugs, aber sie treten jetzt schon so oft auf, dass ich mein System grundlegend ändern möchte.
Und nun habe ich bei vB gesehen, dass dort dieses Problem nicht existiert (weil das Autologin-Cookie immer die gleichen Daten enthält und nie überschrieben wird).
Nur was ich interessant fand ist, dass ich das Cookie eines Freundes nicht "stehlen" konnte. Und das ist das was ich mir aktuell nicht erklären kann, weil wir beide FF3 hatten. Mittlerweile bin ich durch meine eigenen vBulletin-Versionen (3.6.1 und 3.7.0 Beta) und einer umfassenden Recherche der Meinung, dass die sha-Variante, die ich bei jemanden gesehen habe, gar nicht von vBulletin stammt, sondern eine Eigenentwicklung ist. Deswegen versuche ich mich mal in der Modifikation einzelner Header, um herauszufinden, was dort verarbeitet wird und was nicht.
Das ein Autologin-Cookie keine wirkliche Sicherheit bietet, weiß ich selber, aber wenn das Cookie nach dem Diebstahl nicht funktioniert, hemmt das erstmal enorm.
Aktuell dachte ich daran die user_id und das pw jeweils als hash in Cookies zu hinterlegen. Und zwar so:
PHP-Code:
if ($user_browser_version >= BROWSER_VERSION) {
$user_pw_hash = md5(FILE_SALT . BROWSER_NAME . OS_NAME . PROVIDER_NAME . USER_SALT . md5(USER_PW));
$user_id_hash = md5(FILE_SALT . BROWSER_NAME . OS_NAME . PROVIDER_NAME . USER_SALT . md5(USER_ID));
}
Legende:
FILE_SALT = Dieser Salt kommt aus einer Datei. Der Hacker benötigt also FTP-Zugriff um den Hash nachzubilden. Wenn sich diese Datei dann noch außerhalb des Roots befindet, ist die Sache "perfekt".
BROWSER_NAME = Hier nur die "Marke" des Browser (ie, ff, opera, usw.). Nur die Marke, damit der Autologin nach einem Update auch noch funktioniert. Verhindert zum Teil den Cookie-Diebstahl, weil der Browser des Diebes identisch sein muss.
BROWSER_VERSION = Enthält die Browserversion des Besuchers, während $user_browser_version, die Version des letzten Logins enthält. Das Cookie wird nur dann akzeptiert, wenn die übermittelte Browserversion größer oder gleich der vom letzten Login war. Sofern also jemand das Cookie klaut und eine ältere Version einsetzt, wird das Cookie abgelehnt.
optional PROVIDER_NAME = Hier die "Marke" des Providers (arcor, telekom, aol, etc.). Der einfachste Weg wäre es die letzten 6 Stellen des Hostnamens zu extrahieren (in den Logfiles war "qsc.de" das Kürzeste, was ich finden konnte). Das Problem ist nur, dass gethostbyaddr() ziemlich lahm sein kann (falls IP nicht im DNS / DNS nicht erreichbar) und daher sollte man alle IPs nur einmal prüfen. Das gibt dann recht viele Datensätze, ist also unter Umständen etwas suboptimal. Auch kann ein Nachteil an der Sache sein, dass der User ausgeloggt ist, sofern er sich in verschiedenen Netzen bewegt. z.B. mit seinem Laptop im Büro und dann noch mal zu Hause. Das bekommt man in den Griff, wenn man mehrere Hosts zulässt z.B. max. 2. Auch das schützt vor Cookie-Diebstahl. Der Hacker müsste sich mit dem gleichen Provider einloggen, damit er das Cookie gebrauchen kann.
optional OS_NAME = Hier der Typ (2000, XP, VISTA, MAC, usw.). Ansonsten identisch mit BROWSER_NAME.
USER_SALT = Dieser Salt ist Teil der User-DB-Tabelle und demnach Unique
$user_id_hash = Auch als Hash, damit ein gestohlenes Cookie keinem bestimmten User zugeordnet werden kann.
P.S. die Sache mit dem besagten vBulletin-Forum ist übrigens geklärt. Dort wird der komplette HTTP_USER_AGENT als Salt verwendet. Entsprechend ist nach einem Update des Browsers oder nach einer Installation eines Plugins, dass den USER_AGENT beeinflusst (z.B. Office), der Autologin nicht mehr aktiv. Die letzte Bestätigung werde ich dazu bekommen, sobald es wieder ein Update von FF gibt.