Ingo Bartel: Session Managment nicht übe URL bzw. Cookie?

Hallo,

ich habe gesehen das in PHP die moeglichkeit besteht mit sessions zu arbeiten die nicht visuell fuer den benutzer ersichtlich sind (weder in der URL noch über Cookie).

Ich habe jetzt da nicht tief nachgeforscht - moeglicherweise gibt es die moeglichkeit die session über den header (nicht html) zu übertragen? (irgendwie muss der client ja die session wieder senden, also empfangen muss er sie ja dann schon)

Ich benutze Perl kein PHP - die folgefrage (wenn jemand eine antwort weiss) waere dann... Wie komm ich dann an die session ran wenn nicht ueber die pathinfo?

Dank im voraus,
Ingo

  1. Sup!

    Statt mit get kann man die Session-Daten auch mit post übertragen.

    Gruesse,

    Bio

    1. Hoi,

      Statt mit get kann man die Session-Daten auch mit post übertragen.

      Ich glaube nicht, dass das besonders praktikabel ist. Aber ansonsten
      hast du Recht: es gibt nur diese 3 Moeglichkeiten, GET, POST und
      Cookie. Und alle 3 sind fuer den User (Gott sei Dank) einsehbar.

      Gruesse,
       CK

      1. Hallo Christian

        Ich glaube nicht, dass das besonders praktikabel ist. Aber ansonsten
        hast du Recht: es gibt nur diese 3 Moeglichkeiten, GET, POST und
        Cookie. Und alle 3 sind fuer den User (Gott sei Dank) einsehbar.

        Es gibt ja noch ein paar andere "Methoden" der HTTP-Kommunikation. Verstaendlich erklaerte Uebersicht siehe z.B.:
        http://www.tecchannel.de/internet/208/4.html
        Kann es nicht auch sein, dass ueber eine dieser anderen Methoden so was wie erweitertes Session-Management moeglich ist?

        viele Gruesse
          Stefan Muenz

        1. Hoi,

          Es gibt ja noch ein paar andere "Methoden" der HTTP-Kommunikation.

          Jap. Aber die sind in den wenigsten Servern integriert, und einige
          davon sind eigentlich nur fuer Proxies gedacht.

          Kann es nicht auch sein, dass ueber eine dieser anderen Methoden so
          was wie erweitertes Session-Management moeglich ist?

          Nein, eigentlich nicht. Wie sollte das moeglich sein? Die in deinem
          Link vorgestellten zusaetzlichen Methoden eignen sich dazu nicht.

          Gruesse,
           CK

          1. Hi!
            ich würde die Seite in einen Frame packen, und dann kannst Du die SessionID wie Du willst über Get + Post(jeder Link, jedes Formular) übertragen, und der normalsterbliche User sieht nichts.
            Vor den Leuten hier im Forum kannst Du solche Sachen eh nicht verstecken ;-)

            Grüsse
              Andreas

            1. Hi!
              ich würde die Seite in einen Frame packen, und dann kannst Du die SessionID wie Du willst über Get + Post(jeder Link, jedes Formular) übertragen, und der normalsterbliche User sieht nichts.
              Vor den Leuten hier im Forum kannst Du solche Sachen eh nicht verstecken ;-)

              Grüsse
                Andreas

              Ersteinmal vielen dank fuer die antworten.
              Vorweg noch zum posting.. ziel war auch nicht die session nicht erreichbar zu machen für den user sondern rein vom aessueren halt..

              von daher wuerde sich die frame methode wirklich anbieten, obwohl das nur für den visuellen effekt vielleicht zu unprofessionell waere..

              Ich denke ich werd sie einfach weiter über get bzw pathinfo weiter verwenden.

              Gruss,
              Ingo

              1. Hi!
                Warum unprofessionel, machen viel größere Seiten so, immer wenn keine Frames verwendet werden und sich die Adressleiste nicht verändert, mir fällt zwar gerade kein Beispiel ein, ist aber so.
                Und das ist auch keine Arbeit, einfach das Frameset erstellen wo deine Seite 100% angezeigt wird, der Rest geht von alleine, die anderen Seiten öffnen sich automatisch immer in dem Frame.
                Oder Du mußt möglichst versuchen alles per Post zu übertragen, da sieht man dann auch nichts, nur sobald Du einen "normalen" Link hast geht das nicht mehr, und so viele Formulare, ich weiß nicht.
                Mußt Du wissen!

                Grüsse
                  Andreas

      2. Hi,

        es gibt nur diese 3 Moeglichkeiten, GET, POST und
        Cookie.

        4.) Basic Authentication

        Und alle 3 sind fuer den User (Gott sei Dank) einsehbar.

        Selbstverständlich. Der User hat ein Recht darauf zu erfahren, was für Daten er verschickt.

        Cheatah

        1. Hi Cheatah,

          es gibt nur diese 3 Moeglichkeiten, GET, POST und
          Cookie.
          4.) Basic Authentication

          5. Digest Authentication

          Viele Grüße
                Michael

          1. Hoi,

            es gibt nur diese 3 Moeglichkeiten, GET, POST und
            Cookie.
            4.) Basic Authentication

            1. Digest Authentication

            Noe. So ist kein Session-Management moeglich. Ich kann sagen, der und
            der User war es, aber nicht, obs auch derselbe PC war oder so.

            Wenn sich jemand hinsetzt und einloggt (== einen Zugriff macht) und
            sich dann an den anderen Rechner setzt und dort das Gleiche macht,
            denkt das Script uU im Normalfall, dass es sich um ein und denselben
            User handelt.

            Gruesse,
             CK

            1. Hi Christian,

              Noe. So ist kein Session-Management moeglich. Ich kann sagen, der und
              der User war es, aber nicht, obs auch derselbe PC war oder so.
              Wenn sich jemand hinsetzt und einloggt (== einen Zugriff macht) und
              sich dann an den anderen Rechner setzt und dort das Gleiche macht,
              denkt das Script uU im Normalfall, dass es sich um ein und denselben
              User handelt.

              Im Normalfall, ja. Die serverbasierte Anwendung müßte also zusätzlich
              Mehrfach-Login verhindern - dann reicht die Authentication-Information
              aus, um eine Session zu etablieren.

              Viele Grüße
                    Michael

              1. Hoi Michael,

                Im Normalfall, ja. Die serverbasierte Anwendung müßte also zusätzlich
                Mehrfach-Login verhindern - dann reicht die
                Authentication-Information aus, um eine Session zu etablieren.

                Richtig. Aber da ist IMHO das Zurueckgreifen auf vorhandene
                Session-Systeme sinnvoller.

                Gruesse,
                 CK

                1. Hi Christian,

                  Im Normalfall, ja. Die serverbasierte Anwendung müßte also zusätzlich
                  Mehrfach-Login verhindern - dann reicht die
                  Authentication-Information aus, um eine Session zu etablieren.
                  Richtig. Aber da ist IMHO das Zurueckgreifen auf vorhandene
                  Session-Systeme sinnvoller.

                  Je nach Randbedingungen.
                  Wenn Mehrfach-Login inhaltlich nicht gebraucht wird, aber Cookies als lästig
                  empfunden werden ...

                  Viele Grüße
                        Michael

                  1. Hoi,

                    Je nach Randbedingungen.
                    Wenn Mehrfach-Login inhaltlich nicht gebraucht wird, aber Cookies als lästig
                    empfunden werden ...

                    ... muss man immer noch einen betraechtlichen Programmier-Aufwand
                    betreiben, um den Mehrfachlogin zu verhindern.

                    Nene, diese Methode ist, wie gesagt, IMHO nicht besonders sinnvoll.
                    Besonders nicht unter dem Aspekt, dass User gerne vergessen, sich
                    auszuloggen und die Session dann in den Timeout laufen muss. Ist der
                    relativ kurz, ist alles ok. Aber ich glaube nicht, dass ein User
                    verstaendnis dafuer hat, wenn er eine halbe Stunde warten darf, dass er
                    sich neu einloggen kann. *Ich* haette es nicht.

                    Gruesse,
                     CK

                    1. Hi Christian,

                      Wenn Mehrfach-Login inhaltlich nicht gebraucht wird, aber Cookies als lästig
                      empfunden werden ...
                      ... muss man immer noch einen betraechtlichen Programmier-Aufwand
                      betreiben, um den Mehrfachlogin zu verhindern.

                      Wenn der Kunde es bezahlt, wieso nicht?
                      (Wenn Du wüßtest, was ich schon für Kundenwünsche realisieren durfte ...)

                      Die besage Kollisions-Kontrolle kostet beispielsweise fast nichts, wenn
                      die Authentifizierung ohnehin auf eine Datenbank zugreifen muß - mit einer
                      Transaktion kann ich problemlos auch die Session-ID in die Zeile der Be-
                      nutzerkennung reinschreiben bzw. aus ihr lesen.

                      Besonders nicht unter dem Aspekt, dass User gerne vergessen, sich
                      auszuloggen und die Session dann in den Timeout laufen muss. Ist der
                      relativ kurz, ist alles ok.

                      Das Problem hast Du aber _immer_ bei Sessions, weil HTTP eben ein
                      zustandsloses Protokoll ist. Die Benutzer loggen sich _nie_ aus.
                      Du brauchst _immer_ den cleanup-Job bzw. den Timeout. Und Du brauchst
                      eine Strategie, ob ein zweites login ein erstes überschreiben soll oder
                      nicht.

                      Aber ich glaube nicht, dass ein User verstaendnis dafuer hat, wenn er
                      eine halbe Stunde warten darf, dass er sich neu einloggen kann. *Ich*
                      haette es nicht.

                      Du scheinst kein Kunde einer online-Bank zu sein.
                      Genau dieses Blockieren ist (bzw. war?) dort schon aus Sicherheitsgründen
                      der Defaultfall, um Angriffe mit Passwort-Ausprobieren abzuwehren.

                      Manchmal geht Sicherheit vor Komfort - vor allem dann, wenn es um sehr
                      viel Geld geht. Eine Raumfähre ist auch nicht in erster Linie bequem. ;-)

                      Viele Grüße
                            Michael
                      (der ein Session-Management-System mit Cookies produktiv einsetzt, bei
                       dem die overruling-Strategie pro Benutzergruppe konfigurierbar ist ;-)

            2. Hallo erstmal,

              es gibt nur diese 3 Moeglichkeiten, GET, POST und
              Cookie.
              4.) Basic Authentication

              1. Digest Authentication

              Hab zwar keine Ahnung was das ist...

              Noe. So ist kein Session-Management moeglich. Ich kann sagen, der und
              der User war es, aber nicht, obs auch derselbe PC war oder so.

              ...aber das gilt doch für eine Session-ID auch. Ob ich nun http://bla.de/x.pl?session=abc von dem Rechner, mit dem ich mich eingeloggt habe, eingebe oder einem anderen spielt doch auch keien Rolle, oder sehe ich das falsch?

              Ciao,
              Erik

              1. Hoi,

                Noe. So ist kein Session-Management moeglich. Ich kann sagen,
                der und der User war es, aber nicht, obs auch derselbe PC war
                oder so.

                ...aber das gilt doch für eine Session-ID auch. Ob ich nun
                http://bla.de/x.pl?session=abc von dem Rechner, mit dem ich mich
                eingeloggt habe, eingebe oder einem anderen spielt doch auch keien
                Rolle, oder sehe ich das falsch?

                Ja, siehst du. Beim Session-Management geht es darum, den User
                *eindeutig* identifizieren zu koennen. Dafuer erstellt man beim Login
                eine (fast?) eindeutige ID und legt mit dieser ID als Schluessel
                Daten ab. Dabei ist es total egal, ob der User 3x oder 4x mit dem
                Namen 'ckruse' eingeloggt ist, oder ob er sich x mal unter einem
                anderen Login anmeldet. Bei Basic oder Digest Authentification wird
                die Erkennung des User *nur* anhand von Login und Passwort gemacht.
                Das bringt nichts: bei verschiedenen Hits koennen genau so gut 3
                User mit derselben Kennung auf die Ressource zugreifen. Das sollte
                bei der von mir beschriebenen Methode (fast) ausgeschlossen sein, da
                dort die Erkennung ganz anders funktioniert und fuer jede *Session*
                individuell ist, nicht nur fuer jeden User.

                Gruesse,
                 CK

                1. Hi Christian,

                  Ja, siehst du. Beim Session-Management geht es darum, den User
                  *eindeutig* identifizieren zu koennen. Dafuer erstellt man beim Login
                  eine (fast?) eindeutige ID

                  wenn die ID etwas enthält, was in dieser Form nur eindeutig sein kann
                  (sagen wir mal: eine Kombination aus UNIX-Prozess-ID und time stamp),
                  würde ich sie als zuverlässig eindeutig ansehen.

                  Viele Grüße
                        Michael

              2. Hi Erik,

                4.) Basic Authentication

                1. Digest Authentication
                  Hab zwar keine Ahnung was das ist...

                Beides sind Ausprägungen desjenigen Teils von HTTP, mit dem innerhalb der
                HTTP-Header Authentifizierungsinformationen zwischen Server und Client
                ausgetauscht werden.
                Wenn ein geschützter Bereich des Servers angesprochen wird, dann sendet
                der Server als Antwort einen HTTP-Status "Weise Dich aus nach dem Verfah-
                ren <name>" (wobei Basic und Digest die beiden möglichen Namen sind), und
                der Browser muß seine Anforderung erweitert um diese Informationen wieder-
                holen. Um sie einzuholen, führt er mit dem Benutzer einen Dialog (öffnet
                eine Box zur Eingabe von Benutzername und Kennwort) oder nimmt diese Werte
                aus einem vorherigen Dialog (weil er sie für eine Browser-Sitzung speichert,
                nicht aber über sie hinaus - das entspricht der Zielsetzung "Session-Proto-
                koll" eigentlich sehr gut).

                Der Webserver führt aber in der Tat kein Gedächtnis, ob ein Benutzer auf
                dem Server mehrfach eingelogt ist - das müßte die Server-Anwendung selbst
                tun (und dabei auch korrekte Logins ggf. ablehnen, wenn die Benutzerkennung
                bereits aktiv sein sollte).

                Noe. So ist kein Session-Management moeglich. Ich kann sagen, der und
                der User war es, aber nicht, obs auch derselbe PC war oder so.
                ...aber das gilt doch für eine Session-ID auch.
                Ob ich nun http://bla.de/x.pl?session=abc von dem Rechner, mit dem
                ich mich eingeloggt habe, eingebe oder einem anderen spielt doch auch
                keien Rolle, oder sehe ich das falsch?

                Wenn Du dieselbe Session-ID im Klartext als CGI-Parameter verwendest,
                dann hast Du durchaus recht. Du könntest diesen URL sogar bookmarken
                und damit wieder in eine Session "zurückspringen".

                Gerade deshalb macht man das aber nicht so, sondern:
                a) Man verwendet Cookies, weil man diese in den bisher üblichen Browsern
                   nicht mit vertretbarem Aufwand editieren kann (dieser Informationsstand
                   scheint gerade zu veralten). Dann würde ein URL alleine diesen Zugriff
                   nicht mehr korrekt reproduzieren, weil Informationen aus dem Cookie
                   fehlen.
                b) Man ergänzt die Session-ID in einer Weise, daß Du nicht einfach einen
                   beliebigen Wert verwenden kannst, weil Du dabei keine korrekte Session-
                   ID heraus bekommst.

                Stell Dir vor, Du hättest während einer Session eine konstante IP-Adresse.
                (Das ist überwiegend der Fall und liefert ein anschauliches Beispiel.)
                Würde ich Dir eine Session-ID liefern, dann würde ich beispielsweise die
                IP-Adresse, die Du mir übertragen hast, in diese Session-ID mit hinein
                codieren. Bei jeder weiteren Anfrage kann ich sie wieder extrahieren und
                damit feststellen, ob diese Anfrage tatsächlich von demjenigen Client kam,
                der sich die Session-ID ursprünglich geholt hat.
                Einen Zugriff mit demselben URL von einem anderen PC (mit einer anderen
                IP-Adresse) kann ich damit vom ursprünglichen PC unterscheiden; ein
                cut&paste in einen anderen Browser desselben PC beispielsweise nicht.

                Ich könnte natürlich noch mehr Informationen mit verschlüsseln, etwa den
                UserAgent ... oder auch den HTTP_REFERER, falls Dein Browser mir zuverläs-
                sig einen solchen sendet. Je mehr Informationen ich in der Session-Kennung
                speichere, desto genauer erkenne ich Dich wieder.

                Und natürlich muß ich diese Informationen so verschlüsseln, daß zwar ich
                selbst sie wieder zerlegen kann, Du aber möglichst keine Chance, die Ver-
                schlüsselung zu knacken und Dir selbst gültige Session-IDs anderer laufen-
                der Sessions zu berechnen. Die laufenden Sessions sind zudem auf dem Server
                gespeichert, und einfach nur eine legale Session-ID zu erzeugen, die nicht
                gespeichert ist, nützt gar nichts - es muß schon eine Session-ID sein, die
                gerade existiert.
                Selbst wenn Du also sämtliche Attribute eines Surfers am PC neben Dir
                kennst und dessen Session "übernehmen" willst, kann ich immer noch eine
                beliebig lange Zufallszahl in die Session-ID einbinden, die Du nicht in
                kurzer Zeit erraten kannst. Diese Zufallszahl ist ebenfalls auf dem Server
                gespeichert, so daß ich die Session-ID in minimaler Zeit wieder entschlüs-
                seln kann - Du hingegen müßtest alle Kombinationen durchprobieren.

                Und da ich darüber hinaus die Session selbst steuere (beispielsweise indem
                ich ständig neue Cookies an den Client sende, die selbst immer wieder für
                die Validierung des nächsten Zugriffs erforderlich sind - sie könnten bei-
                spielsweise die aktuelle Uhrzeit in verschlüsselter Form enthalten und da-
                mit innerhalb weniger Minuten "veralten"), müßtest Du die Verschlüsselung
                sehr schnell knacken, um "mitspielen" zu können.

                Letzten Endes ist "Session" ein heftig unterspezifizierter Begriff.
                Es kommt darauf an, was Du an Eigenschaften der Session haben willst,
                um ein Modell zu realisieren, welches diese Eigenschaften aufweist.

                Viele Grüße
                      Michael

                1. Hi Michael,

                  vielen Dank für deine ausführliche Antwort, auch wenn mir das meiste bezügl. Session-IDs schon klar war.

                  Stell Dir vor, Du hättest während einer Session eine konstante IP-Adresse.
                  (Das ist überwiegend der Fall und liefert ein anschauliches Beispiel.)
                  Würde ich Dir eine Session-ID liefern, dann würde ich beispielsweise die
                  IP-Adresse, die Du mir übertragen hast, in diese Session-ID mit hinein
                  codieren. Bei jeder weiteren Anfrage kann ich sie wieder extrahieren und
                  damit feststellen, ob diese Anfrage tatsächlich von demjenigen Client kam,
                  der sich die Session-ID ursprünglich geholt hat.
                  Einen Zugriff mit demselben URL von einem anderen PC (mit einer anderen
                  IP-Adresse) kann ich damit vom ursprünglichen PC unterscheiden; ein
                  cut&paste in einen anderen Browser desselben PC beispielsweise nicht.

                  Ich könnte natürlich noch mehr Informationen mit verschlüsseln, etwa den
                  UserAgent ... oder auch den HTTP_REFERER, falls Dein Browser mir zuverläs-
                  sig einen solchen sendet. Je mehr Informationen ich in der Session-Kennung
                  speichere, desto genauer erkenne ich Dich wieder.

                  Habe ich dich richtig verstanden, dass du Dinge wie IP-Adresse in den "Session-ID-String" (oder wie man das auch nennen will) einbauen willst?
                  Mir erschiene es sinnvoller diese Dinge nicht dort einzubauen sondern mit der Session-ID beim Login zu speichern und dann bei jedem Aufruf auf Übereinstimmmung zu überprüfen. So spart man sich (De)Kodierung und die Gefahr, dass in dieser Hinsicht etwas manipuliert werden könnte.

                  Viele Grüße,
                   Erik

                  1. Hi Erik,

                    Habe ich dich richtig verstanden, dass du Dinge wie IP-Adresse
                    in den "Session-ID-String" (oder wie man das auch nennen will)
                    einbauen willst?

                    Wenn ich etwas davon habe, sie wiederzuerkennen, dann ja.
                    Wenn sie sich beim Client ständig ändern kann, dann nein.
                    (So gesehen ist die IP-Adresse zwar ein anschauliches und im Intranet
                    ggf. praktikables, im Internet aber weniger taugliches Beispiel.)

                    Mir erschiene es sinnvoller diese Dinge nicht dort einzubauen
                    sondern mit der Session-ID beim Login zu speichern und dann bei
                    jedem Aufruf auf Übereinstimmmung zu überprüfen.
                    So spart man sich (De)Kodierung und die Gefahr, dass in dieser
                    Hinsicht etwas manipuliert werden könnte.

                    Wenn der Client mit einer unveränderlichen IP-Adresse diese automatisch
                    immer mit sendet, und ich codiere sie in die Session-ID mit hinein, dann
                    kann ich auf dem Server erkennen, daß ein anderer Client mit Deiner (!)
                    Session-ID (die er ggf. im Netz erlauscht hat) einen Zugriff versucht,
                    der ihm wegen seiner IP-Adresse nicht zusteht!
                    Ich erkenne also, daß jemand Dich zu fälschen versucht. Je mehr ich
                    durch eine komplexe Session-Kennung über Dich weiß, desto besser sind
                    meine Chancen, Angriffe auf Deine Session als solche zu identifizieren.
                    Die Gefahr der Manipulation wird doch eher kleiner, wenn ich dem Angrei-
                    fer _zusätzliche_ Hürden in den Weg stelle.

                    Es geht nicht _nur_ darum, daß ich Deine Zugriffe als zusammengehörig
                    erkennen kann. Ich will sie _auch_ zuverlässig von anderen Zugriffen
                    unterscheiden können. Sonst legt Dir der unfreundliche Hacker von neben-
                    an nämlich Dinge in Deinen Warenkorb, die Du gar nicht kaufen wolltest ...
                    das schädigt Dich als Kunden ebenso wie den Verkäufer, auch wenn es dem
                    Angreifer selbst keinen direkten wirtschaftlichen Nutzen verschafft.
                    (Außer er arbeitet im Auftrag der Konkurrenz ...)

                    Viele Grüße
                          Michael

      3. Hi Christian,

        Statt mit get kann man die Session-Daten auch mit post übertragen.
        Ich glaube nicht, dass das besonders praktikabel ist.

        Nur als Fußnote, wieso nicht (für's Archiv):

        POST läßt sich von HTML-Seiten aus nur über Formulare aktivieren,
        GET auch von normalen Links.
        Ein Session-Protokoll über POST wäre also auf die ausschließliche Verwen-
        dung von Formularen beschränkt - die Seiten könnten keine normalen Links
        nutzen.
        Dasselbe würde auch für andere HTTP-Methoden gelten.

        Solange der Browser für Hyperlinks GET-Requests sendet, muß das Verfahren
        zur Realisierung des Session-Protokolls das verwenden, was GET kann - und
        das sind HTTP-Header (inklusive Cookies. Authentications und URLs mit
        Query-Strings).

        Alles, was darüber hinaus geht, würde den Einsatz eines eigenen Browsers
        erfordern.

        Viele Grüße
              Michael