nicht angemeldet
Session und Cookies
Hallo,
Ich wollte mal fragen ob man überhaupt noch die Session_id im Link übergeben muss, also um die Leute die keine Cookies erlauben nicht auszusperren? Gibts solche Leute heute eigenlich noch?
Und haben Cookies noch ein so großes Schadenspotential?
samy,
-
Hello,
Ich wollte mal fragen ob man überhaupt noch die Session_id im Link übergeben muss, also um die Leute die keine Cookies erlauben nicht auszusperren? Gibts solche Leute heute eigenlich noch?
Und haben Cookies noch ein so großes Schadenspotential?Aus dem Geschitspunkt der allgemeinen Sicherheit sollte man nicht mehr mit Session-IDs in der URL arbeiten. Cookies erzeugen bestimmt wesentlich weniger Sicherheitslücken, als die Übergabe in der URL.
Für Leute, die keine Cookies erlauben bleibt dann auch immer noch Basic Authentication. Da kann man sich ebn nur nicht wieder vernünftig abmelden, ohne alle Browserfenster zu schließen...
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
Hallo,
Du meinst also man sollte die URL gar nicht in der URL übergeben?
Und was ist 'Basic Authentication'???samy,
-
Hello,
Du meinst also man sollte die URL gar nicht in der URL übergeben?
Da ist jetzt was schiefgegangen... :-)
Und was ist 'Basic Authentication'???
Dazu könnte man diesen Begriff z.B. mal in die Suche vom Archiv eingeben:
http://suche.de.selfhtml.org/cgi-bin/such.pl?suchausdruck=Basic+Auth+Session&lang=on&feld=alle&index_1=on&index_2=on&index_3=on&index_4=on&index_5=on&index_6=on&index_7=on&hits=100Und Google hilft bestimmt auch weiter
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
OK danke! Ich meinte natürlich die Session_id in der URL!
-
-
-
Hallo Tom,
Aus dem Geschitspunkt der allgemeinen Sicherheit sollte man nicht mehr mit Session-IDs in der URL arbeiten. Cookies erzeugen bestimmt wesentlich weniger Sicherheitslücken, als die Übergabe in der URL.
Welche Sicherheitskritischen Aspekte sprechen denn gegen eine Übertragung der SessionID per URL im Gegensatz zu Cookies?
LG
Mark-
Hallo,
Weil wenn ein dummer Admin einen Link in einer email weiterleitet hat der andere zugriff aus seine Session!
samy,
-
Hello,
Aus dem Gesichtspunkt der allgemeinen Sicherheit sollte man nicht mehr mit Session-IDs in der URL arbeiten. Cookies erzeugen bestimmt wesentlich weniger Sicherheitslücken, als die Übergabe in der URL.
Welche Sicherheitskritischen Aspekte sprechen denn gegen eine Übertragung der SessionID per URL im Gegensatz zu Cookies?
Schau mal hier und such auch mal in Google
http://forum.de.selfhtml.org/archiv/2004/1/70719/#m406911
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
Schau mal hier und such auch mal in Google
Ich war jetzt eigentlich auch mehr an Deiner persönlichen Meinung interessiert, aber sie scheint sich wohl mit dem der anderen zu decken.
Trotzdem Danke
-
-
-
Hallo Tom,
Aus dem Geschitspunkt der allgemeinen Sicherheit sollte man nicht mehr mit Session-IDs in der URL arbeiten. Cookies erzeugen bestimmt wesentlich weniger Sicherheitslücken, als die Übergabe in der URL.
Ich sehe null Probleme mit Session-IDs in der URL sofern das richtig gemacht wurde.
Ich musste für ein Projekt in ASP (VBScript) eine eigene Session-Verwaltung schreiben.
Beim Erstaufruf wird jedem Link eine generierte SessionId angehängt, gleichzeitig wird die session von ASP mit dieser SessionId gefüllt. Auch ein Eintrag in eine Datenbank erfolgt mit SessionId, Timestamp, UserAgent, IP-Adresse und HTTP_ACCEPT-Werten?
Beim nächsten Aufruf einer Seite im Projekt (natürich muss einem Link gefolgt werden) wird zuerst überprüft ob die SessionId in der ASP-Session-Collection vorhanden ist. Dies würde bedeuten, dass Session-Cookies aktiviert sind und die Session-ID nicht mehr an die Links gebunden wird.
Bei jedem Page-Request wird die Session verlängert (Timestamp wird aktualisiert).Was sind jetzt die Kritierien für eine gültige Session:
- valider Timestamp (20 Minuten Session Timeout)
- valide IP-Adresse [1]
- valider UserAgent [2]
- valide HTTP-ACCEPT Werte [3]
In dem von dir verlinkten Archiv-Artikel (</archiv/2004/1/70719/#m406911>) hat Sven Vorbehalte gegen das Abgleichen der IP-Adresse [1]:
Aber die IP-Adresse ist absolut sinnlos. Weil sich die ändern kann, auch wenn absolut derselbe User zugreift, bzw. eben doch nicht garantiert für nur einen einzigen User steht!
Bedenke: User haben dynamische IP-Adressen, oder sitzen hinter richtigen NAT-Gateways (die ordnen den Benutzern des privaten Intranets mit vielen IP-Adressen die wenigen (oder die einzige) öffentliche IP des Gateways zu), oder benutzen zwangsweise Proxyfarmen mit Load-Balancing (siehe AOL, Freenet).
Wenn du zwingend erforderst, dass deine Benutzer in einer Session immer dieselbe IP haben, dann verhinderst du bei einem gewissen Prozentsatz eine ordentliche Nutzung.
Merke: Eine IP-Adresse ist kein Garant für den identischen User! Teilweise haben mehrere User die gleiche IP, teilweise wechselt die IP des Users unvorhersehbar.
Ich sehe das nicht wirklich so, vielleicht fehlt mir hier aber auch die Erfahrung. IP-Adressen von einem User sollten nicht ständig wechseln (innerhalb einer Session, typischerweise 5-10 Minuten). Eine IP-Adresse wird doch nur gewechselt, falls der User dies manuell tätigt oder zum Beispiel die Telekom einen Adressen-Wechsel erzwingt (IMHO alle 24h?). Wird sie einmal gewechselt, weil er z.B. um Mitternacht eine neue IP aufgezwungen bekommt: neu einloggen und für die nächsten 24h (?) sollte das Problem nicht mehr auftauchen.
Anders herum, dass mehrere User mit der gleichen IP-Adresse die Seite besuchen, spricht ja nicht gegen das Validieren mit der IP-Adresse sondern eher für das Validieren mit zusätzlichen Kriterien (User-Agent etc.)[2] Der User-Agent sollte ein recht zuverlässiges Kriterium sein, wenn gleich er nicht als einziges Kriterium validieren darf - es gibt tausende von "Opera/7.51 (Windows NT 5.1; U) [en]".
Wann ändert sich der User-Agent? Bei einem Browserwechsel (Cookies gehen dann auch baden) oder bei einem manuellen User-Agent-Wechsel - selbst schuld![3] Als zusätzliches Kriterien überprüfen wir die ACCEPT-Werte. Die sollten sich normalerweise während einer Session nicht verändern. Ok, wenn der User innerhalb der Session grad das Office installiert oder ähnliches, würde im die Session neu gesetzt - auch hier: tja pech gehabt, ist aber eher unwahrscheinlich.
Es gibt hier noch "viel" mehr Kriterien die einfügt werden könnten (ACCEPT Language, ACCEPT Charset... bitte um Hilfe bei dieser Liste *g*). Nichts spricht eigentlich gegen eine lange Liste, ausser dass der User die Session verliert, wenn er etwas an seinem Browser verändert. Dann wird er halt zu seinem Schutz ausgeloggt und muss sich wieder anmelden - so what?
Wo wird diese SessionId auftuchen? Erwähnt wurden Google (hab ich noch nicht bemerkt: diese Suche http://www.google.com/search?sourceid=mozclient&ie=utf-8&oe=utf-8&q=inurl%3APHPSESSID ergibt keine Resultat mit Session-IDs in den jeweiligen URLs), also bleiben noch Referrer in den Log-Files.
Erstens müssen die gezielt gesucht und benutzt werden, vom jeweiligen Siteadmin, dann muss er mit gleicher IP-Adresse [4] und allen oben erwähnten Kritieren vorbeischauen - eher unwahrscheinlich [4] bis sehr selten.[4] Ein bisschen anders sieht es in Intranets aus oder Seiten die auf dem Firmenwebserver. Dort können entweder die Referrer vom Admin (Intranet) ausgewertet werden oder es kommen alle Mitarbeiter mit der gleichen IP in die DMZ.
Hier wäre eine HTTP-Authentifizierung wahrscheinlich sinnvoller.Just my 16 cents zu dieser Thematik.
Grüsse
Siramon,
ja der Penner aus Nr. 14-
Hallo Siramon,
finde Deinen Beitrag sehr informativ.
Ein paar Sachen versteh ich nicht:Auch ein Eintrag in eine Datenbank erfolgt mit SessionId, Timestamp, UserAgent, IP-Adresse und HTTP_ACCEPT-Werten?
Was genau sind denn Accept Werte?
[3] Als zusätzliches Kriterien überprüfen wir die ACCEPT-Werte.
Da sind sie schon wieder.. ;-)
Plane für mein Vorhaben ebenfalls die Validierierung per Timespamp, User-Agent und Ip-Adresse - aber Accept ist mir noch neu.
Gruß
Mark-
Hab nun doch eine einigermaßen nützliche Erklärung dieser Accept-Werte gefunden. Nur der Vollständigkeit halber für andere interessierte:
-
-
Moin!
In dem von dir verlinkten Archiv-Artikel (</archiv/2004/1/70719/#m406911>) hat Sven Vorbehalte gegen das Abgleichen der IP-Adresse [1]:
Zitat: "Wenn du zwingend erforderst, dass deine Benutzer in einer Session immer dieselbe IP haben, dann verhinderst du bei einem gewissen Prozentsatz eine ordentliche Nutzung."
Ich sehe das nicht wirklich so, vielleicht fehlt mir hier aber auch die Erfahrung. IP-Adressen von einem User sollten nicht ständig wechseln (innerhalb einer Session, typischerweise 5-10 Minuten).
Du widersprichst meinem Einwand aber in keiner Weise. Natürlich ist das Leben angenehmer und eine Prüfung der IP sicherer, wenn man irgendwie garantieren kann, dass Benutzer immer einzeln eine feste IP nutzen.
Das ist dann aber ein ganz spezielles Szenario, und nach meinem Empfinden eher selten.
Eine IP-Adresse wird doch nur gewechselt, falls der User dies manuell tätigt oder zum Beispiel die Telekom einen Adressen-Wechsel erzwingt (IMHO alle 24h?). Wird sie einmal gewechselt, weil er z.B. um Mitternacht eine neue IP aufgezwungen bekommt: neu einloggen und für die nächsten 24h (?) sollte das Problem nicht mehr auftauchen.
Zwei Fragen stellen sich:
1. Welche zusätzliche Sicherheitsqualität wird gewonnen, wenn die IP geprüft wird?
2. Welcher ärgerliche Schaden kann entstehen, weil sich ein Nutzer einmalig unerwartet oder dauerhaft nervig neu einloggen muß?Zu Frage 1:
Eine zusätzliche Sicherheitsqualität wird IMO nicht gewonnen. Zur Erlangung des unerlaubten Zugangs sind lediglich mehr Parameter "richtig" zu raten und zu setzen, als bei einer simplen Session-ID. Gerade was die IP angeht, sind mögliche Szenarien durchaus denkbar. Wer in einer Firma mit NAT ins Internet geht, kann die Session eines Kollegen übernehmen - erst recht, wenn aufgrund der Standardinstallation des Browsers überall die gleiche Versionsnummer und Softwareausstattung vorhanden ist. Bei diesem Szenario braucht man wieder "nur" die richtige Session-ID.Zu Frage 2:
Es mag Szenarien geben, da ist der Verlust einer begonnenen Session nicht so schlimm. Aber eigentlich benutzt man Sessions doch gerade, um Informationen mitzuschleppen. Egal ob es sich dabei um einen Warenkorb, die Information "eingeloggt - ich bearbeite gerade Text" oder sonst etwas handelt - in allen Fällen würde wertvolle Arbeit des Nutzers zerstört, wenn dieser aufgrund seines nicht beeinflussbaren IP-Wechsels komplett an den Anfang zurückgesetzt wird.Dann wird er halt zu seinem Schutz ausgeloggt und muss sich wieder anmelden - so what?
Du vergisst, dass die Session ja begonnen wird, um irgendwas zu erreichen. Dieser Zweck wird durch Ausloggen nicht erreicht. Die Benutzer werden sich daher entweder gegen dein System sträuben und wegbleiben, oder wirkungsvolle Gegenmaßnahmen erfinden, welche deine Systemsicherheit dann wieder senken könnten.
Ich halte daher die IP für kein sinnvolles Kriterium, weil sie sich browserunabhängig verändern kann. Die vom Browser gesetzten HTTP-Header sind dagegen vielleicht akzeptabel, weil die sich tatsächlich nur beim Verändern des Browsers ändern - wenngleich auch hier Proxys eingreifen und unerwartete Veränderungen durchführen könnten, auf die der User keinen Einfluß hat.
Aber alles dies bringt keinen qualitativen Sicherheitsgewinn, sondern nur einen quantitativen: Man muß mehr in seinem angreifenden HTTP-Request richtig raten (oder herausgefunden haben). Wenn es tatsächlich um wichtige Dinge geht, ist Verschlüsselung die einzig gangbare Methode. Dann kann immerhin auf dem Übermittlungsweg nichts abgehört werden. DAS wäre eine qualitative Verbesserung der Sicherheit.
- Sven Rautenberg
-
Hello,
Eine IP-Adresse wird doch nur gewechselt, falls der User dies manuell tätigt oder zum Beispiel die Telekom einen Adressen-Wechsel erzwingt (IMHO alle 24h?). Wird sie einmal gewechselt, weil er z.B. um Mitternacht eine neue IP aufgezwungen bekommt: neu einloggen und für die nächsten 24h (?) sollte das Problem nicht mehr auftauchen.
Nein, AOL-User bekommen mit jedem Request eine neue IP-Adresse, zwar i.d.R. aus demselben Netz (anderes konnte ich bisher nicht feststellen) aber eben eine andere.
Mein Tiscali-Zugang trennt täglich mehrfach, wenn länger als 15min. (geschätzt) kein Traffic stattfindet, gibt mir aber sofort eine neue IP, wenn ich wieder einen Request auslöse (sofern sie nicht mal wieder eine Zahlung aus Anno Knölf vermissen *grummel*).Zu Frage 2:
Es mag Szenarien geben, da ist der Verlust einer begonnenen Session nicht so schlimm. Aber eigentlich benutzt man Sessions doch gerade, um Informationen mitzuschleppen. Egal ob es sich dabei um einen Warenkorb, die Information "eingeloggt - ich bearbeite gerade Text" oder sonst etwas handelt - in allen Fällen würde wertvolle Arbeit des Nutzers zerstört, wenn dieser aufgrund seines nicht beeinflussbaren IP-Wechsels komplett an den Anfang zurückgesetzt wird.Ein Benutzer in einem vernünftigen[tm] System sollte die Möglichkeit haben, auf dem "Lost-Connection-Point" wieder aufzusetzen und die Session fortzusetzen oder eben selber durch leichte verständliche Frage entscheiden zu können, dass die unterbrochene Session in den Trahcan kann.
Aber alles dies bringt keinen qualitativen Sicherheitsgewinn, sondern nur einen quantitativen: Man muß mehr in seinem angreifenden HTTP-Request richtig raten (oder herausgefunden haben). Wenn es tatsächlich um wichtige Dinge geht, ist Verschlüsselung die einzig gangbare Methode. Dann kann immerhin auf dem Übermittlungsweg nichts abgehört werden. DAS wäre eine qualitative Verbesserung der Sicherheit.
Die Schlüssel dürfen dann aber auch nicht über das Netz ausgetauscht werden, sondern ähnlich wie TANs auf einem separaten Weg ausgetauscht werden. Da wäre es nun hilfreich, wenn man in Browsern lokale Systemvariablen setzen könnte, die dann z.B. mittels JavaScript abgefragt werden können. Dazu wäre ein eigener input-Type im HTML ebenfalls sinnvoll, der niemals mit übertragen wird. Wir haben dann aber die Unbequemlichkeit, diesen Schlüsselwert bei jedem Login zusätzlich eingeben zu müssen, denn das Speichern von TANs auf dem System ist ja schon wieder eine Sicherheitslücke.
Ich denke, da die Browser vornehmlich von Firmen verteilt werden, die an echter Sicherheit nicht interessiert sind, wird das aber nicht machbar sein, es sei denn, dass hier einzelne Hersteller mal einen Deal mit der EU machen, die aber wohl (siehe Softwarepatente) auch schon von den Geheimdiesnten der Imperatoren unterwandert ist :-((
Wir haben hier allerobersten politischen Handlungsbedarf, wenn uns unserer Freiheit lieb ist.
Genauso wäre die Einführung eines erweiterten Mail-Protokols "VMTP" durch unsere Politik wünschenswert, denn hier geht es inzwischen darum, wesentliche Interessen unseres Europas und seiner Wirtschaft/seiner menschen zu schützen.Über derartig wichtige Dinge wird aber nicht debattiert, obwohl da eine gute gesetzliche Regelung jährlich Milliarden Schaden verhindern würde. Dann bräuchten wir nicht mehr über die paar Euro für Sozialhilfe diskutieren.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
-
Hallo Siramon,
[... Probleme mit der IP-Adresse als Identifikations-Mittel ...]
Ich sehe das nicht wirklich so, vielleicht fehlt mir hier aber
auch die Erfahrung. IP-Adressen von einem User sollten nicht
ständig wechseln (innerhalb einer Session, typischerweise 5-10
Minuten).Was du gern moechtest, danach richten sich nur wenige Leute. Die IP-Adresse kann sich problemlos aendern, auch heute gibt es noch
viele Provider, die transparente, wechselnde Proxies einsetzen. Hier
ist allen voran Freenet zu nennen. Bei fuenf Zugriffen kann der User
fuenf verschiedene IP-Adressen haben.[2] Der User-Agent sollte ein recht zuverlässiges Kriterium sein,
wenn gleich er nicht als einziges Kriterium validieren darf - es
gibt tausende von "Opera/7.51 (Windows NT 5.1; U) [en]".Wir betreiben bei uns in der WG ein maskierendes Netzwerk. Wir sind
vier Leute. Drei davon benutzen Mozilla unter Linux mit X.org-X11.
Das bedeutet, drei Leute haben schonmal dieselben Header mit
derselben IP.Grüße,
CK
-
-
hi,
Ich wollte mal fragen ob man überhaupt noch die Session_id im Link übergeben muss, also um die Leute die keine Cookies erlauben nicht auszusperren?
default bei PHP ist, doch, versuch's zuerst über cookie, und erst wennn das nicht klappt, nutze URL-übergabe.
(klar, beim ersten seitenaufruf muss sie dazu auch an den URL angehängt werden, aber wenn danach der cookie kommt, nicht mehr.)Und haben Cookies noch ein so großes Schadenspotential?
hatten sie je eins ...?
gruß,
wahsaga--
I'll try being nicer if you'll try being smarter.-
Hallo,
Ich dachte nur weil manche Leute sie ja deaktiviert haben!
samy,
-
hi,
Ich dachte nur weil manche Leute sie ja deaktiviert haben!
das "risiko" bei cookies besteht eigentlich nur darin, dass damit in gewissem umfang user tracking möglich ist.
google-stichwort "web bugs".das ist aber auch "schon" alles.
gruß,
wahsaga--
I'll try being nicer if you'll try being smarter.
-
-
-
Hallo Samuel,
Ich wollte mal fragen ob man überhaupt noch die Session_id im Link übergeben muss, also um die Leute die keine Cookies erlauben nicht auszusperren? Gibts solche Leute heute eigenlich noch?
Ich würde darauf wetten.
Und haben Cookies noch ein so großes Schadenspotential?
Cookies haben eigentlich gar kein Schadenspotential. (Außer in einem hypothetischen kaputten Browser). Das einzige was unerwünscht sein kann, ist das Tracking der User von großen Banneragenturen, die auf sehr vielen Webseiten Banner geschaltet haben.
Im Gegensatz zu einigen anderen sehe ich jedoch kein großes Problem bei der Weitervergabe der der Session-ID in der URL. Wenn Links auf externe Seiten über eine Wrapper-Seite geleitet werden, die die Session-ID aus dem Referer entfernt sind alle anderen Möglichkeiten, die Sessio-ID zu übertrage auf eigene Dummheit des Anwenders zurückzuführen. Und wer Cookies deaktiviert wird und muss dann auch mit diesem Risiko leben können.
Schöne Grüße,
Johannes
--
Der folgende Satz ist wahr.
Der vorhergehende Satz ist gelogen.
ss:| zu:} ls:[ fo:} de:] va:} ch:) sh:( n4:| rl:( br:< js:| ie:{ fl:( mo:}