Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 11

Thema: Sicherheitsproblem der übelsten Art

  1. #1
    Erfahrener Benutzer
    Registriert seit
    11.01.2007
    Beiträge
    278

    Ausrufezeichen 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:

    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

  2. #2
    Erfahrener Benutzer
    Registriert seit
    11.01.2007
    Beiträge
    278
    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

  3. #3
    Erfahrener Benutzer
    Registriert seit
    14.08.2007
    Beiträge
    205
    schuld is vermutlich die session Id da die bei google mit erfast wurde konnte man rein das ist natürlich echt übel ^^

  4. #4
    Erfahrener Benutzer
    Registriert seit
    14.08.2007
    Beiträge
    205
    Zitat Zitat von Ische2K Beitrag anzeigen
    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

  5. #5
    Erfahrener Benutzer
    Registriert seit
    14.08.2007
    Beiträge
    205
    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

  6. #6
    Moderator Avatar von Worka
    Registriert seit
    20.05.2007
    Beiträge
    973
    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?

  7. #7
    Erfahrener Benutzer
    Registriert seit
    11.01.2007
    Beiträge
    278
    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

  8. #8
    Erfahrener Benutzer
    Registriert seit
    14.08.2007
    Beiträge
    205
    Zitat Zitat von VMS1 Beitrag anzeigen
    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 ^^

  9. #9
    Erfahrener Benutzer Avatar von jpwfour
    Registriert seit
    06.02.2008
    Beiträge
    3.717
    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)

  10. #10
    Erfahrener Benutzer Avatar von didith1207
    Registriert seit
    17.09.2006
    Beiträge
    1.580
    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

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •