Session Managment nicht übe URL bzw. Cookie?

[Ingo Bartel]

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

[Bio]

Sup!

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

Gruesse,

Bio

[Christian Kruse]

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

[Stefan Muenz]

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

[Christian Kruse]

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

[andreas]

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

[Ingo Bartel]

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

[andreas]

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

[Cheatah]

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

[Michael Schröpl]

Hi Cheatah,

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

5. Digest Authentication

Viele Grüße
      Michael

[Christian Kruse]

Hoi,

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

5. 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

[Michael Schröpl]

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

[Christian Kruse]

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

[Michael Schröpl]

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

[Christian Kruse]

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

[Michael Schröpl]

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 ;-)

[Erik]

Hallo erstmal,

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

5. 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

[Christian Kruse]

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

[Michael Schröpl]

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

[Michael Schröpl]

Hi Erik,

4.) Basic Authentication

5. 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

[Erik]

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

[Michael Schröpl]

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

[Michael Schröpl]

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