nicht angemeldet
Moin!
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 ;-)
Wenn die Session-ID mit GET übermittelt wird, weil der User keine Cookies akzeptiert, dann gelangt die Session-ID über den Referrer auch woandershin.
Wenn Cookies verwendet werden, natürlich nicht. Insofern ist die Methode mit Cookies natürlich besser, weil der Browser diese Daten im Cookie wirklich nur an den entsprechenden Server zurücksendet (oder wahlweise an Server dieser Second-Level-Domain), aber sicher ist es dadurch natürlich noch lange nicht. Nur die Session-ID im Cookie kann ebenfalls geraten werden. Da sollte dann doch lieber der Timestamp der Anmeldung mit reingeraten und verschlüsselt werden. Den Timestamp kann dann nur der Server generieren, und nur wer sich ordentlich angemeldet hat, kann arbeiten.
Wenn die Sicherheit es erfordert, muß man eben Cookies zur Pflicht machen.
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?
Ja, Proxys könnten da was reinfummeln. Aber wie häufig und wahrscheinlich ist das? Und was passiert, wenn es tatsächlich gemacht wird? Wenn man die Möglichkeit voraussieht und sich entsprechend darauf einstellt, dann ist das zwar auch ein Problem, aber nur ein relativ kleines für eine sehr begrenzte Zahl von Benutzern. Und wenn man das Problem durch Umgehen des Proxys abstellen kann - ok. Wer das nicht kann - Pech. Lieber gewisse Mindestforderungen stellen, als unsicher werden, oder?
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?
Eben, die meisten Browser akzeptieren nun mal text/html, image/gif, image/jpg und */*. Nur sehr selten tragen sich hier Plugins ein, die dann ebenso auftauchen - dazu wird diese Browserangabe viel zu selten ausgewertet. Ich habe beispielsweise noch von keinem Server gehört, der dem Browser wahlweise GIF, JPG oder PNG liefert, je nach Wunsch. Das wäre viel zuviel Aufwand für den Ersteller (der sich entweder für GIF entscheidet, weil er transparenz braucht oder Schriften hat, oder für JPG, weil Fotos vorliegen). Es lohnt also kaum, sich hieran zu orientieren, die Angaben sind zu ähnlich.
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?
Du hast dann immer noch einen riesigen Bereich des Internets, aus dem gleichzeitig Benutzer und Angreifer kommen könnten. 62.0.0.0/8 ist beispielsweise der Beginn von IP-Adressen in Israel, Griechenland, der Schweiz... ich hab nurmal kurz angetestet, was ripe.net dazu sagte. Deutschland ist auch vertreten.
Letztendlich ist eine IP-Adresse leider kein eindeutiges Kennzeichen eines Benutzers. Ein Benutzer kann mehrere IPs benutzen, und mehrere Benutzer eine einzige.
Ü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?
Bingo, daran hatte ich irgendwie nicht gedacht. Allerdings weiß das der Angreifer natürlich nicht, und ein schlaues System wird den Einloggversuch mit falschen Daten bei gleichzeitig aktiver Session mit richtigen Daten registrieren und evtl. Warnungen aussprechen oder die Session beenden und eine Neuanmeldung verlangen.
Naja, letztendlich stimmt in solch einem Fall was an der Sicherheit nicht, und diese obige Idee wäre ein Nachreparieren, wo vorher grundlegende Konstruktionsfehler gemacht wurden. Außerdem kann das wieder mal bei flexiblen Benutzern (z.B. zweiter Browser des gleichen Benutzers, URL per Copy&Paste übertragen -> User-Agent unterschiedlich) zu Fehlern führen, die nicht sein müssen.
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?
Anscheinend nicht so einfach. Im Prinzip wirklich nur mit Cookies. Der Cookie wird, genau wie die Useranmeldung bei .htaccess, ausschließlich an den jeweiligen Webserver gesendet, und zwar im HTTP-Request. Keine dieser Daten gelangen durch irgendwelche Datenlecks wie Referrer etc. an andere Webserver, da zum Glück entsprechende Sicherheitsvorschriften gemacht wurden. Das System kann nur kompromittiert werden, wenn der Angreifer die Kommunikation zwischen Benutzer und Server abhören kann.
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.
Das ist alles nichts. Wie findest du raus, daß Javascript aktiv ist? Du läßt eine externe Javascript-Datei laden. Wie kriegst du diese Information eines vollkommen separaten Requests in die eigentliche Sessioninformation mit hinein? Wohl garnicht. Was, wenn der Benutzer beim Anmelden JS ausgeschaltet hat und es aus irgendwelchen Gründen zwischendurch einschaltet - oder umgekehrt? Eben...
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 ;-)
Ich will dich ja nicht beunruhigen, aber bei md5 kommt doch immer ein String konstanter Länge heraus. Der ist zwar wesentlich länger, als der bei Crypt, aber er ist konstant. Folglich bietet er nur eine begrenzte Anzahl an verschiedenen Variantionen von Zeichen. Und entsprechend gibt es die Möglichkeit, daß zwei verschiedene zu verschlüsselnde Texte das gleiche MD5-Ergebnis haben. MD5 ist doch genauso eine Einweg-Crypto-Hash-Methode wie crypt(). Nur daß man wesentlich länger sucht.
Aber crypt verstehe ich selbst nicht richtig, wenn ich ein Passwort mit crypt() verschlüssele, bekomme ich immer einen anderen String?!?!? Wieso überhaupt?
Es wird zusätzlich zum zu verschlüsselnden Paßwort noch ein Salz-Wert hinzugefügt. Das sind die ersten beiden Zeichen des Ergebnisses. Wenn du ohne Salz-Angabe crypt() verwendest, werden zufällige Werte als Salz genommen (wahlweise auch immer derselbe Wert).
Und was ich dann noch weniger verstehe, wenn ich vergleiche:
if($crypt_pw==crypt(klartext_pw)
Du mußt eben dafür sorgen, daß das Salz identisch ist, indem du einfach das verschlüsselte Paßwort als Salzwert an crypt() mit übergibst. Crypt wird die ersten beiden Zeichen als Salz verwenden.
Sinn des Salzwertes ist es: Wenn unterschiedliche Salzwerte genommen werden, sehen gleiche Paßwörter verschlüsselt trotzdem unterschiedlich aus. Eine reine Maßnahme fürs Auge scheinbar.
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?
Wenn crypt beispielsweise nur die ersten 8 Zeichen des Paßwortes verschlüsselt, sind logischerweise alle längeren Paßwörter mit dem nur 8 Zeichen langen Fragment identisch. "Kammerspiele" und "Kammerspaß" wären gleich.
Ebenso: Wenn crypt nur 8 Zeichen Ergebnis hat, und als Zeichenvorrat nur kleine und große Buchstaben auswirft, sowie die 10 Ziffern, dann gibts 62 verschiedene Zeichen. Insgesamt bei 8 Zeichen also 218.340.105.584.896 verschiedene Ergebnisse von crypt() (das Salz kennt man ja, wenn man das verschlüsselte Ergebnis hat, spielt also keine Rolle bei Angriffen).
Man kann sich aber vorstellen, daß es bei unbegrenzter Länge des Paßwortes ganz sicher unendlich viele Paßwörter gibt. Unendlich viele Inputvarianten werden auf 218.340.105.584.896 Outputvarianten gemappt - da gibt es Dopplungen im Ergebnis, ganz klar. Wie lange man dafür suchen muß, kann ich aber nicht sagen.
- Sven Rautenberg