nicht angemeldet
Moin!
Ich hänge mich mal hier an (hab die nachfolgenden Postings wohl gelesen, nehme vielleicht auch versteckt darauf Bezug), hier scheint der passendste Platz dazu.
Eine Frage zu htaccess:
Die Passwörter werden auf dem Server ja verschlüsselt gespeichert. Wie funktioniert das dann bei der Eingabe, wird das was in das Fenster eingegeben wird direkt als username:crypt(passwort) im Arbeitspeicher abgelegt, oder im Klartext, und auch im Klartext übertragen, wenn man kein SSL benutzt?
Wie die Paßwörter auf dem Server gespeichert werden, ist primär uninteressant. Interessant ist: Wie kommen die Paßwörter vom Client zum Server. Und das läßt sich leicht beantworten:
AuthType Basic: Unverschlüsselt (!!!)
AuthType Digest: Verschlüsselt durch ein Challenge-Response-Verfahren. Die eigentliche HTML-Seite wird aber trotzdem unverschlüsselt ausgeliefert.
Bei SSL wird die Verschlüsselung auf einer tieferen Ebene realisiert, also sind alle Datenübermittlungen deshalb verschlüsselt. Frag mich nicht, wie Proxys das hinkriegen (https erfordert andere Proxys als normales http, und diese Proxys dürfen auch nichts speichern).
Und noch eine Frage wegen das anderen postings: Du sagst ein Problem ist wenn die SessionID in den Log-Files irgendwelcher Proxies... stehen, korrekt? Aber die Session wird doch rel schnell wieder gelöscht, wenn nicht mehr benötigt, das müßte also sehr zeitnah passieren, oder?
Wie lange ist die Session denn noch gültig, nachdem sie irgendwo in ein anderes Logfile geschrieben wurde? Das ist doch das Problem. Wenn jemand ein Webmail-Interface mit Sessions geschrieben hat, und ein Benutzer kriegt eine HTML-Mail mit Bildlink, der ein Bild auf dem Angreiferserver verlinkt, dann taucht dort der Referrer auf und liefert möglicherweise die Session-ID mit.
Wenn weiterhin anzunehmen ist, daß der User noch etwas mit Maillesen beschäftigt ist, ist jetzt genügend Zeit, die Sessiondaten zu übernehmen und als angemeldete User-Kopie ebenfalls in der Post zu stöbern.
Man kann, sofern die Implementierung des Mechanismus absolut mangelhaft ist, sogar das Paßwort ändern. Nämlich dann, wenn dem angemeldeten Benutzer einfach durch Angabe des neuen Paßwortes gestattet wird, es zu ändern, aber nicht mehr nach dem alten Paßwort gefragt wird. Schwups - der Mailaccount gehört dem Angreifer.
Erst wenn sich der reguläre Benutzer abmeldet und der Server die Session für ungültig erklärt (und daher keine weiteren Seiten für diese Session ausliefert), hat der Angreifer ebenfalls keinen Zugriff mehr. Aus genau diesem Grunde erzählen alle Webmail-Anbieter wie GMX oder web.de ihren Benutzern immer, wie wichtig es ist, daß man sich nach der Benutzung abmeldet und ordentlich ausloggt. Andernfalls würde die Session weiterhin bestehen und bis zum Timeout für Angreifer offen sein (sofern diese Anbieter wirklich so schlechte Interfaces haben, wie hier beschrieben - ich denke, das ist nicht der Fall).
Und wenn ich SSL verwende, wird dieses Risiko dann ausgeschaltet? Was steht dann in den Refers? Der Proxy... muß aber doch irgendwie wissemn, wohin er weiterlieten soll, un dwenn der das weiß kann das doch auch geloggt werden, oder?
Die Brücke zwischen https und http wird AFAIK nicht geschlagen. Wenn du auf einer https-Seite einem Link folgst, kriegt die verlinkte http-Seite keinen Referrer übermittelt. Natürlich kriegt der jeweilige https-Server alle Referrer, die lokal auf dem Server bezogen sind - serverübergreifend wird IMHO nichts übermittelt.
Um das alles noch etwas sicherer zu machen, könnte ich ja evtl den kpl. HTTP_USER_AGENT verwenden. Ich hab mal in der phpinfo() geguckt, was wir da so alles schönes haben, in Frage kämen meiner Meinung:
HTTP_USER_AGENT - sehr verscheiden - gut geeignet, oder?
Der ist einigermaßen konstant bei der Mehrzahl der Benutzer. Und vor allem ist nicht zu erwarten, daß er sich zwischendrin ändert - jedenfalls nicht bei jedem Request.
HTTP_ACCEPT - genau so, vielleicht etwas lang, oder?
Die Länge ist ja nicht unbedingt entscheidend. Die Frage ist, was du mit der Info machst. :)
REMOTE_ADDR - auch gut, aber was ist mit Proxys? Kann es nicht vorkommen, das die Adresse während des Besuches wechselt? ich meine jetzt nicht dyn IP-Vergabe, da ist die session eh zu Ende, oder? Wie ist das mit der IP?
Die Adresse kann sich während einer Session ändern - das ist IMO sehr häufig, zumindest zu häufig, um darauf eine zusätzliche Sicherung aufzubauen.
REMOTE_PORT Da weiß ich nicht, ob der immer gleich bleibt, wie ist das, wonach werden die Ports aufgeteilt?
Der Port ändert sich potentiell bei jedem Request, ist also völlig ungeeignet.
Überlege nochmal die Aufgabenstellung: Wie kann man serverseitig verhindern, daß andere User einfach die Session übernehmen bzw. mitsurfen?
Wenn der Browser vom Server einfach nur eine beliebige Nummer (Session ID) bekommt und diese Nummer immer wieder mitsendet, wenn er was vom Server will, dann kann ein Angreifer versuchen, die Nummer zu raten (und bei gutbesuchten Servern mit mehreren hunderttausend Sessions gleichzeitig ist die Chance dazu natürlich sehr gut).
Wenn der Server aber ein relativ eindeutiges Merkmal des Browsers mit zur Identifikation heranzieht (also z.B. den User-Agent), dann muß der Angreifer schon zwei Dinge richtig wissen: Erstens die Session ID, und zweitens den exakten User-Agent.
Genau das gleiche liegt vor, wenn per .htaccess vom Browser bei jedem Request Username und Paßwort gesendet werden - auch das muß der Angreifer raten.
Man kann natürlich argumentieren, daß keine der Browserangaben wirklich konstant ist, die Username/Passwort-Kombination hingegen schon. Was wäre die schlimmste Konsequenz? Beim Surfen wird sich der User im ersten Fall zwischendrin (nämlich wenn sich der User-Agent irgendwie ändert) nochmal neu anmelden müssen, was ihm durch eine erklärende Fehlermeldung ja einfach erklärt werden könnte.
Es reicht ja immer zu wissen, ob sich eher die Session beenden würde, als das sich z.B. der Port ändert. Weißt Du wie das ist? OK, von diesen Daten speichere ich dann eine bestimmte Kombination in der Session und das prüfe ich jedesmal, oder? Hat es Sinn, das noch mit MD5() zu verschlüsseln?
Auf dem Server die Info verschlüsseln macht nicht unbedingt viel Sinn, wenn du dem Server vertraust. Die Info über den regulären User-Agent der Session ist flüchtig, kann beim nächsten Anmeldevorgang schon wieder ganz anders aussehen. Außerdem ist es ein zusätzliches Merkmal zur Sicherung der Session, kein authentifizierendes.
Ein Paßwort mit MD5 verschlüsselt auf dem Server abzulegen macht mehr Sinn. Paßwörter werden in der Regel (leider) für eine lange Zeit benutzt, man sollte also in jedem Fall verhindern, daß für den unwahrscheinlichen Fall des Einbruchs in den Server gleich die Paßwörter im Klartext vorliegen und den Einbrechern direkt in die Hände fallen. Allerdings sind Mechanismen wie crypt() nicht mehr wirklich sicher - mit genügend Rechenpower sind solche Paßwörter in recht kurzer Zeit geknackt (wobei anzumerken ist, daß dabei nicht das Originalpaßwort wiederentstehen muß, sondern ein x-beliebiger Wert gefunden werden kann, der ebenfalls den gleichen crypt-Wert ergibt).
- Sven Rautenberg