session: Sessions können doch immer von jedem "geklaut" werden

Hallo

Ich möchte ein Login Script mit Sessions erstellen.

Mein Gedanke ist gerade, wie ich es doch so einigermaßen sicher machen kann. Denn es ist doch möglich, dass sich jeder die Session merkt und eine eigene Session mit dem Wert erstellt und schon ist er drin oder?

Oder wie soll ich das verstehen?

Danke

  1. nein.
    die "sessions ID" ist einmalig , auch wenn der Password immer wiedr der selbe ist.
    oder irre ich mich?
    MFG
    bleicher

    --
    __________________________-
    Menschen an sich , sind nicht schlecht - es sind nur ihre Taten (c).
    1. wie überprüfe ich dann, ob es auch der richtige user ist?

      1. "session" bedeutet , daß der Server eine datei anlegt (für die dauer dr session) in der er die sessions ID speichert , diese wird bei jedem login neu codiert.Mehr zum thema sessionen hier http://tut.php-q.net/sessions.html , oder google oder ä.
        MFG
        bleicher

        --
        __________________________-
        Menschen an sich , sind nicht schlecht - es sind nur ihre Taten (c).
      2. Das überprüfst du nur einmal am anfang beim login. Wenn es das der richtige User ist, legst du eine entsprechende SessionID an. Danach kannst du das nicht mehr 100 prozentig verifizieren. Du kannst lediglich dinge prüfen, die den user-kreis einschränken,wie IP etc.

        Cookies tauscht man in der regel aber nicht untereinander.

  2. Hallo,

    Sessions sind ein serverseitiger Mechanismus. Soll heißen: Der Server kümmert sich darum die enthaltenen Daten zu sichern und beim nächsten Aufruf auch wieder bereitzustellen. Diese Daten werden _nicht_ an den Client übermittelt. Der Client bekommt nur die Session-ID mitgeteilt, entweder in Form eines Cookies, als Anhang an sämtliche URLs oder in Formularen. Überträgt der Client beim nächsten Aufruf also wieder die ID, kann der Server die passenden Daten wieder rauskramen und dem Skript bereitstellen.
    Der Client kann _nicht_ eine ganze Session an den Server schicken - wenn doch, dann ist das Skript auf dem Server sehr schlecht programmiert. Genaugenommen bekommt der Client selbst dann keinen Zugriff auf die Session, bei aktiviertem register_globals unter PHP könnte es für das Skript aber so aussehen als gäbe es da noch andere Daten.

    Es ist allerdings richtig, dass ein Benutzer die Session eines anderen kidnappen kann, wenn er dessen Session-ID kennt. Die ist nur pseudo-einmalig, d.h. eine mehr oder weniger lange, zufällige Zeichenfolge. Kommst du in deren Besitz (weil dir jemand eine URL per Mail schickt) und verwahrt der Server noch die zugehörige Session, dann könnte dieser andere Nutzer als Original auftreten und hätte Zugriff erlangt.

    MfG
    Rouven

    --
    -------------------
    Inter Arma Enim Silent Leges  --  Cicero
    1. echo $begrüßung;

      Es ist allerdings richtig, dass ein Benutzer die Session eines anderen kidnappen kann, wenn er dessen Session-ID kennt. Die ist nur pseudo-einmalig, d.h. eine mehr oder weniger lange, zufällige Zeichenfolge. Kommst du in deren Besitz (weil dir jemand eine URL per Mail schickt) und verwahrt der Server noch die zugehörige Session, dann könnte dieser andere Nutzer als Original auftreten und hätte Zugriff erlangt.

      Damit man dies gehörig erschwert, kann man bei jedem Scriptaufruf die Session-ID wechseln lassen. Dazu kann man sich der Funktion session_regenerate_id() bedienen. Allerdings ist sie erst ab PHP 5.1.0 mit dem dort vorhandenen Parameter delete_old_session für diesen Zweck brauchbar, da man ohne das Löschen der alten Session-Datei natürlich weiterhin mit der alten ID auf diese alten Daten zugreifen kann.

      Hat der Anwender nun einen Link mit einer Session-ID weitergegeben, darf er keine weiteren Scripte aufrufen, die session_regenerate_id() verwenden, damit ein Aufruf mit der weitergegebenen Session-ID funktioniert. Bei diesem Link muss es sich auch um einen solchen handeln, denn die URL-Zeile des Browsers enthält ja noch die alte Sessions-ID, mit der der Aufruf des aktuellen Scripts erfolgte, und deren Sessiondaten mittlerweile gelöscht sind.

      Weiterhin ist noch anzumerken, dass das Speichern der Session-ID in einem Cookie statt per Anhängen an Links und dergleichen, empfehlenswert ist, denn bei Cookies erfolgt im Normalfall keine ungewollte Weitergabe an Dritte.

      echo "$verabschiedung $name";

  3. Kein Text.

    1. Kein Text.

      Na ok dann jetzt doch, nachdem ich scheinbar schon Bettreif bin...

      Ich meinte natürlich "Cookies auch" und nicht Cookies aus ;)

  4. Hi!

    Es ist relativ einfach das Klauen einer Session zu erschweren. Du kannst beim Erstellen der Session die IP-Adresse des Benutzers berücksichtigen, der sich einloggt.
    Auf jeder Webseite, die nur über eine gültige Session sichtbar sein soll, vergleichst Du dann die IP-Adresse der Session mit der IP-Adresse des Benutzers. Stimmen diese nicht überein, zerstörst Du die Session und leitest den Benutzer beispielsweise auf eine Logi-Seite weiter.

    Ganz sicher ist dieser Mechanismus nicht. Denn wenn jemand einen Proxy-Server nutzt, kann der Schutz ins Leere laufen

    Aber vom Prinzip dürfte es klar sein. Auf dem Weg könnte man evtl. auch noch weitere Daten beim Generieren der SessionID auslesen und später im Vergleich einbeziehen...

    mfg
    Chris

    1. hi,

      Auf jeder Webseite, die nur über eine gültige Session sichtbar sein soll, vergleichst Du dann die IP-Adresse der Session mit der IP-Adresse des Benutzers. Stimmen diese nicht überein, zerstörst Du die Session und leitest den Benutzer beispielsweise auf eine Logi-Seite weiter.

      Ganz sicher ist dieser Mechanismus nicht. Denn wenn jemand einen Proxy-Server nutzt, kann der Schutz ins Leere laufen

      Und wenn die IP zwischen den Requests mehrfach wechselt, dann ist es nicht nur nicht ganz sicher, sondern ganz unbrauchbar.

      (Ja, dieser Fall ist als wahrscheinlich anzunehmen. AOL macht das teilweise so, da werden zahlreiche Proxies genutzt; und auch beim Einsatz über bestimmte Proxy-Netzwerke wie bspw. TOR kommt das vor.)

      gruß,
      wahsaga

      --
      /voodoo.css:
      #GeorgeWBush { position:absolute; bottom:-6ft; }
    2. Hi,

      vergleichst Du dann die IP-Adresse der Session mit der IP-Adresse des Benutzers. Stimmen diese nicht überein,

      bitte nicht IP, das läuft schief. Wenn, dann wär so was wie der User-Agent oder so ne Möglichkeit... Allerdings kann man den leichter fälschen als ne IP.

      Auf der sicheren Seite wärst du eigentlich nur mit SSL.

      e7

  5. Denn es ist doch möglich, dass sich jeder die Session merkt und eine eigene Session mit dem Wert erstellt und schon ist er drin oder?

    Vermutlich alles schon beantwortet, aber ich habe noch zwei Minuten Zeit. ;)

    Sessions werden serverseitig verwaltet sind also nur im Dialog mit dem Server manipulierbar. Die SessionID, auf die Du Dich wohl beziehst, kann in der Tat erraten werden, aber 1.) ist dieses nicht "ganz so" leicht (viel Glück!) und 2.) muss dieses im Rahmen einer "man in the middle"-Attacke sehr zeitnah zum letzten Zugriff auf die betreffenden Sitzungsparameter geschehen.

    Zusammengefasst: Ein Angriff auf eine bestehende Sitzung ist fast sicher erfolglos, sofern eine "anständige" Verschlüsselungsstärke gegeben ist (HTTPS, 128Bit reicht zumindest gegen einen Angriff der NSA nicht mehr, aber ansonsten ...).