schuld is vermutlich die session Idda die bei google mit erfast wurde konnte man rein das ist natürlich echt übel ^^
schuld is vermutlich die session Id
schreib deinen betreiber mal an der soll die session id abschalten das die ned immer angezeigt wird damit kannste erst mal bissel vorbeugen dann heißt es gucken das jede sitzung neu gestartet wird und auch beendet wird also auto log of so in der artZitat von Ische2K
schuld is vermutlich die session Id
Wichtig!!!
Sofort wenn Möglich betreiber anschreiben oder die Session Id selber auschalten ich glaub da muss ein update her ^^
Das Poroblem ist Definitiv die session id mit Worka getestet möglichst die session id ned anzeigen lassen das keiner auf die idee kommt unfug zu treiben.
die Session Id wird in den cookis gespeichrt also gucken das immer der logout benutzt wird oder ein zwangs logout geschieht ^^ siehe oben den code.
google sucht nicht mehr nach den session ids aber trozdem ältere seiten zb könnten noch drinstehen
Wir (Ische2K und ich) haben es grad mal nachgestellt und ich bin auch in Ische2Ks Account gekommen.
Kann man da nicht noch zusätzlich mit einem Cookie absichern?
Ich werde das nun so machen, das ich einen beliebigen Code in ein Feld in die Db speichere. Der wird dann in ein Cookie gespeichert. Paßt der Cookie nicht zum Code = autom. Logout
Denke das sollte helfen. Sollte man drüber nachdenken das man das, oder etwas Ähnliches ins Basisscript mit aufnimmt. Die Chance das es passiert ist ja ziemlich gering, aber wie man sieht kann es vorkommen.
Gruß
Marco
danke wäre toll wenn du dich da ran gibst das war auch so ne idee von mir oder nur auto logout würde jaacuch schon reichen hauptsache die sitzung wird immer beendet ^^
das problem liegt aber doch gar nicht am vms, oder täusche ich mich da??
schließlich entscheidet der server bzw. php, wie sessions behnadelt und verarbeitet werden und insbesondere, wie die session id, die php zum identifizieren des users braucht, übergeben wird.
dabei gibt es afaik 3 möglichkeiten,
1. per GET variable, wodurch es natürlich zu dem beschriebenen sicherheitsproblem kommen kann.
2. per POST varaibale, was auch nicht 100% ig sicher ist.
3. per cookie, was zwar auch nicht 100% sicher ist, aber total ausreichend und die sicherste möglichkeit.
also bei wem die session id noch per url übergeben wird, der sollte einfach schleunigst seinen server umkonfigurieren:
http://de.php.net/manual/de/session.configuration.php
also umstellen,d ass nur noch session ids per cookie übergeben werden, damit schließt man zwar die user aus, die keine cookies akzeptieren, aber da man in eigentlich jedem browser das für jede seite extra einstellen kann, sollte das kein problem sein, aber danach sollten sich solche sicherheitsprobleme erübrigt haben.
um sessions noch sicherer zu machen (wobei die methode mit den cookies schon ganz schön sicher ist), könnte man zu jeder session id noch die ip des users in der datnebank blegen, dann müsste man zusätzlich noch sich dieselbe ip holen, was auch nicht so leicht zu bewerkstelligen ist.
ganz sichere methoden speichern wikrlich alle infos über den suer ab, also auch die browserkennung etc., nur ist das ziemlcher overkill, gerade was datenbnk abfragen angeht.
Kill one man, and you are a murderer.
Kill millions of men, and you are a conqueror.
Kill them all, and you are a god. - Jean Rostand, Thoughts of a Biologist (1939)
denke da auch eher an einen fehler vom Server ich würde bei einem serverproblem
das in die htaccess einfügen :
php_value session.use_trans_sid 0
php_value session.use_only_cookies 1
so dürften session-ids nicht mehr an die url angehängt werden
und werden nur noch per cookie übermittelt
Berechtigungen
Zitieren