nicht angemeldet
Cookies oder Sessions?
suitHi,
kann mir jemand sagen was besser für ein Mitlgieder Authentifizierungsscript ist: Cookies oder Sessions?
MfG
Simon
-
Hi,
kann mir jemand sagen was besser für ein Mitlgieder Authentifizierungsscript ist: Cookies oder Sessions?
Definiere: "besser"
Kommt drauf an, was du erreichen willst, und wie.
Auf jeden Fall wirst du den ueber das zustandslose Protokoll HTTP zugreifenden Client identifizieren, "wiedererkennen", wollen.
Dazu sendet er dir idR. einen eindeutigen Wert bei jedem Request mit.
Auch bei Sessions geschieht dies ueber Cookies, ausser wenn der Client diese nicht akzeptiert, dann wird die Session-ID ueber GET/POST uebergeben.
Sessions bieten dir natuerlich die Moeglichkeit, noch mehr bereits ausgelesene oder anderweitig ermittelte Daten vorzuhalten, und das "im Geheimen", auf der Serverseite - ohne dass sie dem Client bekannt gemacht werden muessten.MfG ChrisB
--
„This is the author's opinion, not necessarily that of Starbucks.“-
Definiere: "besser"
Ja da ich erst Einsteiger im PHP Gebiet bin weiß ich eben nicht was für meinen Fall besser ist: User kann sich anmelden, und wird auf der Ganzen Seite als angemeldet erkannt solange er sich nicht ausloggt. Nur was ist im Fall, wenn der User Cookies deaktiviert hat ? Sind dann Sessions nicht besser ?
MfG
Simon-
Hi,
Nur was ist im Fall, wenn der User Cookies deaktiviert hat ? Sind dann Sessions nicht besser ?
Dann koennen sie in so fern "besser" sein, dass sie es etwas einfacher fuer dich machen, weil PHP einen Automatismus hat, um das zu "erkennen", und sich dann selbststaendig um die Uebergabe der SID per GET/POST zu kuemmern.
Wobei gerade die Uebergabe per GET den Session-"Diebstahl" ggf. etwas einfacher fuer Angreifer macht.MfG ChrisB
--
„This is the author's opinion, not necessarily that of Starbucks.“-
Moin!
Wobei gerade die Uebergabe per GET den Session-"Diebstahl" ggf. etwas einfacher fuer Angreifer macht.
Das ist aber auch dann der Fall, wenn man "nur Cookies" verwendet, und für den Fall, dass die abgelehnt werden, sich eine Alternative ausdenken muss.
Ist also ein Argument contra PHP-Sessions und Pro-Cookies.
Wenn man die Session-ID aus der URL fernhalten möchte, kann man sich sein PHP ja auch passend konfigurieren.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Wobei gerade die Uebergabe per GET den Session-"Diebstahl" ggf. etwas einfacher fuer Angreifer macht.
Das ist aber auch dann der Fall, wenn man "nur Cookies" verwendet, und für den Fall, dass die abgelehnt werden, sich eine Alternative ausdenken muss.aus dem grund sollte man sich nicht auf das vorhandensein eines session-cookies oder ähnlichem verlassen sondern immer das session-cookie gegen werte, die am server hinterlegt wurden (zb in einer session-datenbank), gegenprüfen (sofern dies die session-routine des webservers bzw der scriptesprache nicht ohnehin schon tut)
geeignet ist zb eine kombination aus ip-adresse und der hostname des benutzers, der verwendete user-agent, der port - das ist zwar auch noch kein 100%iger garant dafür, dass jemand die session eines anderen geklaut hat, aber es verhindert zumindest, dass jemand einem anderen benutzer einen link inkl. session-id schickt und ihm somit "uneingeschränkten zugriff" ermöglicht
-
Moin!
Wobei gerade die Uebergabe per GET den Session-"Diebstahl" ggf. etwas einfacher fuer Angreifer macht.
Das ist aber auch dann der Fall, wenn man "nur Cookies" verwendet, und für den Fall, dass die abgelehnt werden, sich eine Alternative ausdenken muss.aus dem grund sollte man sich nicht auf das vorhandensein eines session-cookies oder ähnlichem verlassen sondern immer das session-cookie gegen werte, die am server hinterlegt wurden (zb in einer session-datenbank), gegenprüfen (sofern dies die session-routine des webservers bzw der scriptesprache nicht ohnehin schon tut)
Das ist schlechterdings unmöglich.
geeignet ist zb eine kombination aus ip-adresse und der hostname des benutzers
Nein. Die IP-Adresse ist nicht konstant, und der ermittelbare Hostname des Users entspricht seiner IP-Adresse, weil genau diese als Basis für die Hostnamenermittlung herangezogen wird.
der verwendete user-agent,
Das könnte man einigermaßen als Konstante annehmen, allerdings: Was bringt es, wenn z.B. Firefox 3.0.3 massenhaft in Umlauf ist und deshalb auch massenhaft identische User-Agent-Strings benutzt werden - auch von bösen Angreifern. Wirklich individuelle Werte darf man hier nicht erwarten, das wäre extremer Zufall.
der port
Der wechselt potentiell bei jedem Request - noch häufiger, als die IP-Adresse es tut.
das ist zwar auch noch kein 100%iger garant dafür, dass jemand die session eines anderen geklaut hat,
Stimmt. Es ist absolut untauglich für sowas, weil es schon das normale Funktionieren der Session behindert.
aber es verhindert zumindest, dass jemand einem anderen benutzer einen link inkl. session-id schickt und ihm somit "uneingeschränkten zugriff" ermöglicht
Sowas wird effektiv dadurch verhindert, dass man Cookies zwingend vorschreibt.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Sowas wird effektiv dadurch verhindert, dass man Cookies zwingend vorschreibt.
was hindert mich daran, das cookie von jemandem zu klauen?
-
Moin!
Sowas wird effektiv dadurch verhindert, dass man Cookies zwingend vorschreibt.
was hindert mich daran, das cookie von jemandem zu klauen?
Beschreibe, wie du das tun willst, und ich beurteile dann, ob das ein realistisches Szenario ist.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Beschreibe, wie du das tun willst, und ich beurteile dann, ob das ein realistisches Szenario ist.
ein login in ein backend mit temporärer session (automatisches login ist nicht möglich, die session läuft nach 15 minuten ab)
wie wird verhindert, dass jemand das cookie des rechners ausspäht und sich so einloggen kann?
nach möglichkeit eine lösung die ohne ssl, ein client-zertifikat oder eine vpn-verbindung auskommt
bzw anders herum: wie verhindert man, dass ihm falle eines ausgespähten cookies der angreifer dennoch nichts damit anfangen kann?
-
Moin!
Beschreibe, wie du das tun willst, und ich beurteile dann, ob das ein realistisches Szenario ist.
ein login in ein backend mit temporärer session (automatisches login ist nicht möglich, die session läuft nach 15 minuten ab)
wie wird verhindert, dass jemand das cookie des rechners ausspäht und sich so einloggen kann?
Sag mir, wie du das Cookie ausspähen willst, und ich sage dir, ob das ein realistisches Szenario ist, welches sich durch die von dir genannten Zusatzprüfungen verhindern lässt.
Butter bei die Fische!
- Sven Rautenberg
--
"Love your nation - respect the others."-
Sag mir, wie du das Cookie ausspähen willst, und ich sage dir, ob das ein realistisches Szenario ist, welches sich durch die von dir genannten Zusatzprüfungen verhindern lässt.
mit javascript zb - cookie auslesen und die daten mit einem xmlhttprequest sofort weiterschicken
kommt öfer vor als man denkt, dass durch eine sicherheitslücke [1] javascript in den quelltext eingeschleust wird, der da eigentlich nicht hinsoll
Butter bei die Fische!
den hab ich noch nie verstanden
[1] ob die jetzt bestehen darf oder dies das eigentliche problem ist, sei dahingestellt
-
Moin!
Sag mir, wie du das Cookie ausspähen willst, und ich sage dir, ob das ein realistisches Szenario ist, welches sich durch die von dir genannten Zusatzprüfungen verhindern lässt.
mit javascript zb - cookie auslesen und die daten mit einem xmlhttprequest sofort weiterschicken
kommt öfer vor als man denkt, dass durch eine sicherheitslücke [1] javascript in den quelltext eingeschleust wird, der da eigentlich nicht hinsoll
Wenn innerhalb der Domain eine Sicherheitslücke die Ausführung von Javascript-Code ermöglicht, ist die Integrität der Daten ohnehin nicht mehr gewährleistet. Sprich: Warum sollte man sich als Angreifer dann darauf beschränken, "nur" das Session-Cookie auszulesen und weiterzuverraten (BTW: Mit AJAX funktioniert das nicht, weil dessen Requests nur wieder auf dieselbe Domain gehen dürfen). Oder anders gefragt: Was spricht dagegen, nicht einfach direkt die Gesamtumstände des fraglichen Requests mitzuverraten, also User-Agent, IP, Referrer etc.
Mit anderen Worten: Welche Sicherheit brächte es, Parameter zu prüfen, die im Normalfall genauso wie die Session-ID dem Angreifer unbekannt sind, und im erfolgreichen Angriffsfall ihm aber genauso leicht bekannt sein können.
Abgesehen davon erfordert so ein Angriff halt tatsächlich besondere Umstände, beispielsweise die tatsächliche Ausnutzbarkeit einer vorhandenen Cross-Site-Scripting-Lücke.
[1] ob die jetzt bestehen darf oder dies das eigentliche problem ist, sei dahingestellt
Im Normalfall wird so eine Lücke nicht so einfach zu finden sein. Denn erstens müsste man sie als tatsächlich eingeloggter User durch Untersuchungen auffinden (im Blindflug dürfte es ein aussichtsloses Unterfangen bleiben), und zweitens müsste sie überhaupt mal existieren.
Du magst vielleicht argumentieren, dass zusätzliche Prüfungen es für den Angreifer schwieriger machen würden. Falsch: Wenn erst einmal eine XSS-Lücke gefunden wurde, bricht das Gesamtsystem zusammen. Denn via XSS kann ja nicht nur ein Spionageskript die Sessiondaten weitersagen, sondern genausogut anstelle des eingeloggten Users via AJAX Aktivität entfalten. Und sei es nur, für die Passwort-Vergessen-Funktion eine neue Mailadresse einzutragen - oder halt sonstigen Unfug zu treiben, der leicht erreichbar ist und ansonsten erstmal unbemerkt bleibt.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hello,
Abgesehen davon erfordert so ein Angriff halt tatsächlich besondere Umstände, beispielsweise die tatsächliche Ausnutzbarkeit einer vorhandenen Cross-Site-Scripting-Lücke.
Die ist in vielen Foren und Kontaktseiten aber gegeben, da dort oft veressen wird, Benutzereingaben kontextgerecht zu codieren.
Wenn also z.B. ein Benutzer einer Kontaktseite in der Lage ist, in seinem Benutzerprofil HTML unterzubringen, das dann auch noch (ungefiltertes) inline-CSS enhalten kann, ist schon eine doppelte Lücke vorhanden.
Das gibt es öfter, als man glauben mag.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Die ist in vielen Foren und Kontaktseiten aber gegeben, da dort oft veressen wird, Benutzereingaben kontextgerecht zu codieren.
Wenn also z.B. ein Benutzer einer Kontaktseite in der Lage ist, in seinem Benutzerprofil HTML unterzubringen, das dann auch noch (ungefiltertes) inline-CSS enhalten kann, ist schon eine doppelte Lücke vorhanden.
Das gibt es öfter, als man glauben mag.
phpbb hatte afaik mal in der vergangenheit eine lücke, die unter bestimmten umständen erlaubte, javascript ungefiltert in signaturen zu verwenden - hiermit war es dann möglich die benutzerinformationen der eingeloggten benutzer ausfindig zu machen
da die userid auch als cookie hinterlegt war, war so sehr einfach an die session von administratoren und moderatoren zu kommen - mit geklauter session eingeloggt konnte man zwar nicht das passwort des admin/mod ausspionieren, aber dennoch das passwort neu zuschicken lassen um dann damit schindluder zu treiben
es reicht schon, wenn man sich als admin einloggen kann um einen neuen admin zu erzeugen - bei foren mit mehreren 10.000 benutzern und einer fülle an moderatoren ist das teilweise nicht überschaubar, wenn da einer mehr oder weniger entsprechende rechte hat
-
-
-
-
-
Hi,
bzw anders herum: wie verhindert man, dass ihm falle eines ausgespähten cookies der angreifer dennoch nichts damit anfangen kann?
Doppelte Verneinung, schwierige Verneinung ...
MfG ChrisB
--
„This is the author's opinion, not necessarily that of Starbucks.“
-
-
-
-
-
-
-
-
Hello,
Ja da ich erst Einsteiger im PHP Gebiet bin weiß ich eben nicht was für meinen Fall besser ist: User kann sich anmelden, und wird auf der Ganzen Seite als angemeldet erkannt solange er sich nicht ausloggt. Nur was ist im Fall, wenn der User Cookies deaktiviert hat ? Sind dann Sessions nicht besser ?
Lies das Posting von ChrisB nochmal, das die Zusammenhänge doch sehr deutlich gemacht hat.
Im einen Fall nutzen PHP Sessions auch Cookies.
Sie bringen dann aber auch schon die nächste Schicht mit, nämlich die Verwaltung der Session und der Sessionvariablen auf dem Server. Diese Verwaltung müsstest Du dir selber bauen, wenn Du nur mit Cookies arbeiten willst. In einen Cookie, der dann nur am Client gespeichert wäre, passen lange nicht soviele Daten, wie in ein Sessionfile, das auf dem Server gespeichert wird. Außerdem entlastet das Session-File den Traffic beim request, weil die ganzen Daten nicht jedes Mal mitgesandt werden müssen.
Sessions sind dafür da, um den Client wiederzuerkennen und für ihn so während seines ganzen Besuchszyklus, der ja i.d.R. aus dutzenden (wenn nicht sogar tausenden) von Requests besteht, immer wieder die passenden Daten bereit zu haben.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
-