nicht angemeldet
Hi!
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.
war aber gefährlich, hätte ich fast überlesen, und das wäre wirklich schade gewesen :-)
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.
Oh weh! Aber das kann dochnicht wirklich sein oder? Warum sollte der Link die SessionID des eigeloggten users mitliefern? Außerdem ist das ja dann großer Zufall, vielleicht könnte man dann mal bei nem Freund "Einbrechen", das ist lustig, bringt aber nicht viel ;-)
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.
Aber das hörte sich gerade bei Cheatah etwas anders an, ich zitiere(http://forum.de.selfhtml.org/?m=74151&t=13365):
Warum denn nicht den HTTP_USER_AGENT???
der Header kann beliebig verändert, also auch z.B. von einem Proxy mit dem Timestamp versehen werden. In dem Fall würde die Erkennung versagen.
Was sagst Du dazu?
Das in einer SessionID mehrer IPs vorkommen können, habe ich da "bewiesen"(am besten liest Du vorher die Korrektue :-):http://forum.de.selfhtml.org/?m=74285&t=13365):
http://forum.de.selfhtml.org/?m=74280&t=13365
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. :)
Ich meinte auch nur wenn ich das speichere, aber das muß man ja nicht lange speichern, hatte ich nicht daran gedacht. Aber der Vorteil hier wäre wohl, das das von keinen proxies... zwischenruch verändert wird, oder? Ist nur die Frage, wie berechtigt Cheatah´s Kritik daran war, das es davon nur sehr wenige Kombinationsmöglickeiten gibt. Wie ist das Wohl im Verhältnis zum User_Agent? Ich denke auch da machen bestimmt 50-100 Verschiedene 80-90% der Besucher aus, oder? Also keine besonders große Herausforderung an einen Hobby-Cracker, oder?
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.
Hat wohl auch keinen Sinn, wenigstens die ersten beiden Zahlen der IP auszuwerten, das hätte in meinem obigen Beispiel funktioniert, wird aber wohl bei T-Online auch anders sein können, das man von ner 80... auf ne 195... kommt, in einer Session, oder?
Überlege nochmal die Aufgabenstellung: Wie kann man serverseitig verhindern, daß andere User einfach die Session übernehmen bzw. mitsurfen?
Man muß eine Möglichkeit haben, Daten die der Client _immer gleich_ mitsendet, und die möglichst differenziert sind auszulesen.
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.
Aber nur mal angenommen ein Angreifer bekommt die SessionID aus dem Referer-Eintrag in irgendwelchen log-Files, da steht der Agent doch direkt daneben, oder?
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.
Aber mir ginge es mal um eine Lösung ohne .htaccess, das diese Lösung optimal ist ist mir bewußt, aber man muß doch wenigsten einigermaßen mit anderen Mitteln ähnliche Sicherheit erreichen können, oder?
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.
Aber wenn der sich jedesmal duch den Timestamp eines Proxy ändert? das wäre schon schwierig dem User zu erklären (zumindest automatsich)!
Man braucht eindeutige Angaben des Browser. Was ist denn mit solchen Sachen wie akzeptiert Cookies, Javascript... was es da so alles gibt, das wird sich doch auch nicht über die Session ändern, oder? Wenn man daraus irgendwie was strickt? Nur leider gibt es ja immer nur 2 Möglichkeit bei sowas, an/aus, also auch nicht wirklich sehr verschieden, was? Was gibt es denn evtl, was sehr verschieden ist(viele Möglichkeiten), aber auf alle Fällte immer konstant an den Server gesendet wird? Die IP wäre so genial, aber fällte denke ich aus besagten Gründen raus.
Ein Paßwort mit MD5 verschlüsselt auf dem Server abzulegen macht mehr Sinn.
Das mache ich sowieso! War das mit dem Hash aus Username und Passwort und as ganze verschlüsselt speichern! Alles drum herum mit SSL.
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).
Daher verwende ich ja md5() - da gibt es nur eine Möglichkeit ;-)
Aber crypt verstehe ich selbst nicht richtig, wenn ich ein Passwort mit crypt() verschlüssele, bekomme ich immer einen anderen String?!?!? Wieso überhaupt?
Und was ich dann noch weniger verstehe, wenn ich vergleiche:
if($crypt_pw==crypt(klartext_pw)
MUSS da doch eine Ungleichheit rauskommen, oder? Die Wahrscheinlichkeit das das wieder gleich verschlüsselt ist doch fast = 0, oder? Aber es funktioniert trotzdem, wieso?
Und anders herum ist das ja schlimm, wenn auch andere Wörter den gleichen crypt() String ergeben, ist das dann tatsächlich der gleiche String, oder auch noch ein anderer der irgendwie passt(so wie oben!!!) Aber das wäre ja richtig schlimm! Weißt Du wie das Verhältnis ist, echtes_Passwort:passendes_anderes_Passwort?
Vielen Dank für dein hilfreiche Antwort!
Viele Grüße
Andreas
- Sven Rautenberg