Für eine CGI-Applikation möchte ich ein sicheres Session-Management *selbst* programmieren. Der Benutzer loggt sich ein und soll dann immer identifiziert werden können, dabei ist mir die Sicherheit sehr wichtig.
Welche Session-Techniken kennt ihr?
Neben einer Cookie-Lösung denke ich auch an Query-Strings. Allerdings sind diese ja öffentlich sichtbar.
Kann ich in diesen Zusammenhang die IP-Adresse kontrollieren, oder gibt es da Probleme mit Proxies/Firewalls?
Viele grüße,
Udo
Neben einer Cookie-Lösung denke ich auch an Query-Strings.
Diese beiden lösungen sind auch üblich. Soweit es geht Cookies, User die keine Cookies akzeptieren über URL-Parameter.
Die IP-Lösung halte ich für weniger geeignet (es könnten mehrere Sessions vermischt werden).
ich denke mal die Cookie / URL Lösung solltest du machen, das wird eigentlich überall so gemacht.
Gruß
Bruno
in anbetracht dessen, dass nicht alle user cookies akzeptieren würde ich persönlich das lassen.
machs doch so: wenn sich der user einlogt bekommt er ne sessionID zugewiesen (ne zufallszahl, möglichst lang, so dass sie nicht erraten werden kann, 15 bziffern oder so?) und außerdem wird noch eine zeitangabe zugewiesen (über time z.B.) das ganze schreibst du in ne datei und jedes aml wenn ne seite vom user aufgerufen wird wird die login zeit und die sessionID überprüft. wenn du jetzt noch festlegst, dass der user maximal 30m minuten am stück mit der selben sessionID eingelogt sein darf, dann dürfte das ziemlich sicher sein.
Die IP-Lösung halte ich für weniger geeignet (es könnten
mehrere Sessions vermischt werden).
Erstmal danke für deine Antwort.
Das mit der IP Adresse meinte ich so, dass zu der Session-ID intern noch die IP-Adresse gespeichert wird und bei weiteren Aufrufen verglichen wird (sie muss also immer gleich bleiben).
Damit könnte man sicherstellen, dass es sich auch wirklich um den richtigen User handelt und nicht die Session-ID wegen der URL von einer anderen herausgefunden werden kann (z.B. JavaScript oder bereits der Referer-String bei Grafiken).
Allerdings bin ich mir nicht sicher, ob die IP Adresse beim Benutzer auch tatsächlich während der Session gleich bleibt oder sich durch Proxies oder ähnliches verändert (Proxies verdecken ja die echte IP Adresse).
Ideen?
Udo
in anbetracht dessen, dass nicht alle user cookies akzeptieren
würde ich persönlich das lassen.
Ich denke inzwischen an eine kombinierte Lösung. Zuerst wird ein Cookie gesetzt, kommt das nicht sofort zurück wird per URL weitergearbeitet. Das alles ohne dass es der Besucher merkt. Es ist kein Problem das in meinem System zu implementieren da jede Seite dynamisch (also per Skript) erzeugt wird.
machs doch so: wenn sich der user einlogt bekommt er ne
sessionID zugewiesen (ne zufallszahl, möglichst lang, so dass
sie nicht erraten werden kann, 15 bziffern oder so?) und
außerdem wird noch eine zeitangabe zugewiesen (über time z.B.)
das ganze schreibst du in ne datei und jedes aml wenn ne seite
vom user aufgerufen wird wird die login zeit und die sessionID
überprüft. wenn du jetzt noch festlegst, dass der user maximal
30m minuten am stück mit der selben sessionID eingelogt sein
darf, dann dürfte das ziemlich sicher sein.
Mir steht auch eine Datenbank zur Verfügung. Das mit den Session-IDs und der Timeout-zeit ist mir schon klar. Vielleicht habe ich mich auch etwas schlecht ausgedrückt. Ich möchte eher eine möglichst sichere und verlässliche Lösung finden. Wenn die Session-ID über die URL weitergegeben wird, kann sie leicht herausgefunden werden (beim Laden von anderen Seiten wird beispielsweise die Referer-Adresse und somit die Session-ID mitgeschickt. Es gibt noch andere Möglichkeiten.
Ich habe deshalb an die Speicherung und Überprüfung der IP-Adresse gedacht. Die Frage ist nur: Kann ich mich darauf verlassen, dass sich die IP Adresse des Besuchers nicht während seines Aufenthalts ändert? Weiss ja nicht ob Proxies z.B. da Probleme machen da ich die echte IP-Adresse des Besuchers ja nich herausfinden kann.
Gibt es da spezielle Methoden?
Udo
meines wissens nach behält auch ei user der nen proxie benutzt die ganze online session über hinweg die gleiche IP.wenn du die abspeicherst, dann dürfte das wohl schonfunktionieren, es sei den der proxie vergibt bei jedem neuen seitenaufruf dem user ne neue IP aus seinem pool (exotisch, hab aber schon gehört das solls geben…) die IP bekommst du über $ENV{‚REMOTE_ADDR‘}, weißt du ja sicher, oder? 
zur not musst du halt an deine user appellieren, sich bevor sie ne andere seite besuchen, aus zu logen… (was in der praxis warscheinlich nicht wirklich funktioniert…)
Das mit der IP Adresse meinte ich so, dass zu der Session-ID
intern noch die IP-Adresse gespeichert wird und bei weiteren
Aufrufen verglichen wird (sie muss also immer gleich bleiben).
Damit könnte man sicherstellen, dass es sich auch wirklich um
den richtigen User handelt und nicht die Session-ID wegen der
URL von einer anderen herausgefunden werden kann (z.B.
JavaScript oder bereits der Referer-String bei Grafiken).
Sorge für einen Session-Timeout, dann müsste das ausspähen der Daten schon sehr zeitnah erfolgen, damit man die Session „übernehmen“ kann.
Allerdings bin ich mir nicht sicher, ob die IP Adresse beim
Benutzer auch tatsächlich während der Session gleich bleibt
oder sich durch Proxies oder ähnliches verändert (Proxies
verdecken ja die echte IP Adresse).
Ich wrüde nicht davon ausgehen dass die IP gleichbleibt. Ein (sicher seltenes) Szenario wäre z.b. auch ein User hat deine Seite offen, seine verbindung wird irgendwie absichtlich oder unabsichtlich getrennt, er muss sich neu einwählen und will weitersurfen, schwupp sind seine Session-Daten weg.
Also ich finde es ja gut, dass du die Sorgen um die Sicherheit machst, aber ich würde sagen die Session-ID per Cookie (falls nicht möglich per URL) mit einem nicht zu gross dimensionierten Timeout sollte reichen und wird soviel ich weiss auch standardmässig so verwendet.
Also ich finde es ja gut, dass du die Sorgen um die Sicherheit
machst, aber ich würde sagen die Session-ID per Cookie (falls
nicht möglich per URL) mit einem nicht zu gross
dimensionierten Timeout sollte reichen und wird soviel ich
weiss auch standardmässig so verwendet.
Ok, wenn ich bedenke, dass schätzungsweise 90% der Besucher Cookies aktiviert haben, wird die Übergabe der Session-ID per URL bei den restlichen 10% auch kein grosses Sicherheitsrisiko bedeuten… 
Andrerseits will ich das System einerseits für eine Administration und andrerseits für ein Besuchertracking ohne Log-In verwenden. Der 2. Fall verlangt zwar keine große Sicherheit, schickt dem User aber beim ersten Betreten ein Cookie.
Es wäre nun die Diskussion interessant, wie sehr Cookies heute akzeptiert werden. Ich glaube, wo doch heute viele Werbebanner (Doubleclick z.B.) bereits Cookies setzen, dürfte das kaum auffallen, oder was meint ihr?
Udo
es sei den der proxie vergibt bei jedem neuen seitenaufruf dem
user ne neue IP aus seinem pool (exotisch, hab aber schon
gehört das solls geben…)
Genau das befürchte ich. Ich hatte bereits früher mal etwas ähnliches probiert. Nach dem Einloggen wurde dabei dem User über hidden-Fields in Formularen (die gesamte Administration beruhte auf POST-Formulare) immer eine Art Session-ID mitgegeben, welche auch die IP speicherte. Im Allgemeinen ging das gut, aber ich bekam einige E-Mails von verärgerten Usern, dass das System den Zugriff aufgrund eines IP-Wechsels verweigerte. Dabei sei der User auch nicht aus dem Internet ausgestiegen.
Ich habe darauf hin die IP-Kontrolle ausgeschaltet.
Kann aber auch gut sein, dass die betroffenden User irgend einen Blödsinn gemacht haben oder unwissentlich sich neu ins Internet eingeloggt haben oder sonstwas (mal von Programmierfehlern abgesehen *g*).
die IP bekommst du über
$ENV{‚REMOTE_ADDR‘}, weißt du ja sicher, oder?
Klar
zur not musst du halt an deine user appellieren, sich bevor
sie ne andere seite besuchen, aus zu logen… (was in der
praxis warscheinlich nicht wirklich funktioniert…)
Ich habe da mehr an ein Timeout gedacht, das die Session automatisch löscht…
Mit Cookies brauche ich eigentlich auch keine IP-Adresse, für mich reichen sie völlig aus um den Benutzer zu identifizieren. URLs sind aber gewissermaßen öffentlich…
Vielleicht mach ich mir auch einfach zu viele Sorgen Das Session-System wird aber recht oft in verschiedenen Projekten zum Einsatz kommen und deshalb möchte ich auf Nummer sicher gehen.
Viele Grüße,
Udo
Mit Cookies brauche ich eigentlich auch keine IP-Adresse, für
mich reichen sie völlig aus um den Benutzer zu identifizieren.
URLs sind aber gewissermaßen öffentlich…
Hm Cookies sind auch öffentlich so gesehen oder FORM-Hidden Felder, wird ja alles letztlich im Klartext gesendet.
Das schon. Die Session-ID ist ja auch nichts geheimes - für den Benutzer dem die Session wirklich gehört. Einmal eingeloggt kann er ruhig seine eigene Session-ID herausfinden.
Allerdings wäre es nicht gut wenn andere Personen die Session-ID herausfinden (so lange der Benutzer eingeloggt ist). Die fremde Person hat damit nämlich vollen Zugriff auf den geschützten Bereich.
Nehmen wir mal an, ein eingeloggter Benutzer klickt auf der geschützten Website auf einen externen Link und gelangt so auf eine fremde Website. Dieser Website wird die Ursprungs-URL (Referer) übertragen. Wenn die Session-ID in der URL gespeichert ist, dann ist sie somit verraten. Cookies oder hidden Fields von POST-Formularen werden hingegen nicht weitergegeben.
Ist zwar unwahrscheinlich dass der Webmaster der jeweiligen Seite schnell genug die geschützte Seite aufrufen kann, bevor die Session verfällt, aber immerhin.
Aber, wie gesagt, bei einer automatsichen Cookie/URL-Kombination (URL wird nur verwendet wenn das Cookie nicht angenommen wurde) fällt die Wahrscheinlichkeit verschwindend klein aus, dass ein unbefugter Zugang möglich ist.
Udo
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Nehmen wir mal an, ein eingeloggter Benutzer klickt auf der
geschützten Website auf einen externen Link und gelangt so auf
eine fremde Website. Dieser Website wird die Ursprungs-URL
(Referer) übertragen.
Ach jetzt verstehe ich wie du das meinst… naja ok, ich denke mal mit diesem Szenario kann man leben.
Cookies oder
hidden Fields von POST-Formularen werden hingegen nicht
weitergegeben.
wenn du nur mit post statt mit get arbeitest, dann kannst du das mit der IP weglassen, ansonsten würd ich wie bereits gesagt mit nem timeout nach 20 oder 30 min (je nach bedarf) arbeiten.
Bei meiner aktuellen Anwendung gibt es keine Formulare mehr.
Ich werde es einfach mit dem Timeout machen.
Wenn Cookies erlaubt sind, dann wird ein Cookie gesetzt, ansonsten über die URL.
Nochmal danke an alle!
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Und wenn Du nicht damit leben willst, kannst Du auch noch mit einem „Defer“-Script arbeiten, wie GMX es macht: Externe Links werden dort grundsätzlich nicht direkt angeboten, sondern immer nur auf folgendem Weg:
Es wird ein neues Fenster geöffnet (um den Zugriff auf die History zu verhindern), in dem ein Skript ausgeführt wird, welches als einzigen Parameter die URL der neuen Seite erhält. Dieses Script leitet dann nur noch weiter an die neue Seite. Und was die dann sieht, ist a) per JavaScript eine History mit einem Eintrag (nämlich das Defer-Skript), und b) per ServerVariable die aufrufende Seite (wieder das Defer-Skript).
Ciao, Thomas
Meine Überlegungen - Lösungsansatz?!
Also ich habe z.Z. auch so ein - nennen wir es mal statistische Erfassung - Script in Planung. Ich habe mir die Sachen schon ganz gut durchdacht und bin zu folgenden Optimum (aus meiner Sicht) gekommen.
Beim Betreten der Seite erhält der User ein Cookie (mit Haltbarkeit von paar Tagen) und eine Session-ID. Nun logge ich auf jeder Seite die UserID aus dem Cookie, die SessionID und die Seite. (evt. auch mehr ) Nun kann ich:
an der Cookie-ID feststellen wer es war (falls er sich mal im Gästebuch verewigt und so der Cookie-ID einen Namen zuordnet), wie oft er da war und in Kombination mit der Session-ID und welche Wege er je Session genommen hat
Wenn er keine Cookie akzeptiert wenigstens seine Weg durch die Seiten anhand der Session-ID verfolgen und habe ebenfalls den Name dazu falls er sich im Gästebuch verewigt verewigt und so der Session-ID einen Namen zuordnet
Was haltet Ihr von diesen Überlegungen? Abgesehen von der Thematik ‚gläserner User‘, weil ausspionieren will ich niemand auf meiner kleinen Homepage.
mfg Slick
Also ich habe z.Z. auch so ein - nennen wir es mal
statistische Erfassung - Script in Planung. Ich habe mir die
Sachen schon ganz gut durchdacht und bin zu folgenden Optimum
(aus meiner Sicht) gekommen.
Habe auch vor so etwas ähnliches in mein System einzubauen. Allerdings weniger um die Navigation der Besucher zu loggen sondern mehr um bessere Website-Statistiken zu erstellen.
Es gibt da überigens eine Web/Programm-Kombination mit der du auch das Verhalten der Besucher beobachten kannst - in Echtzeit. Das ganze läuft über ein JavaScript und einem unsichtbaren Bild (und es kann noch einige andere Sachen). Kostenlos zu haben unter http://www.humanclick.com/
Grüsse,
Udo
Wie ich es handhabe…
Hallo,
ich hab mich mit diesem Problem auch schon länger beschäftigt…
Ich mach das so:
Andere Websites: URLs ausserhalb der eigenen Domain werden über relocation-Script umgeleitet (damit haben die anderen Websites nur sowas wie http://…/relocate?http://www.xy.de im Log, ohne SessionID)
bei mir funkt das schon seit 2 jahren ganz gut,
lg,
gerhard
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Ich mach das so:
- Es werden nur SessionIDs in der URL verwendet
- In einer DB werden zu den Usern SessionIDs mit
Ausgabezeitpunkt festgehalten
hatte ich auch vor
- Beim Einloggen wird die Remote-IP, der UserAgent-String und
die Uhrzeit festgehalten- Bei jedem Zugriff wird die Referer- und die aktuelle Adresse
mitgeloggt
Das kann ich leider nicht machen, da das System auch mit bis zu 1 Mio. PageViews pro Tag zurechtkommen muss, da würde die Datenbank ganz schön ins Schwitzen kommen.
- Beim validieren der SessionID wird folgendermaßen
vorgegangen:
a) SessionID vorhanden? Nein -> ungültig
b) SessionID passt, aber UserAgent stimmt nicht überein ->
ungültig
Das ist eine interessante Idee. Allerdings hab ich auch schon gehört (stand irgendwo auf GRC.COM) dass bestimmte Browservarianten den UserAgent dazu missbrauchen, einige Informationen über das Client-System (Bilschirmauflösung, usw.) zu übermitteln. Weiss jetzt aber nicht, ob sich da der UserAgent während einer Sitzung ändert.
Gab es da nie Probleme?
c) Remote-IP stimmt nicht: Wenn nie ein Referer-String
gesendet wurde (z.B. Opera lässt das ausschalten, und auch der
neue IE6 bietet sowas) -> ungültig
Wenn Referers geschickt worden sind, wird überprüft, ob der
aktuelle Referer innerhalb des Logs im Zeitraum vom Einloggen
bis jetzt vorkommt
Kann ich leider nicht anwenden (s.o.).
Andere Websites: URLs ausserhalb der eigenen Domain werden
über relocation-Script umgeleitet (damit haben die anderen
Websites nur sowas wie http://…/relocate?http://www.xy.de
im Log, ohne SessionID)
Das ist eine gute Idee! Da fast alle Links auf der Website vom System selbst verwaltet werden dürfte leicht zu implementieren sein. Thanks
Udo