nicht angemeldet
session.referer_check
Hallo liebe Forumer!
Hier wurde ja schon x-mal breitgetreten, daß man sich auf einen Referer nicht verlassen kann. Weil er vom Client nicht gesendet wird, weil er manipuliert ist.
Ist es gut in einem geschützten Bereich einer Internetpräszenz, genauer gesagt, einem Redaktionssystem, session.referer_check zu setzen oder handelt man sich damit Nachteile ein?
Zitat aus dem PHP-Manual:
"session.referer_check enthält die Zeichenkette, auf die Sie jeden HTTP-Referer überprüfen wollen. Wenn der Referer vom Client gesendet und die Zeichenkette nicht gefunden wurde, wird die eingebettete Session-ID als ungültig gekennzeichnet. Grundeinstellung ist eine leere Zeichenkette."
Beste Grüße
Viennamade
-
Ist es gut in einem geschützten Bereich einer Internetpräszenz, genauer gesagt, einem Redaktionssystem, session.referer_check zu setzen
Ja.
oder handelt man sich damit Nachteile ein?
Nein. Aber auch keine Vorteile.
-
Hallo!
Danke für die Antwort!
Ist es gut in einem geschützten Bereich einer Internetpräszenz, genauer gesagt, einem Redaktionssystem, session.referer_check zu setzen
Ja.oder handelt man sich damit Nachteile ein?
Nein. Aber auch keine Vorteile.Aber das widerspricht sich doch. Wenn session.referer_check keine Vorteile bringt, dann kann es doch nicht gut sein darin eine Zeichenkette einzusetzen?!
Verhindern kann session.referer_check, daß irgendjemand von irgendwo irgendwie auf die geschützten Seiten kommt.
Vielleicht ist es ein Nachteil, daß ein Zugangsberechtigter nicht mehr von einem leeren Browserfenster zur login-Maske gelangen kann?Beste Grüße
Viennamade-
Hallo!
Verhindern kann session.referer_check, daß irgendjemand von irgendwo irgendwie auf die geschützten Seiten kommt.
Nein. Ich kann jeden Referer an den Server senden, der mit passt. Was ist, wenn der Referer z.B. von einem Proxy oder irgendeiner tollen "Internet-Security-Software" auf dem Desktop gefiltert wird?
Grüße
Andreas--
SELFHTML Feature Artikel: http://aktuell.de.selfhtml.org/artikel/-
Hallo!
Hallo!
Verhindern kann session.referer_check, daß irgendjemand von irgendwo irgendwie auf die geschützten Seiten kommt.
... Ich kann jeden Referer an den Server senden, der mir passt ...
Diese obige Aussage von Dir, und folgendes Zitat aus dem Manual:
__Wenn der Referer vom Client gesendet___ und die Zeichenkette nicht gefunden wurde, wird die eingebettete Session-ID als ungültig gekennzeichnet.läßt doch den Schluß zu, daß die Verwendung von session.referer_check nicht Wirklich Sinn macht.
Beste Grüße
Viennamade-
Moin!
Verhindern kann session.referer_check, daß irgendjemand von irgendwo irgendwie auf die geschützten Seiten kommt.
... Ich kann jeden Referer an den Server senden, der mir passt ...
Diese obige Aussage von Dir, und folgendes Zitat aus dem Manual:
__Wenn der Referer vom Client gesendet___ und die Zeichenkette nicht gefunden wurde, wird die eingebettete Session-ID als ungültig gekennzeichnet.läßt doch den Schluß zu, daß die Verwendung von session.referer_check nicht Wirklich Sinn macht.
Gut erkannt.
Unter definierbaren Umständen (also z.B. Intranet) kann man natürlich durch Installation bzw. Nicht-Installation entsprechender Software garantieren, dass immer der richtige Referrer gesendet wird, solange die Browser normal genutzt werden. Dann ist aber der zusätzliche Schutzeffekt des Referrer-Checks irgendwie nicht wirklich vorhanden, denn ein Intranet könnte man ja auch aufgrund des bestimmbaren IP-Raumes eingrenzen und den Zugriff ansonsten verweigern.
Echt verhindert werden Übernahmen von Sessions durch referer-Check sowieso nicht. Es wird nur schwieriger, durch zufälliges Raten anzugreifen. Solch ein Rate-Angriff ist aber allein durch die Session-ID, welche man ja richtig tippen muß, schon äußerst unwahrscheinlich.
Der einzige wirklich denkbare Angriff wäre, dass die übermittelten Daten abgehört werden, um so das Raten zu umgehen. Das dürfte aber nur bei wirklich wichtigen Anwendungen relevant werden und ist mit SSL recht einfach zu verhindern.
- Sven Rautenberg
-
-
-
Aber das widerspricht sich doch. Wenn session.referer_check keine Vorteile bringt, dann kann es doch nicht gut sein darin eine Zeichenkette einzusetzen?!
Nur weil es keine Vorteile bringt, muß es ja noch lange keine Nachteile mit sich bringen. Wobei ich das insofern relativeren muss, als das es hier um nennenswerte Vorteile geht und doch einen klitzekleinen Nachteil hat.
- Der Referrer ist, wie Andreas bereits schrieb, relativ leicht zu manipulieren, relativ im Vergleich zum Erraten oder Ausspionieren einer aktiven Session-ID. Die zusätzliche Sicherheit durch referer_check ist daran gemessen kaum der Rede wert.
- Anonymisierer senden bisweilen Müll anstatt den Referrer zu unterdrücken. Allerdings sind Funktionen zum Schutz der Privatssphäre in vielen Browsern mittlerweile eingebaut, womit sich derartige Zusatzsoftware erübrigt.
Vielleicht ist es ein Nachteil, daß ein Zugangsberechtigter nicht mehr von einem leeren Browserfenster zur login-Maske gelangen kann?
Nein, die Session kann man auch problemlos noch starten, nachdem Benutzername und Passwort für gültig erklärt wurden. Meiner Meinung nach sollte man das sogar, denn erstens bedeutet dann schon die Existenz einer Session in jedem Fall einen angemeldeten Benutzer, während bei der Methode Session-schon-vor-Login die Session auch für Leute existieren würde, die sich noch überhaupt nicht identifiziert haben. Und zweitens hasse ich unnötige Cookies.
Außerdem greift referer_check nur zu, wenn vom Browser auch ein Referer gesendet wurde. Dies ist bei Eintippen der URL nie der Fall und beim überwiegenden Teil der Browsern auch dann nicht, wenn die URL aus den Lesezeichen aufgerufen wurde.
-
Hi!
Nein, die Session kann man auch problemlos noch starten, nachdem Benutzername und Passwort für gültig erklärt wurden. Meiner Meinung nach sollte man das sogar, denn erstens bedeutet dann schon die Existenz einer Session in jedem Fall einen angemeldeten Benutzer, während bei der Methode Session-schon-vor-Login die Session auch für Leute existieren würde, die sich noch überhaupt nicht identifiziert haben.
Aber darauf kann und sollte man sich nicht verlassen. Eine Session existiert auch (bzw. wird erzeugt) wenn ich dem Server eine unbekannte Session-ID schicke. Auch kann man sich eine gültige Session evtl. in einem anderen Script, oder je nach Konfiguration auf einem anderen virtuellen Host holen! Das Vorhandensein einer Session(-ID) sagt erstmal überhaupt nichts aus. Die Information ob der User eingeloggt ist würde ich daher immer in der Session speichern, da der User hier garantiert keinen Einfluss drauf hat. Und genau so den Timestamp des letzten Requests, um die Session nach X Minuten zu leeren, und ein neues Login zu fordern. Wenn man jetzt noch grundsätzlich nur die md5-Summen der Passwörter speichert und SSL-Verschlüsselung verwendet, würde ich mir keine Sorgen machen.
Grüße
Andreas--
SELFHTML Tipps & Tricks: http://aktuell.de.selfhtml.org/tippstricks/-
bedeutet dann schon die Existenz einer Session in jedem Fall einen angemeldeten Benutzer,
Das Vorhandensein einer Session(-ID) sagt erstmal überhaupt nichts aus.
Richtig, siehe meine Antwort an Sven.
Und genau so den Timestamp des letzten Requests, um die Session nach X Minuten zu leeren, und ein neues Login zu fordern.
Dafür gibt es doch session.gc_maxlifetime ("session.gc_maxlifetime specifies the number of seconds after which data will be seen as 'garbage' and cleaned up", standardmäßig nach 24 Minuten).
-
Moin!
Und genau so den Timestamp des letzten Requests, um die Session nach X Minuten zu leeren, und ein neues Login zu fordern.
Dafür gibt es doch session.gc_maxlifetime ("session.gc_maxlifetime specifies the number of seconds after which data will be seen as 'garbage' and cleaned up", standardmäßig nach 24 Minuten).
Nein, das ist für exakt arbeitende Logouts unbenutzbar. PHP arbeitet mit einer Löschwahrscheinlichkeit für die alten Session-Daten. Default: 1%. Das bedeutet, dass durchschnittlich nur bei einem von hundert Zugriffen die alten Session-Daten gelöscht werden. Genausogut können die aber auch mehr als 24 Stunden oder gar wochenlang ungelöscht auf dem Server liegenbleiben.
- Sven Rautenberg
-
Und genau so den Timestamp des letzten Requests, um die Session nach X Minuten zu leeren, und ein neues Login zu fordern.
Dafür gibt es doch session.gc_maxlifetime
Nein, das ist für exakt arbeitende Logouts unbenutzbar. PHP arbeitet mit einer Löschwahrscheinlichkeit für die alten Session-Daten. Default: 1%.
Es spricht nichts dagegen, diesen Wert hochzusetzen. Aber wer drauf steht, kann es natürlich auch manuell machen.
-
Moin!
Nein, das ist für exakt arbeitende Logouts unbenutzbar. PHP arbeitet mit einer Löschwahrscheinlichkeit für die alten Session-Daten. Default: 1%.
Es spricht nichts dagegen, diesen Wert hochzusetzen. Aber wer drauf steht, kann es natürlich auch manuell machen.
Wenn man diesen Performancenachteil grundsätzlich in Kauf nehmen will, kann man das natürlich tun.
- Sven Rautenberg
-
-
-
-
-
Moin!
Nein, die Session kann man auch problemlos noch starten, nachdem Benutzername und Passwort für gültig erklärt wurden. Meiner Meinung nach sollte man das sogar, denn erstens bedeutet dann schon die Existenz einer Session in jedem Fall einen angemeldeten Benutzer, während bei der Methode Session-schon-vor-Login die Session auch für Leute existieren würde, die sich noch überhaupt nicht identifiziert haben. Und zweitens hasse ich unnötige Cookies.
Die Existenz einer Session darf kein Kriterium für einen angemeldeten Besucher sein. Das wäre im höchsten Maße gefährlich, weil man sich Sessions jederzeit selbst starten kann. Kleiner Seitenhieb am Rande: Wie man Sessions und Userzugangsberechtigungen nicht prüfen sollte, hat die Telekom ja gerade mit ihrem OBSOC gezeigt.
Es hilft der Realisierung, wenn man jedem Besucher der Site standardmäßig eine Session verpaßt. Ob der Besucher als eingeloggt zu betrachten ist, muß in den Session-Daten drinstehen.
Angesichts der Tatsache, dass es sich um ein Redaktionssystem handelt, ist dein Einwand bezüglich überflüssiger Cookies unbedeutend: Wer auf so eine Seite geht, will sich in der Regel einloggen. Wer hingegen böse Absichten hegt, der muß eben unter dem Cookie leiden - das ist Pech. ;)
- Sven Rautenberg
-
bedeutet dann schon die Existenz einer Session in jedem Fall einen angemeldeten Benutzer,
Die Existenz einer Session darf kein Kriterium für einen angemeldeten Besucher sein. Das wäre im höchsten Maße gefährlich, weil man sich Sessions jederzeit selbst starten kann.
Richtig, ich habe einen Teil vergessen zu erwähnen: Ich bin davon ausgegangen, dass auf die Sessiondaten im Skript zugegriffen wird. Eine Session-ID lässt sich von außerhalb erfinden/fälschen, aber nicht die Daten, die zur Session gehören, denn die bleiben auf dem Server.
Die einfache Abfrage, ob eine Session-ID übergeben wurde, ist natürlich zwecklos, da hast Du vollkommen recht. Es muss zwingend ein Wert der Session genutzt werden, z.B. $_SESSION["user"]. Sowas kann nicht von außen injiziert werden, deshalb reicht alleine die Existenz als Ist-angemeldet-Kennzeichen.Kleiner Seitenhieb am Rande: Wie man Sessions und Userzugangsberechtigungen nicht prüfen sollte, hat die Telekom ja gerade mit ihrem OBSOC gezeigt.
Das war ein anders gelagerter Fall. Man musste sich schon erst anmelden, davon, dass man alleine mit einer erfundenen Session-ID Zugriff hatte, wurde nicht berichtet. Das oder besser ein Problem war also vielmehr eine unzulängliche Berechtigungsverwaltung: alle Kunden hatten gewissermaßen die gleiche Identität und deshalb Zugriff auf alle Kundenverträge (ich meine Nutzung der Vertragsdaten mit "Kundenlevel"). Dass dort tatsächlich Sessiondaten überprüft wurden, zeigt sich daran, dass man mit erlangtem Kundenzugriff zwar alle Kundenverträge, aber nicht interne Verwaltungsdaten zu sehen bekam. Dieser Schritt lief dann über die selten dämlichen Passwörter.
Es hilft der Realisierung, wenn man jedem Besucher der Site standardmäßig eine Session verpaßt.
Fraglich. Ob ich session_start() am Anfang der Loginseite stehen habe oder zwei Zeilen tiefer innerhalb des if, mit dem die Gültigkeit von Name/Passwort überprüft wurde, ist doch irrelevant.
Ob der Besucher als eingeloggt zu betrachten ist, muß in den Session-Daten drinstehen.
Steht beispielsweise ein Benutzername drin, ist er eingeloggt. Hat man keine weiteren Hierachien in der Zugangsberechtigung, reicht die bloße Prüfung, siehe oben. Gibt es weitere Hierachien, muss natürlich die für den Benutzernamen angegebene erst festgestellt werden, aber auch diese dürfte sich im Anschluss in den Sessiondaten halten lassen.
Ein $_SESSION["eingeloggt"] ist demnach überflüssig und, nur nebenbei, ganz und gar nicht sollte man das Passwort in der Session speichern.
-
-
-
-
Hallo liebe Forumer!
Ich möchte mich bei allen Autoren zu diesem Thread herzlich bedanken. Eure Beiträge haben mir viele Unsicherheiten bei der Verwendung von Sessions genommen.
Beste Grüße
Viennamade