Das Problem, das ich habe, das möglicherweise nicht lösbar ist, ist wie folgt:
Ich habe einen Kunden, der eine große Organisation mit mehr als 1.500 Benutzern an 7 bis 8 verschiedenen Standorten ist. Die Anwendung ist eine PHP-Anwendung, die auf dem Kohana v3.0-Framework aufbaut. Die Organisation sitzt hinter einem Proxy-Filterserver auf ISP-Ebene. Jeder Standort verfügt über eine öffentliche Haupt-IP-Adresse, die über den Proxy und dann über das Web geleitet wird. Jeder Benutzer hat eine Mac- oder Windows-Workstation, die vom Arbeitgeber ausgestellt wurde.
Was sie erleben, scheinen Cookie-Kollisionen zu sein. Beispiel: Ein Benutzer meldet sich an seiner Arbeitsstation an, dann meldet sich ein anderer Benutzer von demselben Speicherort, einer anderen Arbeitsstation mit dem gleichen Betriebssystem und Browsertyp an. Der zweite Benutzer empfängt die aktive Sitzung des ersten Benutzers, indem er ein neu erzeugtes Cookie (Token) empfängt, das dem ersten Benutzer entspricht. Dies scheint nur mit dem "authautologin" -Cookie zu korrelieren (gesetzt, wenn das Kontrollkästchen "Remember me" auf dem Anmeldebildschirm aktiviert ist), aber ich halte meine Optionen für Caching vom Proxy offen (ich kann nicht beweisen, dass der Proxy ist Caching noch).
Aufgrund der Netzwerkkonfiguration sieht der Server Hunderte von Benutzern, die sich von derselben IP-Adresse mit demselben Benutzeragenten anmelden. Mein erster Gedanke ist, dass die Art und Weise, wie die Kohana v3 Cookies für den Browser (User Agent) erzeugt, für diese reale Anwendung nicht eindeutig genug ist.
Hat jemand schon mal so etwas erlebt? Und was wären die richtigen Maßnahmen für die Cookie- und Session-Generierung? Wäre das Verwalten von Cookies und aktiven Sitzungen in der Datenbank besser?
Kohana Module: Jelly-Auth, Jelly und Auth
Server: Apache / 2.2.9 (Debian) mod_fastcgi / 2.4.6 mod_jk / 1.2.26 PHP / 5.2.6-1 + lenny8 mit Suhosin-Patch mod_ssl / 2.2.9 OpenSSL / 0.9.8g
Bekannte Browser: IE 8 & amp; 9, Firefox (OS und Win) und Safari (OS)
Es ist nur eine Idee, aber es gibt (je nach Debian und PHP-Version) einen Fehler bei PHP-Sitzungen. Was ich Ihnen vorschlagen zu versuchen:
Wow das ist eine böse Verwundbarkeit, guter Fang!
Bei weitem der beste Weg, um Cookies unter PHP zu erstellen, ist es, PHP es tun zu lassen:
%Code%. Und das ist alles! Wenn Sie Ihren eigenen Cookie erzeugen, dann haben Sie wirklich irgendwo versagt. Jetzt können Sie das session_start() super global verwenden. Die beste Vorgehensweise besteht darin, $_SESSION[] in einer gemeinsamen Header-Datei aufzurufen, bevor Sie in Ihrer Anwendung auf $ _SESSION zugreifen.
Es gibt wahrscheinlich andere Probleme, die Sie in Betracht ziehen sollten, wie owasp a9 , csrf, und die Cookie-Flags: session_start() und das "secure" -Flag (Erzwingen des Cookies über https).
Ich bin mir nicht sicher, ob ich dich richtig verstanden habe, aber ... Ich verstehe, dass die Anfrage so lautet:
Benutzer (Arbeitsstation) == & gt; proxy () == & gt; Internet == & gt; Firmenwebsite (und Antwort in umgekehrter Richtung).
Überprüfen Sie, ob der Proxy "HTTP_X_FORWARDED_FOR" (in Superglobal-Variable $ _SERVER) setzt. Dies könnte die einzige Möglichkeit sein, die IP-Adresse des Benutzers zu ermitteln. Wenn ja, bist du fertig.
Tags und Links php security cookies kohana-3 kohana-auth