CSRF/HashTables

B

ByteSurfer

0
Guten Morgen,
in meinem aktuellen Projekt habe ich eine Seite mit 1 Formular. Um hier dem Session Hijacking Herr zu werden habe ich mir den CSRF-Schutz mit integriert.

Mein "Problem" ist, das wenn der jeweilige User jetzt neue Tabs/Fenster im Browser öffnet wird mein aktueller Wert in der Session mit dem neuen Hash überschrieben.

Welche Möglichkeiten gibt es um das Problem in den Griff zu bekommen.
Meine erste Idee war eine Hash-Tabelle in der Session, wo immer 10 gültige Hashes abgelegt werden und bei einem POST gegengeprüft werden können.

Aber wo soll man hier aufhören? Der normal User öffnet weniger 10 Tabs, doch prinzipiell hat er aber die Möglichkeit 0-* separat zu öffnen!


Gibt es hier von euch Lösungsansätze ?

greetz
 
Du könntest beim ersten Aufruf der Seite einen Cookie setzen mit einer Gültigen Session. Wenn der User ein Tab öffnet, kontrollierst du ob a) der Cookie gesetzt ist, b) ob er eine Gültige Session enthält c) ob die Gültige Session vor X-Sekunden den User übergeben wurden ist (IP, Browservergleich, Installierte Plugins abgleichen etc, um den eindeutig zu Identifizieren)

Wenn alles Stimmt diese Gültige Session auch für das neue Tab nutzen.

Ich hoffe das mein ansatz richtig ist...
 
So wird das normalerweise gemacht, ja... wenn du halt nen richtigen CSRF-Schutz haben willst, solltest du dir eine Art Formular-Manager basteln. Der kann dann für unterschiedliche Formulare Sessionabhängige CSRF-Tags basteln (Hash von (Formular-Identität + Session)), was die Sicherheit ein wenig erhöht...
 
würde es nicht reichen dem user beim login einen cookie zu geben, den er bei jedem post nochmals hidden-field mitsenden muss? läuft zwar auf js hinaus, aber ...

du vergleichst den cookie mit dem wert der zur session gehört, und dem was im post steht ... stimmen alle 3 überein, ist scheinbar alles ok...
 
Warum eine JS-Lösung präferieren, wenn es auch ohne geht? ;) Oben genanntes wird bspw. in einer ähnlichen Weise von Django praktiziert und hat den großen Vorteil, dass keine zusätzlichen Daten, außer der Session-ID, gespeichert werden müssen... und es auch ohne JS funktioniert...
 
@all
Danke fürs erste!

Ich werde mich am Weekend erst wieder an die Sache begeben und versuchen den Weg ohne JS zu gehen.

Nichts des so trotz habe ich für Ajax auch einen SecurityToken. Hier funktioniert aber alles ohne Einschränkung.

Allgemein:
JS in Verbindung mit CSRF-Schutz wäre nicht meine primäre Sicht der Dinge.
 
So hier bin ich wieder...

folgendes Szenario:
Folgende Seite präsentiert sich dem Nutzer.


  1. Ein Kontaktformular
    • mit hidden field (hash)
    • in der Session unter Csrf_Protection_Kontakt: 987j567d632gd66 ....
  2. Eine zusätzlich Permanent sichtbare Logineingabemaske (natürlich solange sich der nutzer noch nicht identifiziert hat)
    • mit hidden filed (hash)
    • in der Session unter Csrf_Protection_Login: hjf6ds543h8j90dclo ....
Vorab, alles ist für sich und in kombo voll funktionsfähig!

Zurück zur Eingangsfrage.

Wenn der Nutzer jetzt ein neuen Tab/Fenster öffnet werden beide bestehenden Einträge überschrieben, unabhängig ob ich zusätzlich Informationen via Plugins, Browser etc ... zum vergleichen habe.

Der Hash wir in diesem Fall für die erste Registerkarte nie einen gültigen Wert haben. Bei der Zweiten funktioniert alles wunderbar.
Bei einem Refresh des Ersten Tabs funktioniert alles umgekehrt entsprechend.

Das Verhalten ist ja auch total richtig, jedoch wie bekomme ich hier eine klare Unterscheidung und Zuordnung hin?

Mir hat sich das ganze irgendwie doch noch nicht so ganz erschlossen für meine Umsetzung!
 
ByteSurfer hat gesagt.:
Der Hash wir in diesem Fall für die erste Registerkarte nie einen gültigen Wert haben. Bei der Zweiten funktioniert alles wunderbar.
Bei einem Refresh des Ersten Tabs funktioniert alles umgekehrt entsprechend.
Zum Vergrößern anklicken....

Zum Vergleich brauchst du irgendwas Serverseitig da kann man die Aufrufzeit des ersten Öffnens speichern (irgendwo ablegen die Session) beim 2ten Öffnen wird ebenfalls eine Session abgespeichert mit der Zeit. Jetzt kannst du eindeutig Unterscheiden was zu erst geöffnet war bzw reloadet wurde!
 
Moin Chakky,
danke für die Antwort.

Das würde bedeuten, das ich für jeden Tab/Fenster einen separaten Zeitpunkt in micro mit plotte und zzgl. zu dem Hashelement in der Session mit abspeicher. Das würde aber auch bedeuten das ich hoch x hashes mit microzeiten speichern muss. Oder sehe ich das falsch, denn es liegt ja hier im Verhalten des Nutzers wieviel er separat auf macht ! Ob Sinn oder Unsinn !

Oder ?
 
Die kannst du doch dann alle Verwerfen nach X Sekunden, einmal am Tag oder wenn das Formular erfolgreich war.

Sehe ich jetzt nicht so als Problem und leistungshungrig. Die Session muss so oder so angelegt werden und ob dort noch ein timestamp mit drinne steht oder das Wetter in Sibieren ist ja eigtl egal....

Und wenn das Tab sich öffnet läd die Seite so oder so neu, also hast du in deinen Formular/Request eh ein Zeitstempel. Wenn das natürlich aus den Cache geladen wird, kannst du das nicht abfangen. Das ist natürlich nicht das Problem da eh die Session abgelaufen ist, wenn jmd das ausn Cache lädt/laden muss...
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben