Sicherheitsproblem der übelsten Art

Druckbare Version

13.04.2008, 22:24
VMS1

Sicherheitsproblem der übelsten Art

Hallo,

mir ist gerade was passiert, was ich bis jetzt überhaupt noch nicht erlebt habe und was ich auch echt nicht einzuordnen weiß. Bin mit meinem Latein am Ende.

Vor ca. 15min erreichen mich auf meiner Seite mehrere PNs:

Zitat:

Hi ,
bin durch zufall ins userkonto von XXX gerutscht als ich auf den link von quick lose bei google geklickt hab ,

Nickname: XXX
Kontonummer XXX
Konto eröffnet am 07.04.2008 - 16:42
Aktueller Kontostand 1,49 Anteilspunkte
Dein Werber (Refback %) XXX (100 %)
Aktueller Verdienst 31,50 Anteilspunkte
Gesamt für den Werber XXX Anteilspunkte

könnt ihr euch mal drum kümmern , muß ja nicht jeder sehen was andere user auf dem konto haben oder wie ihre Rl Namen sind , von XXX is er XXXX.................

Alle so in etwa in dieser Art. Erst konnt ich das nicht glauben, aber dann kamen mehrere PNs dieser Art.
Dann ein Hinweis von einem User :

http://www.google.de/search?q=PHPSES...ient=firefox-a

Jetzt geht es nicht mehr, weil ich den User sicherheitshalber gesperrt habe. Aber ich habe es selbst ausprobiert. Ich habe mich selbst ausgeloggt, meine Cookies gelöscht und dann den Link geklickt. Und bumms war ich in nem fremden Userkonto eingeloggt.

Wie geht denn sowas? Und vor Allem wie kann ich das verhindern? Sind jetzt alle Accounts gefährdet?

Ich bitte um Hilfe und bezahle diese auch. Hauptsache es geht so schnell wie möglich. Auch für eine Erklärung wär ich dankbar. z.B. ob die Gültigkeit des Links begrenzt ist usw.

Gruß
Marco
13.04.2008, 22:42
VMS1

Nachdem ich den User gesperrt hatte und erneut wieder freigeschaltet habe ist der Link nun scheinbar ungültig. Trotzdem würde mich interessieren, wie so etwas vorkommen kann und wie hoch das Risiko ist, das so etwas wieder vorkommt.

Ich habe mir fogendermassen geholfen, bin mir aber nicht sicher ob es hilft:

In die index.php hab ich ganz oben dies eingesetzt :

Code:

if (strlen($_GET['PHPSESSID']) > 1) { unset($_GET['PHPSESSID']); setCookie('uid','',time()-86400*30); setCookie('passwort','',time()-86400*30); setCookie('autologin','',time()-86400*30); $_SESSION['uid'] = ""; $_SESSION['passwort'] = ""; $_SESSION['login'] = ""; }

Zusätzlich diese Zeile mit in die htaccess geschrieben :

Code:

php_value session.use_trans_sid 0

Jetzt würde mich halt interessieren, ob das der richtige Weg ist, oder wie man sich bzw. die Userkonten am Besten schützen kann. Denn sowas ist ja hammerkrass. Hab ich auch solange wie ich im Netz unterwegs noch nie erlebt. Scheine wohl ein ausgesprochenes Glückskind zu sein^^

Gruß
Marco
14.04.2008, 00:00
Ische2K

schuld is vermutlich die session Id ;) da die bei google mit erfast wurde konnte man rein das ist natürlich echt übel ^^
14.04.2008, 00:16
Ische2K

Zitat:

Zitat von Ische2K

schuld is vermutlich die session Id ;) da die bei google mit erfast wurde konnte man rein das ist natürlich echt übel ^^

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 art
14.04.2008, 00:39
Ische2K

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
14.04.2008, 00:43
Worka

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?
14.04.2008, 14:49
VMS1

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
14.04.2008, 15:48
Ische2K

Zitat:

Zitat von VMS1

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 ^^
14.04.2008, 16:06
jpwfour

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.
14.04.2008, 16:30
didith1207

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
14.04.2008, 16:52
Ische2K

Zitat:

Zitat von didith1207

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

es ist richtig das das vom server kommt aber trozdem ist es schlecht da die session id durchweg weiter gegeben wird aber selbst nach tagen kannste dich einfach so eingelogt wieder vergnügen da müsste en auto log out rein dann wäre die session id immer nach beenden zb 15 min ohne connect wieder auf 0 also ausgeloggt dann kann sowas ned passieren ;)