|PHP - Session - Cookie oder Parameter

[bubble]

Ich probier mich momentan an einem kleinem CMS (primär zum Lernzweck).

Ich will primär nur mit HTML und CSS auskommen, quasi außer Sachen die man in Browsern deaktivieren kann, einige Funktionalität schaffen. (Momentan ein kleines Forum)

Nun sitze ich halt am Login-System und weiß nicht wirklich wie ich es planen soll. Die leichteste wären Cookies, da muss man nicht viel selbst tun, werden aber auch gerne mal deaktiviert, was mich zu 2 Lösungen führt:

Die Session-ID generell über Parameter zur verfügung zu stellen.

• Vorteil: Vereinheitlichte Handhabung der Session
• Nachteil: Caching sich selten ändernden Inhalten nicht wirklich möglich.

Beim Login Umleitung beim Login einbauen um zu testen ob der Session-Cookie gesetzt wurde oder man per Parameter die Session wieder aufnehmen muss.
Vor- und Nachteile sind quasi das Gegenteil der oberen Variante.

Was ist euerer Meinung nach besser? Oder habt ihr eine komplett-andere Herangehensweise?

MfG
bubble

[M.]

Mahlzeit,

Was ist euerer Meinung nach besser? Oder habt ihr eine komplett-andere Herangehensweise?

Session-Cookie mit Fallback auf Parameter. Sollte PHP eigentlich von sich aus können, zumindest hab ich da was im Hinterkopf.

[bubble]

Was ist euerer Meinung nach besser? Oder habt ihr eine komplett-andere Herangehensweise?
Session-Cookie mit Fallback auf Parameter. Sollte PHP eigentlich von sich aus können, zumindest hab ich da was im Hinterkopf.

Wusste ich nicht, finde aber momentan auch nicht wirklich wie das intern gehändelt wird. Ich bezweifle aber, dass PHP von sich aus GET-Parameter für Links/Forulare und was sonst noch so manipuliert, quasi brauch ich trotzdem noch eine Entscheidung, welche Variante besser ist (für das serverseitige Caching z.B.)

MfG
bubble

[mrjerk]

Hallo,

Wusste ich nicht, finde aber momentan auch nicht wirklich wie das intern gehändelt wird. Ich bezweifle aber, dass PHP von sich aus GET-Parameter für Links/Forulare und was sonst noch so manipuliert, quasi brauch ich trotzdem noch eine Entscheidung, welche Variante besser ist (für das serverseitige Caching z.B.)

Definitiv Cookie mit Fallback auf Parameter, wie M. schon schrieb. Bei Parametern besteht immer das Risiko, dass unbedarfte User URLs inkl. Session-Id kopieren und irgendwo posten,was anderen das Hijacking der Session ermöglichen kann.

Viele Grüsse,
Jörg

[dedlfix]

Tach!

Session-Cookie mit Fallback auf Parameter. Sollte PHP eigentlich von sich aus können, zumindest hab ich da was im Hinterkopf.
Wusste ich nicht, finde aber momentan auch nicht wirklich wie das intern gehändelt wird. Ich bezweifle aber, dass PHP von sich aus GET-Parameter für Links/Forulare und was sonst noch so manipuliert,

Schau dir das Session-Kapitel im PHP-Handbuch an und da vor allem die Konfigurationsparameter.

quasi brauch ich trotzdem noch eine Entscheidung, welche Variante besser ist (für das serverseitige Caching z.B.)

Wenn du mit Sessions arbeitest, werden vermutlich auch einige Daten individuell sein, zum Beispiel der eingeblendete Benutzername. Damit lässt sich höchstens noch der restliche Teil der Seite auf dem Server cachen, der dann beides zusammenbringen muss.

dedlfix.

[M.]

Mahlzeit,

quasi brauch ich trotzdem noch eine Entscheidung, welche Variante besser ist (für das serverseitige Caching z.B.)

Und was gefällt dir dabei an der Aussage "Session-Cookie mit Fallback auf Parameter" nicht? Hättest du es lieber umgekehrt? Wenn du was spezielles hören willst, musst du das schon dazusagen, sonst bekommst du evtl. Antworten die dir weiterhelfen ;)

[1UnitedPower]

Meine Herren!

Was ist euerer Meinung nach besser? Oder habt ihr eine komplett-andere Herangehensweise?

Die Session-ID in der URL mitzuschleifen ist eine ganze schlechte Idee, das ebnet alle Wege für Session-Hijacking. Der Nutzer muss nur einmal den Link aus der Adresszeile kopieren und in einem Forum teilen und schon nehmen alle Nutzer, die dem Link folgen, an der selben Session teil.

Es gibt doch im Wesentlichen zwei Gründe dafür Cookies zu deaktivieren:

1. Man möchte zustandslos, also ohne Sessions, unterwegs sein. Dann erübrigt sich die Problemstellung automatisch.

2. Man hat Sicherheitsbedenken. In dem Fall stünde die Lösung über die URL völlig im Gegensatz zur Intention des Nutzers (aus eben oben genannten Grund).

Oder habe ich da einen Fall vergessen?

[bubble]

Die Session-ID in der URL mitzuschleifen ist eine ganze schlechte Idee, das ebnet alle Wege für Session-Hijacking. Der Nutzer muss nur einmal den Link aus der Adresszeile kopieren und in einem Forum teilen und schon nehmen alle Nutzer, die dem Link folgen, an der selben Session teil.

Daran habe ich bisher nicht gedacht. Spontan würde mir aber als weg einfallen, User Agent und Remote Address in der Session zu speichern und bei jedem Request zu vergleichen, wenn es sich unterscheidet, wird sofort eine neue Session erzeugt, bei dem man nicht "eingeloggt" ist, bevor das Request bearbeitet wird.
Dann wäre man bei der Verarbeitung nicht mehr eingeloggt und bekäme ein Login-Formular zu Gesicht oder einen 403er.

Wobei trotzdem ein Restrisiko bleiben würde, dass wenn man die gleiche Remote-Adrese (z.B. durch einen Proxy) und den gleichen UA hat.

MfG
bubble

[mrjerk]

Moin,

Daran habe ich bisher nicht gedacht. Spontan würde mir aber als weg einfallen, User Agent und Remote Address in der Session zu speichern und bei jedem Request zu vergleichen, wenn es sich unterscheidet, wird sofort eine neue Session erzeugt, bei dem man nicht "eingeloggt" ist, bevor das Request bearbeitet wird.

Gibt auch einige Dienste, die das als zusätzliches Sicherheitsfeature anbieten, und die das vermutlich genau so lösen. Hat aber den Nachteil,dass die Session Flöten geht, sobald sich die IP ändert, z.b. weil sich der Router neu ein wählt o.ä.

viele Grüsse,
Jörg

[bubble]

…, dass die Session Flöten geht, sobald sich die IP ändert, z.b. weil sich der Router neu ein wählt o.ä.

Das passiert aber im Normalfall auch nur einmal am Tag oder? Also abgesehen von mobilen Geräten.

Also meine Meinung hat sich jetzt quasi so gebildet, dass bevorzugt ein Cookie verwendet wird, wenn nicht verfügbar, dann Parameter + UA/REMOTE_ADDR-Vergleich. Bis auf die 24h-Neuverbindung zum ISP dürfte das eigentlich nur Benutzer mit mobilen Endgeräten stören, die Cookies deaktiviert haben.

Dem könnte man eventuell noch entgegen gehen, in dem man die Session-ID per JavaScript aus jedem Link und Formular "rausschneidet", click- und submit-Eventhandler setzt, die die Standard-Aktion unterbinden und dynamisch den Link mit entsprechendem Parameter für die Session-ID erzeugt und aufruft. (Ob das bei POST oder PUT klappt weiß ich nicht, also ohne AJAX)

Und wenn es dann Mobil-Gerät-Benutzer mit deaktivierten Javascript und ohne Cookies ist, dem kann dann halt keiner mehr helfen bei der minimalen Chance des Hijackings der Session-ID bei gleichem UA/REMOTE_ADDR.

Hab ich jetzt noch irgendwas übersehen?

MfG
bubble

[molily]

Hallo,

Spontan würde mir aber als weg einfallen, User Agent und Remote Address in der Session zu speichern und bei jedem Request zu vergleichen

Ein User ist nicht eindeutig einer IP-Adresse zuzuordnen. Eine Session ist nicht einmal eindeutig einem User-Agent zuzuordnen.

Wie mrjerk sagt, das sind höchstens *zusätzliche* Absicherungen. Zusätzlich zu Session-Cookies. Sie beheben nicht die Probleme von Session-IDs in URLs!

Wobei trotzdem ein Restrisiko bleiben würde, dass wenn man die gleiche Remote-Adrese (z.B. durch einen Proxy) und den gleichen UA hat.

Das ist kein »Restrisiko«, sondern gang und gäbe. Der UA ist zudem einfach fälschbar.

Wenn es um Sicherheit geht, sollte man nicht versuchen, etwas eigenes zu erfinden, es sei denn, man hat sich intensiv mit vorhandenen Lösungen auseinandergesetzt. Sonst kommt etwas heraus, das tausendmal unsicherer ist als bewährte Lösungen.

Mathias

[bubble]

Spontan würde mir aber als weg einfallen, User Agent und Remote Address in der Session zu speichern und bei jedem Request zu vergleichen
Ein User ist nicht eindeutig einer IP-Adresse zuzuordnen. Eine Session ist nicht einmal eindeutig einem User-Agent zuzuordnen.

Ja, aber als Angreifer, Session-ID, UA und IP-Adresse zu erraten, selbst wenn es nur UA & IP-Adresse ist, sollte doch sehr unwahrscheinlich sein, oder?

100% risikofrei gibt es sowieso nicht.

Wenn es um Sicherheit geht, sollte man nicht versuchen, etwas eigenes zu erfinden, es sei denn, man hat sich intensiv mit vorhandenen Lösungen auseinandergesetzt. Sonst kommt etwas heraus, das tausendmal unsicherer ist als bewährte Lösungen.

Ich möchte eben nichts neues erfinden, sondern wissen wie ich es am besten mache.

Aus deinem Post interpretier ich, dass Session-Cookies schlimm genug sind und ich lieber kein Fallback via GET-Parameter machen soll. (Jede Seite als Antwort als POST-Request fällt ja sowieso aus)

MfG
bubble

[Sven Rautenberg]

Moin!

Spontan würde mir aber als weg einfallen, User Agent und Remote Address in der Session zu speichern und bei jedem Request zu vergleichen
Ein User ist nicht eindeutig einer IP-Adresse zuzuordnen. Eine Session ist nicht einmal eindeutig einem User-Agent zuzuordnen.
Ja, aber als Angreifer, Session-ID, UA und IP-Adresse zu erraten, selbst wenn es nur UA & IP-Adresse ist, sollte doch sehr unwahrscheinlich sein, oder?

100% risikofrei gibt es sowieso nicht.

Die Sicherheit bei Nutzung von "Sessions" kommt primär aus a) dem sehr großen Zahlenbereich möglicher IDs, aus dem möglichst kryptographisch zufällig eine ausgewählt wird (macht es unmöglich, die ID zu erraten) b) dem Abschotten dieser Information während der Kommunikation zwischen Browser und Server.

Aus diesem Grund b) will man die Session-ID ausschließlich per Cookie übertragen (das Cookie kommt nicht unabsichtlich in Links und Formulardaten vor), und auch niemals eine Session-ID aus anderen Quellen als Cookies akzeptieren (PHP könnte so konfiguriert werden, dass eine Session-ID beim ersten Request im Link drinsteht, danach ins Cookie geschoben wird).

Weiterhin wird man zur Absicherung der Session nach dem Erhöhen des Rechte-Levels einer Session (üblicherweise der Login - vorher ist man anonym und kann nichts, hinterher hat man z.B. Schreibrechte auf seine Accountdaten) eine neue Session-ID generieren und die Session unter dieser neuen ID mit den erhöhten Rechten fortsetzen, um zu verhindern, dass doch irgendwie die vorherige ID bekannt geworden ist.

Und das Session-Cookie selbst sollte auch bestmöglich abgesichert werden. Es gibt dazu ein paar Stellschrauben: Definitiv sollte es HTTP-only sein (Javascript braucht die Session nie für legitime Zwecke wissen, bei Ajax-Requests wird es ja automatisch wieder mitgeschickt), idealerweise auch "secure" (also SSL/TLS benutzen). Weiterhin sollte man vermeiden, die Cookie-Domain allzu freizügig zu wählen, denn bei der Nutzung von Wildcard-Domains steigt die Zahl der möglicherweise gehackten Server, die das Cookie evtl. unbeabsichtigt erfahren, enorm. Man sollte genau die Domain für das Cookie erlauben, auf der sich die Applikation befindet. Befinden sich mehrere Applikationen auf demselben Server, die parallel verschiedene Sessions benutzen, sollte man auch den Pfad, bei dem das Cookie mitgesendet wird, entsprechend auf seinen eigenen Pfad eingrenzen:

http://de1.php.net/manual/de/function.session-set-cookie-params.php

session_set_cookie_params(0, '/the_app', 'www.example.com', false, true);

In der Reihenfolge der Parameter:

0 - Timeout des Cookies, hier: Bis der Browser geschlossen wird. Es gibt vielleicht Gründe, hier eine explizite Zeit anzugeben, aber man sollte sich der Konsequenzen daraus bewußt sein. Es hilft jedenfalls nicht im Hinblick auf die Sicherheit.

'/the_app' - Pfad der Applikation. Wenn ALLE Requests, die mit Session zu tun haben, sich im Pfad mit diesem Anfangsverzeichnis abspielen, kriegt ein Skript außerhalb des Pfades das Cookie nicht.

'www.example.com' - die Domain, auf der die Session gelten soll. Für Sessions übergreifend über mehrere Subdomains würde hier sowas wie '.example.com' stehen und das Risiko erhöhen.

false - Secure-Flag verhindert, dass das Cookie gesendet wird, wenn der Browser keine HTTPS-Verbindung benutzt. Wenn man also kein SSL hat, will man das Flag nicht setzen, sonst würde nichts funktionieren. Andererseits will man es unbedingt setzen, wenn man ausschließlich SSL benutzen kann.

true - HTTP-only-Flag verhindert, dass Javascript an das Cookie rankommt. Will man immer haben.

Wenn es um Sicherheit geht, sollte man nicht versuchen, etwas eigenes zu erfinden, es sei denn, man hat sich intensiv mit vorhandenen Lösungen auseinandergesetzt. Sonst kommt etwas heraus, das tausendmal unsicherer ist als bewährte Lösungen.

Ich möchte eben nichts neues erfinden, sondern wissen wie ich es am besten mache.

Aus deinem Post interpretier ich, dass Session-Cookies schlimm genug sind und ich lieber kein Fallback via GET-Parameter machen soll. (Jede Seite als Antwort als POST-Request fällt ja sowieso aus)

Session-Cookies sind eigentlich kein soo schlimmes Problem, aber man muss in PHP schon einiges an Extra-Arbeit und -Konfiguration leisten, um eine bessere Sicherheit zu erhalten. Für Applikationen ohne SSL-Verschlüsselung dürfte das zwar nicht viel helfen, weil es sowieso unsicher ist, aber es hebt das Schutzniveau zumindest etwas.

Ganz fatal sind jedenfalls Session-IDs, die in Links und Formularen übertragen werden, oder vom Server darin akzeptiert werden. Dann kann ein Angreifer eine ihm bekannte Session-ID in einen Link schreiben und jemandem zumailen, und kann dann die Session übernehmen.

- Sven Rautenberg

[bubble]

Wie schon gesagt hab ich jetzt verdammt viel zu lesen.

Hoffentlich geht das hier nicht unter:

Danke an alle :)

MfG
bubble

[molily]

Hallo,

Definitiv sollte es HTTP-only sein (Javascript braucht die Session nie für legitime Zwecke wissen, bei Ajax-Requests wird es ja automatisch wieder mitgeschickt)

Das ist auch das Problem von HttpOnly. In dem Fall, wo HttpOnly nützlich ist, nämlich Cross-Site Scripting, hilft es nur bedingt. Es verhindert, dass die Session-ID den Browser verlässt und von einem anderen Rechner aus authentifizierte Requests abgesendet werden. Es hilft nicht dagegen, dass der durch XSS ferngesteuerte Browser authentifizierte Requests absendet, das UI verändert und so den Nutzer täuscht, Logout-Möglichkeiten unschädlich macht usw.

Der Artikel http://www.gnucitizen.org/blog/why-httponly-wont-protect-you/ beschreibt das schön. Ich stimme zwar dem Tenor nicht zu, dass HttpOnly nutzlos sei. Es ist aber korrekt, dass das Auslesen und Versenden des Cookies für den Angreifer weniger ergiebig ist als das direkte Senden von Requests vom kompromittierten Browser aus. Bei Persistent XSS sitzt der Angreifer an der Quelle, er kann Schadcode ausführen, der eine stets aktuelle Session nutzen kann. Der Angreifer hat wenig dadurch gewonnen, wenn er die vergängliche Session-ID zudem versenden kann.

Mathias

[Tom]

Hello,

Spontan würde mir aber als weg einfallen, User Agent und Remote Address in der Session zu speichern und bei jedem Request zu vergleichen
Ein User ist nicht eindeutig einer IP-Adresse zuzuordnen. Eine Session ist nicht einmal eindeutig einem User-Agent zuzuordnen.
Ja, aber als Angreifer, Session-ID, UA und IP-Adresse zu erraten, selbst wenn es nur UA & IP-Adresse ist, sollte doch sehr unwahrscheinlich sein, oder?

100% risikofrei gibt es sowieso nicht.

Die Sicherheit bei Nutzung von "Sessions" kommt primär aus

a) dem sehr großen Zahlenbereich möglicher IDs, aus dem möglichst kryptographisch zufällig eine ausgewählt wird (macht es unmöglich, die ID zu erraten)

b) dem Abschotten dieser Information während der Kommunikation zwischen Browser und Server.

c) einer möglichst kurzen Zeitspanne, in der der Einfach-Schlüssel (die Session-ID) passt

http://de3.php.net/manual/en/function.session-regenerate-id.php

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Die Session-ID in der URL mitzuschleifen ist eine ganze schlechte Idee, das ebnet alle Wege für Session-Hijacking. Der Nutzer muss nur einmal den Link aus der Adresszeile kopieren und in einem Forum teilen und schon nehmen alle Nutzer, die dem Link folgen, an der selben Session teil.

Klar, das wäre dann der Fall, wenn die Session-ID zeitlich unbegrenzte Gültigkeit hätte. Aber die kann man durchaus sehr kurz halten:

http://de3.php.net/manual/en/function.session-regenerate-id.php

Der Timeslot für eine gültige Session-ID schrumpft damit auf die Zeit zwischen zwei Requests des Sessioninhabers auf Ressourcen innerhalb des Sessions-Realms.

Das Verfahren macht nur dann Probleme, wenn man Sessions-Daten zwischen mehrerten Servern / Hosts austauschen muss.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[1UnitedPower]

Meine Herren!

Das Verfahren macht nur dann Probleme, wenn man Sessions-Daten zwischen mehrerten Servern / Hosts austauschen muss.

Oder wenn ich von einer Seite aus zwei oder mehr Links folgen möchte. Das ist ein Standard-Szenario: Man liest auf einer Seite, öffnet ein paar Tabs im Hintergrund, liest ein wenig weiter und wechselt anschließend zu den offenen Tabs. Das zuerst geöffnete Tab macht noch keine Probleme. Alle weiteren Tabs nehmen aber nicht mehr an einer gültigen Session teil. Wir erkaufen hier also Sicherheit auf Kosten der Bedienbarkeit. Gute und sinnvoller Ergänzung deinerseits, und sicher besser als eine Sicherheitslücke aufzureißen, aber für die Praxis kein relevantes Vorgehen.

[Tom]

Hello,

Das Verfahren macht nur dann Probleme, wenn man Sessions-Daten zwischen mehrerten Servern / Hosts austauschen muss.

Oder wenn ich von einer Seite aus zwei oder mehr Links folgen möchte. Das ist ein Standard-Szenario: Man liest auf einer Seite, öffnet ein paar Tabs im Hintergrund, liest ein wenig weiter und wechselt anschließend zu den offenen Tabs. Das zuerst geöffnete Tab macht noch keine Probleme. Alle weiteren Tabs nehmen aber nicht mehr an einer gültigen Session teil. Wir erkaufen hier also Sicherheit auf Kosten der Bedienbarkeit. Gute und sinnvoller Ergänzung deinerseits, und sicher besser als eine Sicherheitslücke aufzureißen, aber für die Praxis kein relevantes Vorgehen.

Das Verfahren ist auch nur dann sinnvoll, wenn man session.use_only_cookies auf true gesetzt hat. Dann geht jeder Request mit dem frischen Cookie raus.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[bubble]

Das Verfahren ist auch nur dann sinnvoll, wenn man session.use_only_cookies auf true gesetzt hat. Dann geht jeder Request mit dem frischen Cookie raus.

Angenommen man ist auf Seite A, öffnet Tab B und Tab C in neuen Tabs, recht schnell hintereinander, dass weder B noch C geladen sind. Dann wird einer der Tabs versagen, da er mit der falschen Session anfragt.

(Irgendwie kommt mir das bekannt vor)

MfG
bubble

[Tom]

Hello,

Das Verfahren ist auch nur dann sinnvoll, wenn man session.use_only_cookies auf true gesetzt hat. Dann geht jeder Request mit dem frischen Cookie raus.

Angenommen man ist auf Seite A, öffnet Tab B und Tab C in neuen Tabs, recht schnell hintereinander, dass weder B noch C geladen sind. Dann wird einer der Tabs versagen, da er mit der falschen Session anfragt.

(Irgendwie kommt mir das bekannt vor)

Das sollte aber nicht passieren, da der Browser immer den letzten Cookie gespeichert hat für die Domain oder einen Teil davon, je nachdem, was der Anbieter vorgeschlagen hat.

Nur, wenn Session-Informationen noch sonstwo versteckt sind und der Angefragte (der Host des Request-Auswerters) eventuell dubiose Dinge damit treibt, geht das schief. Dubiose Dinge könnten sein, wenn er die eintreffenden Session-IDs in $_POST, $_GET und $_COOKIE selber auswertet, oder aber die Reihenfolge GPC

http://www.php.de/wiki-php/index.php/Request
http://de1.php.net/manual/en/ini.core.php#ini.variables-order

verändert hat, wird es kritisch.

Man kann eine Session sonst so trimmen, dass sie nur auf den sogenannten "Session-Cookie" hört.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[1UnitedPower]

Meine Herren!

Das sollte aber nicht passieren, da der Browser immer den letzten Cookie gespeichert hat

In einer idealen Welt, in der es keine Latenzen bei Netzwerk-Kommunikation und keine Laufzeit von Programmen gäbe, ist das richtig. In der echten Welt können wir nicht so agnostisch hantieren.

[bubble]

Angenommen man ist auf Seite A, öffnet Tab B und Tab C in neuen Tabs, recht schnell hintereinander, dass weder B noch C geladen sind. Dann wird einer der Tabs versagen, da er mit der falschen Session anfragt.

Das sollte aber nicht passieren, da der Browser immer den letzten Cookie gespeichert hat für die Domain oder einen Teil davon, je nachdem, was der Anbieter vorgeschlagen hat.

Was ich meinte ist Seite B wird geöffnet sendet im Request Session Cookie mit, auf dem Server wird die neue Session-ID generiert, noch bevor die Antwort vom Server kommt (also bevor der Session-Cookie vom Browser aktualisiert wurde, aber auf dem Server schon die neue Session existiert und die alte zerstört wurde), wird Seite C geöffnet.
In dem Moment kommt eine nicht mehr aktuelle Session beim beim Server an und der meckert dann rum.

MfG
bubble

[Der Martin]

Hallo,

Die Session-ID in der URL mitzuschleifen ist eine ganze schlechte Idee, das ebnet alle Wege für Session-Hijacking. Der Nutzer muss nur einmal den Link aus der Adresszeile kopieren und in einem Forum teilen und schon nehmen alle Nutzer, die dem Link folgen, an der selben Session teil.

aber genau das ist doch das Ziel, wenn ich einen Link *mit* Session-ID weitergebe. Das tu ich doch gerade, damit jemand anders dieselbe Session weiterverwenden kann und dasselbe sieht wie ich.

Ciao,
 Martin

[1UnitedPower]

Meine Herren!

aber genau das ist doch das Ziel, wenn ich einen Link *mit* Session-ID weitergebe.

Du bist auch ein affiner Web-Entwickler ;) Das trifft leider nicht auf alle Surfer zu und die Unerfahrenen sind doch insbesondere schutzbedürftig.

Die einzige sichere (TM) Lösung dieses Problem ist durch Einsatz von HTTPS mit Client-Zertifikaten.

@bubble: Auf solche unsauberen Hacks mit IP-Adressen würde ich mich nicht einlassen.

[bubble]

@bubble: Auf solche unsauberen Hacks mit IP-Adressen würde ich mich nicht einlassen.

Bevor ich gefragt hab, dachte ich das einer der beiden Wege der Richtige sei. Mittlerweile vertrau ich keinem von beidem so wirklich.

Die einzige sichere (TM) Lösung dieses Problem ist durch Einsatz von HTTPS mit Client-Zertifikaten.

HTTPS, ich hab mich noch nicht wirklich damit auseinander gesetzt muss ich zugegen, aber von dem was ich bisher gelesen hab, ist das doch nur ein verschlüsseltes HTTP-Request + Response, wobei es für die serverseitige Identifizierung des Clients keine Rolle spielt, oder?

aber genau das ist doch das Ziel, wenn ich einen Link *mit* Session-ID weitergebe.
Du bist auch ein affiner Web-Entwickler ;) Das trifft leider nicht auf alle Surfer zu und die Unerfahrenen sind doch insbesondere schutzbedürftig.

Das find ich verwirrend und interessant zugleich, bitte erklärt das näher. :)

MfG
bubble

[1UnitedPower]

Meine Herren!

@bubble: Auf solche unsauberen Hacks mit IP-Adressen würde ich mich nicht einlassen.

Bevor ich gefragt hab, dachte ich das einer der beiden Wege der Richtige sei. Mittlerweile vertrau ich keinem von beidem so wirklich.

Die Schuld liegt auch ein bischen bei mir. Ich denke gerade drei Schritte weit und schreibe davon nur Schritt zwei auf. Ich versuche es mal langsamer:

Also, wenn du mit Sessions hantierst, besteht natürlich immer das potenzielle Risiko, dass ein Angreifer die Sitzung eines Opfers übernimmt (Session-Hijacking) oder dass ein Angreifer einem fremden Nutzer eine Sitzung unterjubelt (Session-Fixation). Das ist ein Risiko, das ohne Sitzungen nicht auftritt, aber das macht Sitzungen nicht automatisch zu einer Bedrohung. Umgekehrt ist eine Seite ohne Sitzungen übrigens auch nicht automatisch „sicher“, was man immer man sich darunter vorstellen mag. Aber es müssen natürlich Vorkehrungen getroffen werden.

Die Session-ID ist aus kryptographischer Sicht ein »Geheimnis«, das sich Server und Client teilen und worüber sie sich identifizieren. Geheimnis ist in der Kryptographie tatsächlich ein sehr bedeutungsschwangerer Terminus, aber dass es _geheim_ gehalten werden sollte, sagt uns auch der gesunde Menschenverstand.

Wenn wir das Geheimnis also an den URL kleben, müssen wir dafür sorgen, dass dieser ebenfalls geheim bleibt. Falls wir das Geheimnis im Cookie speichern, müssen wir eben zusehen, dass der Cookie geheim bleibt. Der URL steht i.A. in der Adresszeile des Nutzers und der naive Nutzer kann überhaupt nicht wissen, dass wir da putze lustig sicherheitskritische Daten speichern. Der Cookie ist vor einer solchen „Fehl“-Bedienung durch den Nutzer wesentlich unanfälliger. Wann teilt man schon mal einen Mitschnitt seines HTTP-Netzwerk-Verkehrs oder seine Cookies-Dateien?

Nun gehen wir davon aus, dass der Nutzer selbst keine Gefahr für sich selbst mehr darstellt. Aber was ist, wenn es einem Angreifer gelingt, sich irgendwo in der Verbindung zwischen Client und Server einzuhängen und mitzuhören, was die sich so zu sagen haben? In dem Fall spielt es keine Rolle, ob die Session-ID im Cookie oder URL transportiert wird, der Angreifer kann sie lesen. Die Lösung ist so simpel wie effektiv: Man verschlüsselt die Verbindung. Das kann zum Beispiel mit HTTPS geschehen. Aber HTTPS kann auch mehr, es kann über Server-Zertifikate, die oft von einer dritten unabhängigen Partei ausgestellt werden, dem Client eine gewisse Garantie geben, dass es wirklich der Server ist, mit dem er reden möchte. Der umgekehrte Weg kann auch gegangen werden, dann spricht man analog von Client-Zertifikaten.

Interessant ist nun, dass wir eine Session-ID direkt mit einem Client, der sich zertifiziert! hat, in Verbindung bringen können. In diesem Fall haben wir tatsächlich eine verlässliche Methode, um die Sitzung einem Client zuzuordnen und haben damit eine viel stärkere Identifizierungsmöglichkeit als über die Session-ID alleine. Theoretisch können wir nun die Session-ID auch über den URL transportieren, weil unser Server nur noch das Tupel aus Session-ID und zertifiziertem Client toleriert (natürlich nicht automatisch, dass muss unsere Anwendungsschicht implementieren). Client-Zertifikate sind leider ein selten genutztes Feature und erfordern manuelle Installtions-Schritte des Nutzers, die nicht ganz einfach sind.

[bubble]

Ich erspar mir mal das zitieren.

Verdammt ich hab noch eine Menge zu lesen, mal von https abgesehn, was dann noch mal viel mehr sein wird.

Also ist mein Ziel jetzt HTTPS zu verwenden + Session Cookies und Parameter-Session-ID/Restriktion+Information. Das wird mir einige Wochen Lesestoff bieten, da mein Englisch nicht das beste ist :'D

[T-Rex]

Aloa,

ich möchte hier mal der kleine Mann im Ohr sein.
Wenn du ein Shopsystem hast wo der User effektiv Geld verlieren kann und es zu teuren Gerichtsverfahren kommen könnte, sollte man das System so sicher wie möglich machen.
Wenn jemand deinen Chataccount hackt und sich als du ausgibt - wen interessiert es? Im schlimmsten Fall wirst du gebannt, meldest dich neu an und weiter gehts.

Ich finde über https gibt es nicht soooo viel zu wissen. Es stellt einfach eine sichere Verbindung da. Wenn du natürlich im Detail wissen willst wie das implementiert ist, dann haste wirklich was vor dir. Aber mal anders gefragt, schaust du dir an wie ein Auto zusammengebaut ist, bevor du es kaufst?

Gruß
kleiner Mann im Ohr
T-Rex

[Der Martin]

Hallo,

Ich finde über https gibt es nicht soooo viel zu wissen. Es stellt einfach eine sichere Verbindung da. Wenn du natürlich im Detail wissen willst wie das implementiert ist, dann haste wirklich was vor dir.

sehe ich auch so.

Aber mal anders gefragt, schaust du dir an wie ein Auto zusammengebaut ist, bevor du es kaufst?

Nee (oder nur sehr eingeschränkt). Aber hinterher schon.
Noch stärker ist meine Neugier bei Elektronik-Produkten ausgeprägt. Nach dem Kauf erstmal aufschrauben und sehen, was drinsteckt, wie es realisiert ist - vorausgesetzt, das Produkt lässt sich relativ leicht und vor allem zerstörungsfrei öffnen (geschraubt, geclipst o.ä.).

Ciao,
 Martin

[Tom]

Hello,

Ich probier mich momentan an einem kleinem CMS (primär zum Lernzweck).

Gute Idee

Ich will primär nur mit HTML und CSS auskommen, quasi außer Sachen die man in Browsern deaktivieren kann, einige Funktionalität schaffen. (Momentan ein kleines Forum)

Das wird nicht reichen, aber Du hast ja auch sinnvollerweise schon daws Thema PHP ausgewählt.

Nun sitze ich halt am Login-System und weiß nicht wirklich wie ich es planen soll. Die leichteste wären Cookies, da muss man nicht viel selbst tun, werden aber auch gerne mal deaktiviert, was mich zu 2 Lösungen führt:

Wer sich Webinhalte zunutze machen will, sollte als User auch dazu bereit sein, Cookies zu akzeptieren. Lehnt er die ab, bekommt er eben keinen Benefit.

Ich habe hier ca. 1998 auch mal ein Loginsystem vorgestellt, dass wahlweise mit Cookies oder mit Basic-Authentification arbeitet. Der User bekommt davon eigentlich nicht viel mit, außer, dass er sich bei Basic-Auth (damals) noch nicht wieder abmelden konnte.

Beim "Login" solltest Du immer unterscheiden zwischen sessionbasierter und requestbasierter Berechtigungsprüfung.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Jörg Reinholz]

• Nachteil: Caching sich selten ändernden Inhalten nicht wirklich möglich.

Und es geht doch! PHP: Einfaches Caching für Webprojekte.

Jörg Reinholz

[hotti]

hi,

Was ist euerer Meinung nach besser? Oder habt ihr eine komplett-andere Herangehensweise?

hier beschrieben

Meine Antwort: Machs mit Cookie. Wer Cookies nicht annimmt, will sich auch nirgendwo einloggen.
Manipulierbar ist Beides.

noch was zum Cachen

Horst