Sitzungsregenerierung verursacht abgelaufene Sitzung mit schnellen AJAX-Aufrufen

Meine Anwendung ist eine vollständige AJAX-Webseite mit Codigniter Framework und Memcached-Session-Handler.Sitzungsregenerierung verursacht abgelaufene Sitzung mit schnellen AJAX-Aufrufen

Manchmal sendet es viele asynchrone Aufrufe, und wenn die Sitzung ihre ID neu generieren muss (um Sicherheitsprobleme bei der Sitzungsfixierung zu vermeiden), wird das Sitzungscookie nicht schnell genug erneuert und einige AJAX-Aufrufe schlagen fehl, da die Sitzungs-ID abgelaufen ist.

Hier ein schematisches Bild, das ich das Problem offenbar zu zeigen,: deaktivieren

Ich ging über die ähnlichen Themen (zB this one), aber die Antworten nicht wirklich mein Problem lösen, kann ich nicht die Sicherheit, da nur AJAX in meiner Anwendung anruft.

Trotzdem habe ich eine Idee und ich möchte eine Meinung vor dem Hacken in die Codeigniter Session Handler Klassen: Die Idee ist es, 2 gleichzeitige Session Ids für eine Weile zu verwalten, zum Beispiel 30 Sekunden. Dies wäre eine maximale Ausführungszeit für die Anfrage. Daher würde der Server nach der Sitzungsregeneration immer noch die vorherige Sitzungs-ID akzeptieren und zu der neuen Sitzungs-ID wechseln. Mit dem gleichen Bild, das so etwas wie diese geben würde:

Quelle

2016-07-14 Nicolas Thery

Welche Version von CI verwenden Sie? Dies scheint ein fortlaufender Fehler in der CI-Sitzungsbehandlung zu sein, insbesondere bei db-Sitzungen. Ich denke, die Unterstützung mehrerer Session-IDs kann als Hack funktionieren, aber es scheint, als würde es nach Ärger fragen. Können Sie einen anderen Session-Handler verwenden, vielleicht native PHP-Sessions mit Redis oder ähnlichem? Haben Sie sich auch [this thread] (https://github.com/bcit-ci/CodeIgniter/issues/3097) angesehen? – ldg

@Idg: Ich lese alle diese Threads ja. Es spricht über das Problem und CI3 (meine Version) löste es durch Deaktivieren der Sitzung Verlängerung mit AJAX-Anfragen. Das Problem ist, ich * habe nur * AJAX-Anfragen in meiner App .... –

@NicolasThery Können Sie einfach erklären, welche Art von Problem Sie haben –

Ihr Problem weniger mit der tatsächlichen Geschwindigkeit der Anfragen zu sein scheint (obwohl es ein Faktor ist), sondern mehr mit Gleichzeitigkeit. Wenn ich richtig verstehe, macht Ihre Javascript-Anwendung viele (asynchrone) Ajax-Aufrufe - schnell (vermutlich in Bursts) - und manchmal einige von ihnen scheitern aufgrund Session Ungültigmachung wegen Ihrer Geschwindigkeit ist der Anforderungen Problem. Nun, ich denke, dass das Problem ist, dass Sie mehrere gleichzeitige Anforderungen an den Server haben, während der erste seine Sitzung erneuert der andere im Wesentlichen nicht sehen kann, weil die Anfrage bereits erfolgt ist und wartet auf die Verarbeitung durch den Server.

Dieses Problem manifestiert sich natürlich nur, wenn mehrere Anfragen für denselben Benutzer gleichzeitig ausgeführt werden.

Jetzt Die eigentliche Frage hier - was in Ihrer Anwendung Business-Logik dies erfordert?

Es scheint mir, dass Sie versuchen, eine technische Lösung für ein "Business" -Problem zu finden. Was ich meine ist, dass entweder Sie Ihre Anforderungen missverstanden haben, oder die Anforderungen sind einfach nicht so gut gedacht/angegeben.

Ich würde raten Ihnen einige der folgenden versuchen:

sich fragen, ob diese mehrere gleichzeitige Anfragen an ein
kombiniert werden können, schauen tief in die Anforderungen und versuchen, die real zu finden Grund warum Sie tun, was Sie tun, vielleicht gibt es keinen wirklichen geschäftlichen Grund für diese
jedes Mal, bevor Sie die Reihe von Anfragen feuern eine 'refresh' AJAX-Anfrage, um die neue Sitzung zu bekommen, und nur auf su ccess mit allen anderen Anfragen

Ich hoffe, einige von dem, was ich geschrieben habe Hilfe, um Sie zur Lösung zu führen. Viel Glück

Quelle

2016-07-17 20:22:00

Angesichts der Menge von Menschen mit einem ähnlichen Problem, ich glaube nicht, "Änderung Ihrer Geschäftslogik" wird letztlich die Antwort sein. Ich stimme zu, dass es einige Verbesserungen der Geschäftslogik geben könnte, aber es scheint hier auch ein echtes technisches Problem mit CodeIgniter zu geben. Die Verwendung von Versprechensketten auf der FE könnte ebenfalls hilfreich sein und beide Seiten (Technik und Logik) treffen, aber wiederum wird das Problem nicht vollständig gelöst. – ldg

Hallo, ich versuche, zu versuchen, anders über Ihr Problem zu denken und zu denken. Aber ich schlug zwei technische Möglichkeiten vor, um es zu mildern.Die Umsetzung liegt natürlich bei Ihnen. Jedenfalls habe ich intuitiv immer noch das Gefühl, dass das Abfeuern vieler gleichzeitiger Ajax-Aufrufe für denselben Benutzer eine merkwürdige Sache ist und vermieden werden kann. Also ja, ich würde immer noch sagen, dass du wahrscheinlich das falsche Problem gelöst hast. Vielleicht könntest du den Anwendungsfall hier beschreiben, um einen Zusammenhang zu geben, und dann werde ich vielleicht sehen, dass ich falsch liege und dir besser helfen könnte? –

@VladLyga Zuerst: Vielen Dank für Ihre Antworten. Wie Idg sagte, kann das Problem während verschiedener Geschäftsfälle auftreten. Ich habe einen Burst-Anwendungsfall beschrieben, den ich * zu einer gruppierten Anfrage transformieren kann (es wird auch besser für Netzwerkdurchsatz, Leistung und Zuverlässigkeit sein). Aber das Problem kann in einem viel einfacheren (und nicht veränderbaren) Anwendungsfall auftreten: Nehmen wir an, ich habe einen Refresh-Zähler, der jede Minute ausgeführt wird. Wenn ich zur Zeit der Sitzungsregeneration gleichzeitig eine weitere asynchrone Anfrage durchführe, dann die erste Die Anfrage regeneriert die Sitzung und die zweite wird gekickt und das Authentifizierungs-Popup ausgelöst. –

Zunächst ist Ihre vorgeschlagene Lösung ziemlich vernünftig. In der Tat, the people at OSWAP beraten nur, dass:

Die Webanwendung kann eine zusätzliche Verlängerung Timeout implementieren, nach dem die Sitzungs-ID automatisch erneuert wird. (...) Der vorherige Sitzungs-ID-Wert wäre noch einige Zeit gültig, , um ein Sicherheitsintervall zu berücksichtigen, bevor der Client die neue ID kennt und mit der Verwendung beginnt. Wenn der Client zu der Zeit auf die neue ID innerhalb der aktuellen Sitzung wechselt, macht die Anwendung die vorherige ID ungültig.

Leider kann dies nicht mit PHP Standard-Session-Management implementiert werden (oder ich weiß nicht, wie das geht). Die Implementierung dieses Verhaltens in a custom session driver sollte jedoch kein ernsthaftes Problem darstellen.

Ich werde jetzt eine kühne Aussage machen: die Idee, die Sitzungs-ID regelmäßig zu regenerieren, ist gebrochen. Versteht mich jetzt nicht falsch, die Sitzungs-ID beim Anmelden (oder genauer gesagt as OSWAP put it, auf "privilege level change") neu zu generieren ist in der Tat eine sehr gute Verteidigung gegen session fixation.

Aber Session-IDs Regenerieren regelmäßig stellt mehr Probleme als sie löst: während des Intervalls, wenn die beiden Sitzungen koexistieren, müssen sie synchronisiert werden oder sonst läuft man Gefahr, Informationen aus der auslaufenden Sitzung zu verlieren.

Es gibt bessere (und einfachere) Abwehrmechanismen gegen einfachen Sitzungsdiebstahl: SSL (HTTPS) verwenden. Die periodische Sitzungserneuerung sollte für diesen Angriffsvektor als the poor man's workaround angesehen werden.

link to the standard PHP way

Quelle

2016-07-20 13:18:18 RandomSeed

Ich mag es wirklich, dass du antwortest, weil du nach OWASP-Anweisungen gesucht hast, was ein Sicherheitsbeweis ist, auf den ich mich wirklich verlasse. Allerdings ist HTTPS nicht genug, viele Unternehmen haben Verstöße in ihrer SSL-Entschlüsselung/Verschlüsselung, so dass interne Hacking weiß boxed. Eine starke Sicherheit ist eine Sicherheit mit vielen Barrieren. Momentan werde ich mich auf den MemoCached-Session-Garbage-Collector verlassen und die Funktion "Sitzungen bei der Verlängerung nicht zerstören" verwenden. Dies ist nicht optimal, aber immer noch besser als nichts. –

Ich bin mir nicht ganz sicher, gegen welches Bedrohungsmodell Sie sich verteidigen. Wenn Sie sich Sorgen über einen Angriff machen, der eine schlechte SSL-Implementierung ausnutzt, dann beheben Sie diese Priorität, da jede andere Verteidigung bedeutungslos wird, wenn diese kompromittiert wird. Wenn du dir Sorgen um einen Insider-Job machst, dann glaube ich, dass eine regelmäßige Regeneration der Sitzung nicht helfen wird. – RandomSeed

VIELE große Firmen haben eine anwendungsspezifische Firewall, die eine Art von Flüssen blockiert. Nehmen wir zum Beispiel VOIP. Dazu haben sie einen Front-Proxy, mit dem eine Anwendung einen SSL-Handshake erstellt, die SSL-Verbindung wird NICHT auf dem vollen Weg zum Benutzer hergestellt. (Ich bin diese Anwendung, und ich bin nicht in der Lage, alle meine Infrastruktur zu verwalten, ich bin eine Cloud-Service-Software) Danach liest dieser Proxy das Netzwerkpaket und macht seine Arbeit, alle Regeln zu erkennen. THEN startet einen neuen Handshake mit dem Mitarbeiterbenutzer, der ein internes Zertifikat verwendet: DIESES Zertifikat kann beschädigt sein. –

Sitzungsregenerierung verursacht abgelaufene Sitzung mit schnellen AJAX-Aufrufen

Antwort

Verwandte Themen