http://www.codinghorror.com/blog/archives/001171.html
Möchte ich nur nochmals ins Gedächtnis rufen, da ich behaupte, dass 90% aller Browsergames gegenüber dieser Angriffsvariante ungeschützt sind (unter anderem meines).
Sicherheit kommt von Innen und kann nur schwer nachträglich aufgeprägt werden, wie die Schönheit. Jede natürliche Schönheit ist besser als eine operierte Schönheit!
Hieß das früher nicht mal Session Riding?
Auch da hat man wieder den Vorteil wenn man ein Framework wie zum Beispiel Django nutzt. Denn dort gibt's eine CSRF-Middleware die, einmal aktiviert, in jedes Formular geheimen Token einfügt und nach dem absenden abgleicht. Und das alles vollkommen transparent für den Entwickler. Der macht (abgesehen von dem aktivieren) alles wie bisher.
Hilft natürlich auch nur bei POST-Requests.
Naja, kritisches Thema, ich finde allerdings seine Loesungsvorschlaege ziemlich unpraktikabel und wuerde eher das Verlinken von Grafiken ganz unterbinden.
Referrer Check scheidet aus, weil es User gibt, die den bewusst blocken und auch sonst recht feheranfaellig ist.
Secret Hidden Form Value macht einem tabbed browsing kaputt... ist im Zweifel aber immerhin einen Blick wert. Vielleicht mit einer Form von zeitlich limitiert gueltigem Schluessel / Encryption (mit privatem Schluessel und userbezogen) und nicht per Session?
Double Cookies sind nett, sofern man JS mandatory macht (durchaus eine Moeglichkeit und nicht abwertend gemeint, aber es gibt Leute, die ihre Seite abwaertskompatibel halten moechten und fuer die sollte es auch eine Loesubg geben.
Ich persoenlich wuerde wohl eher darauf setzen User Input moeglichst vollstaendig zu filtern. Sollte ich nicht daran vorbeikommen, wuerde ich wohl encrypted form values/get params nutzen.
Original von Kallisti
Naja, kritisches Thema, ich finde allerdings seine Loesungsvorschlaege ziemlich unpraktikabel und wuerde eher das Verlinken von Grafiken ganz unterbinden.
Erklär mir mal wie du auf einer beliebigen, nicht von dir kontrollierten Seite das einbinden von Grafiken die auf dein Spiel verweisen unterbinden willst?
Vielleicht mit einer Form von zeitlich limitiert gueltigem Schluessel / Encryption (mit privatem Schluessel und userbezogen) und nicht per Session?
Django verwendet pro Formular einen eindeutigen Schlüssel. Also ist ein Schlüssel einmalig und nicht auf die ganze Session ausgedehnt.
Ich persoenlich wuerde wohl eher darauf setzen User Input moeglichst vollstaendig zu filtern. Sollte ich nicht daran vorbeikommen, wuerde ich wohl encrypted form values/get params nutzen.
Was willst du denn da filtern? Wenn du ohne Refererauswertung arbeiten willst kannst du ja noch nicht mal filtern wo die Daten herkommen. Und das dir (bzw. deinen Nutzern) jemand gültige Eingaben unterschiebt ist ja wohl nicht sonderlich schwierig.
Ich glaube du hast die Problematik noch nicht ganz verstanden.
Original von Dunedan
Original von Kallisti
Naja, kritisches Thema, ich finde allerdings seine Loesungsvorschlaege ziemlich unpraktikabel und wuerde eher das Verlinken von Grafiken ganz unterbinden.
Erklär mir mal wie du auf einer beliebigen, nicht von dir kontrollierten Seite das einbinden von Grafiken die auf dein Spiel verweisen unterbinden willst?
Stimmt, ich hatte es zunaechst darauf bezogen, dass der Angriff auf _meinen_ Seiten initiiert wird (bzw. im Forum durch das Posten von Grafiklinks). Es ist etwas anderes ob so etwas von den offiziellen Seiten des Spiels ausgeht, oder ob es Fremdseiten sind, wenngleich natuerlich auch dort ein Risiko entsteht, ueber das man diskutieren darf. Dennoch ist es imho erst einmal wichtiger, dass das eigene Angebot vollstaendig sicher ist, da bei Fremdseiten sowieso eine Fuelle weiterer Probleme existieren (Browserluecken, siehe Firefox 3.0.2 Release gerade, WoW-User werden dir mit .cn und .ru Links ein Lied davon singen koennen).
Vielleicht mit einer Form von zeitlich limitiert gueltigem Schluessel / Encryption (mit privatem Schluessel und userbezogen) und nicht per Session?
Django verwendet pro Formular einen eindeutigen Schlüssel. Also ist ein Schlüssel einmalig und nicht auf die ganze Session ausgedehnt.
Und wie soll das technisch funktionieren? Natuerlich ist der Schluessel eindeutig, aber genau das ist doch das Problem. Speicherst du jeden einzelnen Schluessel in der Session ab? Wenn der User viel herumklickt, aber wenige Formulare letztlich abschickt, kommen da schnell einige hundert Schluessel zusammen, da du ja auch keine Timeouts < 20-30 Minuten willst (ich erinnere mal an Galaxy-news hier frueher, als man nach 15 Minuten jedes mal die "ungueltiger-Link" Nachricht bekam).
Genau das ist doch die Problematik, die meisten speichern Sessionweit EINEN Key und jedes Formular ueberschreibt den vorherigen, womit Tabbed Browsing kaputt ist.
Einzige Loesung waere eben Verschluesselung, wie von mir beschrieben, aber das ist etwas anderes/mehr als ein "eindeutiger Schluessel". Man muss den Key serverseitig reproduzieren koennen, ohne ihn zwischenspeichern zu muessen.
Ich persoenlich wuerde wohl eher darauf setzen User Input moeglichst vollstaendig zu filtern. Sollte ich nicht daran vorbeikommen, wuerde ich wohl encrypted form values/get params nutzen.
Was willst du denn da filtern? Wenn du ohne Refererauswertung arbeiten willst kannst du ja noch nicht mal filtern wo die Daten herkommen. Und das dir (bzw. deinen Nutzern) jemand gültige Eingaben unterschiebt ist ja wohl nicht sonderlich schwierig.
Ich glaube du hast die Problematik noch nicht ganz verstanden.
Wie oben beschrieben und ich kann eben sehr wohl filtern, was auf MEINEN Seiten passiert. Jegliche externe Webseite ist sowieso per se ein Sicherheitsrisiko. Das ist keine Entscheidung sich darauf auszuruhen, aber eben Realitaet. Wer heutzutage meint unbeschwert auf jeden Link klicken zu koennen, bekommt desoefteren "aufs Maul" (gerade bei einem Bekannten geschehen - eigentlich IT technisch fit, Opera-only User, neueste Version, keinerlei executable Downloads, Router, Firewall aktiv, alle Betriebssystempatches drin, sicheres Passwort, nie weitergegeben -> WoW-Account futsch, mit seinem Account in allen WoW Foren weitere China Links gespammt...).
Insofern habe ich also durchaus, wohlbemerkt nur als ersten, aber dennoch wichtigsten, Schritt eine Moeglichkeit den Content auf meiner Plattform zu filtern.
Ich kenne das von einem anderen CMS: Pro Sitzung (Client, nicht unbedingt eingeloggt) werden (derzeit) bis zu 20 Schlüssel gültig gespeichert, die als Hidden Tokens für Formulare eingesetzt werden können. Das verhindert sowohl das Problem unrechtmäßiger Spams als auch das typische Problem "Seite wird 2x abgeschickt" wenn der User erste Anzeichen von Klickeritis im Zeigefinger hat.
Interessante Thematik, davon hör ich tatsächlich das erste Mal. Kann mir jemand erklären, wie Double submitted cookies funktionieren? Aus der Beschreibung werd ich nicht so recht schlau. Ein Link zu dem Thema wär auch schön. Beim googeln find ich dazu vor allem Backrezepte ^_^
Original von Kallisti
Vielleicht mit einer Form von zeitlich limitiert gueltigem Schluessel / Encryption (mit privatem Schluessel und userbezogen) und nicht per Session?
Django verwendet pro Formular einen eindeutigen Schlüssel. Also ist ein Schlüssel einmalig und nicht auf die ganze Session ausgedehnt.
Und wie soll das technisch funktionieren? Natuerlich ist der Schluessel eindeutig, aber genau das ist doch das Problem. Speicherst du jeden einzelnen Schluessel in der Session ab? Wenn der User viel herumklickt, aber wenige Formulare letztlich abschickt, kommen da schnell einige hundert Schluessel zusammen, da du ja auch keine Timeouts < 20-30 Minuten willst (ich erinnere mal an Galaxy-news hier frueher, als man nach 15 Minuten jedes mal die "ungueltiger-Link" Nachricht bekam).
Genau das ist doch die Problematik, die meisten speichern Sessionweit EINEN Key und jedes Formular ueberschreibt den vorherigen, womit Tabbed Browsing kaputt ist.
Wozu braucht man denn mehrere Keys? Einfach die Session-ID als GET und/oder als POST-Parameter jeder Seite übergeben. Dann überprüfen, ob der wert in GET/POST mit dem im COOKIE übereinstimmt, wenn ja ist alles gut, sonst eben nicht. Oder einfach ganz auf Cookies verzichten.
Hehe, das ist noch besser wenn du nach "hashed cookies" googlest. :P
Das mit den Cookies soll afaik so funktionieren, dass du im Cookie einen Wert stehen hast, den du per Javascript ins Formular schreibst (welches ja nur Cookies der lokalen Domain auslesen kann). Dann musst du nur noch abgleichen ob der get/post Wert dem Wert im Cookie entspricht.
Der Wert kann pro Session statisch sein, kann z.B. auch _theoretisch_ einfach die Session ID sein.
Double submitted also in dem Sinne, dass du den Wert sowohl im Cookie, als auch per get/post überträgst. Aus Sicherheitsgründen solltest du den Wert dann nachdem du ihn einmal benutzt hast wechseln, aber theoretisch kann man ihn auch für eine Session konstant lassen, sofern diese zeitlich begrenzt ist.
Wenn man den Wert jedoch ändert, macht man ältere Tabs kaputt, die vor absenden des aktuellen Formulars geöffnet wurden... - ausser das Javascript schreibt es erst beim submit, dann müsste es klappen.
Edit, da xou im selben Moment gepostet hat: Session ID deshalb theoretisch und nicht empfehlenswert, weil Bookmarking dir dadurch kaputt geht und weil das Risiko besteht, dass die User die Links unwissentlich posten.
Man könnte dann mit hashed cookies wiederum Identitätsdiebstahl abfangen, aber sauber ist das nicht. - Und es erzwingt die Nutzung von Cookies, die ansonsten optional wären, wenn der User es explizit nicht möchte.
Das Thema ist nicht so einfach, wie man es gern hätte. ;)
Wenn die Sessionid im GET steht kriegst du ein Problem wenn es möglich ist externe Bilder im Spiel zu linken (bsp. eigene Skins, Bilder in Allianzbeschreibungen) da dann die Sessionid im Referer steht.
Also nicht SessionID, sondern eine zweite ID, die für die gleiche Session gilt und nur für die "Herkunft-Validierung" hergenommen wird. Behebt zwar die anderen Probleme der wechselnden IDs bei Links usw. nicht, aber zumindest hat man dann kein Problem mit geklauten SessionIDs, egal was der User mit den Links anstellt.
Wenn sich die Id aber nicht ändern kann man sie im ersten Schritt über den Referer klauen und im zweiten Schritt für CSRF verwenden. Macht die Sache zwar schwieriger aber nicht ausgeschlossen.
Original von Kallisti
Edit, da xou im selben Moment gepostet hat: Session ID deshalb theoretisch und nicht empfehlenswert, weil Bookmarking dir dadurch kaputt geht und weil das Risiko besteht, dass die User die Links unwissentlich posten.
Ich hab noch nie eine Browsergame-Seite gebookmarked... Wenn du bookmarkbare Seiten haben willst hast du doch das CSRF-Problem, dann kannst du ja auch keine Aufruf-Schutzmethoden machen, sonst würde es der Benutzer ja das Bookmark nicht mehr verwenden können.
Was aber gehen sollte wäre doch ein hash der Session ID im GET? Da kann dann keiner über den Referrer an die Session ID und man kann die Gültigkeit der Anfrage schnell überprüfen.
Original von Kallisti
Und wie soll das technisch funktionieren? Natuerlich ist der Schluessel eindeutig, aber genau das ist doch das Problem. Speicherst du jeden einzelnen Schluessel in der Session ab? Wenn der User viel herumklickt, aber wenige Formulare letztlich abschickt, kommen da schnell einige hundert Schluessel zusammen, da du ja auch keine Timeouts < 20-30 Minuten willst (ich erinnere mal an Galaxy-news hier frueher, als man nach 15 Minuten jedes mal die "ungueltiger-Link" Nachricht bekam).
Ich mach da gar nichts. Das macht alles Django für mich. Wie das technisch genau läuft ist mir im Endeffekt auch egal. Und selbst wenn pro Nutzer durchschnittlich 100 Keys rumfliegen: Schadet doch nicht.
Original von xou
Was aber gehen sollte wäre doch ein hash der Session ID im GET? Da kann dann keiner über den Referrer an die Session ID und man kann die Gültigkeit der Anfrage schnell überprüfen.
Wenn du den Hash übergibst, musst du auch den Hash überprüfen. Und wenn das der Fall ist, reicht der Hash aus, um wiederum alle Systeme zu umgehen.
Original von Dunedan
Original von Kallisti
Und wie soll das technisch funktionieren? Natuerlich ist der Schluessel eindeutig, aber genau das ist doch das Problem. Speicherst du jeden einzelnen Schluessel in der Session ab? Wenn der User viel herumklickt, aber wenige Formulare letztlich abschickt, kommen da schnell einige hundert Schluessel zusammen, da du ja auch keine Timeouts < 20-30 Minuten willst (ich erinnere mal an Galaxy-news hier frueher, als man nach 15 Minuten jedes mal die "ungueltiger-Link" Nachricht bekam).
Ich mach da gar nichts. Das macht alles Django für mich. Wie das technisch genau läuft ist mir im Endeffekt auch egal. Und selbst wenn pro Nutzer durchschnittlich 100 Keys rumfliegen: Schadet doch nicht.
Bezogen auf mein Beispiel: Es gibt 20 gültige Keys.. das heißt man würde mit "ungültig!" erschlagen, wenn man sich a) währenddessen aus- und wieder eingeloggt hat oder 20 andere Formulare aufgerufen hat (nicht abgeschickt). Dabei ist 20 natürlich ein theoretisch freiwählbarer Wert, aber man sollte sich im Klaren sein, dass diese Daten alle in der Session stehen - oder aber man eine zusätzlich gepflegte "Token-API" hat, die dies bsp. in einer (riesigen?) Datenbank(tabelle) speichert.
Und natürlich(!) macht es durchaus Sinn, nicht alle Formulare abzusichern. Es gibt manchmal Situation, wo es nicht notwendig ist. Dann bitte auch nicht mit Kanonen schießen, die Spatzenpopulation dankt.
Ich persönlich habe mir hier die Beschreibung mit den Tokens aufbearbeitet und mit einem zusätzlichem Url-Schutz versehen.
Herausgekommen ist dann ein doppelter Schutz, von dem ich behaupte, dass er bei korrekter Implementierung CRSF verhindert:
http://blog.depon.net/index.php?/archives/504-Doppelt-haelt-besser.html
Im Prinzip die beiden hier genannten Verfahren kombiniert.
D.h. du verzichtest darauf die User bookmarken zu lassen? (das machen mehr als man meint) Bzw. alte Tabs nach einem re-login verfallen und müssen neu geöffnet werden? (das machen wahrscheinlich noch mehr ^^)
Wie viele Tokens speicherst Du?
> du verzichtest darauf die User bookmarken zu lassen?
Reine Inhaltsseiten werde ich von der CSRF-URL-Prüfung ausnehmen.
Ich überlege mir auch, dass URLs mit ungültiger URL so umgeleitet werden, dass nur sämtliche GET und PSOT-Parameter verworfen werden.
> Bzw. alte Tabs nach einem re-login verfallen und müssen neu geöffnet werden?
Die Session wird bei einem Relogin nicht verworfen. Nur die User-Credentials, diese sind aber unabhängig von den CSRF-Schutzmaßnahmen.
> Wie viele Tokens speicherst Du?
Momentan 20. Ich werde mir aber eine Protokollierung einbauen wie oft ein überflüssiges CSRF-Token entfernt worden ist und der Nutzer deswegen eine Fehlermeldung erhalten hat.
Ich denke, dass ein Wert von etwa 50 ausreichend ist, aber dazu brauche ich erst Erfahrungswerte ;-)
Hm, nagut. Statt deinem Token mitten in der URL könnte man auch einfach ein "normales" Token an die URL packen. Oder ist es das eh? URL-Rewriting ist ne ganz andere Geschichte, damit sieht das natürlich hübscher aus (vgl. Standard SessionId-Rewrite).
Du willst nur "bestimmte Seiten" mit dem zusätzlichen Token (CSRF) ausstatten? Welche denn.. sowas wie Private Daten (Namen) ändern? Den Ansatz, in diesem Falle einfach nochmal das Passwort (Google) einzugeben, finde ich da viel einfacher und vom User sogar verständlich (ah, "wichtig", muss nochmal Passwort eingeben).
Dann halt uns doch bitte auf dem Laufenden, was sich so bzgl. der Menge an Tokens ergibt.
Und wieso hängst Du nicht einfach die "url" als get Parameter an? Dann wäre die Bookmarkgeschichte etwas "hübscher", als mit dem rewrite. Aber das ist natürlich Geschmackssache.
Die Idee "ausgelaufene" Urls auf neue umzuleiten aber alle Params zu droppen finde ich ganz gut, das fixt dann sowohl die meisten bookmarks, als auch die Sache mit den "alten Tabs". Was ich meinte war, dass in den Tabs ja auch die falsche Url aufkäme und es daher mit einer neuen Session nicht mehr funktioniert, aber wenn Du weiterleitest, ist es kein Ding.
Eigentlich musst Du nichtmal alle Params droppen, sondern nur "set" Parameter. Alles was nur "Read-Access" betrifft kann weiterhin akzeptiert werden.
Original von TheUndeadable
Momentan 20. Ich werde mir aber eine Protokollierung einbauen wie oft ein überflüssiges CSRF-Token entfernt worden ist und der Nutzer deswegen eine Fehlermeldung erhalten hat.
Ich denke, dass ein Wert von etwa 50 ausreichend ist, aber dazu brauche ich erst Erfahrungswerte ;-)
Entweder sehe ich nun den falschen Ansatz oder 20 ist mehr als ausreichend. Es geht ja nur darum mehrere Tokens zu speichern, weil manche Leute mehrere Tabs öffnen, wenn sie im Spiel unterwegs sind.
Ich Kann mir einfach nicht vorstellen, dass man mehr als 20 Tabs gleichzeitig offen hat, die sich nur auf das eine Spiel beziehen. Vorrausgesetzt, dass diese 20 Tabs auch noch Seiten beinhalten, die eine Form beherbergen. Ich denke 10 würden auch schon ausreichen.
Theoretisch könnte man das auch so aufziehen, dass man einen Token fürs erfolgreiche Senden eines Formulars erstellt, und ein Löschtoken für diesen hat, der dann einfach an die Links gehangen wird oder per Javascript immer übergeben wird. Kommt aber sicher drauf an, wie man die ganze Seite im Frontendbereich gestaltet hat. Also ob da stinknormales HTML geschrieben wurde, oder eine Template-Engine alles umsetzt.
In Java ja auch leicht durch spezielle neue Tags lösbar, welche man super ableiten kann und somit an die Situation anpassen kann, wenn man Lust drauf hat.
Würde nebenbei auch verhindern, dass man sich durch gewisse 3rd Party-Tools durchs Spiel bewegt (also ich mein nun keine, die die Links für einen Klicken oder der "Affenmist" ;) )
> Und wieso hängst Du nicht einfach die "url" als get Parameter an?
Damit ich in einer Vorlage einfach '' schreiben kann und ich nicht erst den Parameter anhängen muss. Da der CSRF-Bezeichner für den Browser als Unterverzeichnis wirkt, entstehen hier keinerlei Probleme.
> Eigentlich musst Du nichtmal alle Params droppen, sondern nur "set" Parameter.
In der Tat... Aber die Faulheit des Programmierers ;-) Natürlich kann man hier differenzieren, ich denke, dass ich es auch implementieren werde, aber ich wollte mich halt nicht auf die korrekten Angaben eines Spielezusammenstellers verlassen. Passive Sicherheit auch ohne Zutun des Anwenders steht für mich im Vordergrund.
> URL-Rewriting ist ne ganz andere Geschichte
Ich nutze sowieso einen eigenen Webserver. Für das Dispatching kann ich diesen Teil einfach ignorieren.
> Du willst nur "bestimmte Seiten" mit dem zusätzlichen Token (CSRF) ausstatten?
Theoretisch könnte man alle Seiten, die nur nichtgeschützte Inhalte anzeigen ohne Token aufrufen lassen. Aber auch hier muss der Ersteller der Seiten aktiv werden.
> In Java ja auch leicht durch spezielle neue Tags lösbar
In meinem Framework gibt es die Ersetzung '@[=CSRFTokenField]' , oder so ähnlich. Dort wird dann vom Webserver das Hiddenfield eingepflegt.
http://rafb.net/p/Ypibkj83.html
> Ich Kann mir einfach nicht vorstellen, dass man mehr als 20 Tabs gleichzeitig offen hat
Problem ist auch, wenn der Nutzer einfach mal 20 Formularfelder im zweiten Tab besucht [nicht abschickt], jedesmal ein neues Token erzeugt und dann später im ersten Tab das uralte Formularfeld abschickt. Aber darauf zielt dein Löschtoken ab, wenn ich es richtig verstanden hatte.
> Den Ansatz, in diesem Falle einfach nochmal das Passwort (Google) einzugeben
Ich möchte in der Administrationsoberfläche nicht für jede Aktion nochmals das Kennwort eingeben ;-)
Nein, das ist ein zusätzliches Level, was eine geringe Laufzeit hat (vgl. erweiterte Rechte bei modernen Betriebssystem oder automatischen Lockin/Lockout beim Apple'schen Schlüsselbund).
Aber Tokens sollten eigentlich ausreichen; sind alle schreibenden Operationen mit einem POST-Formular mit Validierung "gesichert", ist eigentlich dein zusätzlicher Mechanismus überflüssig. Denn der Angreifer kann zwar mahen was er will.. aber den Token wird er nicht herausfinden.
Original von TheUndeadable
Aber darauf zielt dein Löschtoken ab, wenn ich es richtig verstanden hatte.
Ja sollte es. Also zu jedem eigentlichen CSRF-Token, den du als hidden-Field in der Session speicherst, gibts dann noch x-beliebige Löschtokens und am besten nochn Zeitfaktor, was ja bei dir schon eingebaut sein wird.
So würde ich den letzten Löschtoken speichern, mit dem ich auf die Seite gekommen bin, und einen neuen, der an alle weiteren Links übergeben wird (per Javascript, eigenem Templatedesign oder what ever). So garantierst du, dass auch beim aktualisieren der Seite nur ein Token für deine Seite verwendet wird, weil der Alte gleich wieder gelöscht wird.
So brauch man nicht 20 CSRF-Tokens, die dann offen bleiben, sondern eigentlich wird der Ungenutzte immer wieder gelöscht und wenn nicht, dann kommt der Zeitfaktor zum Tragen. Ich weiß ja nicht, wie du das gehandhabt hast, wenn man 100mal (übertrieben ich weiß) die F5-Taste drückt. Dann wird sozusagen das Token im anderen Tab ungültig, weil der vergebene Token durch die Aktualisierungen vernichtet wurde?
Anmerkung: Wenn auf die letzte Frage ein "ja" kommt, folgender Gegenvorschlag: Formular-identifizierende Dialoge, d.h. verschiedene Forms werden auch getrennt genutzt (jeweils mit ablaufenden Token).
Eine andere Idee:
Wenn man ein Token benutzt, aus dem man zurückrechnen kann, wann das Token erstellt wurde?! Ein wenig Zufalls"müll" wird bei der Erstellung mitbenutzt.
Das würde zwar keinen 100% Schutz bieten, aber sollte für die Sicherheit eines Browsergames ausreichen...außerdem ist ein Unterschied zum "Ich speichere den Token und lasse ihn dann irgendwann verfallen" nicht wirklich feststellbar (für einen pot. Angreifer).
Die Vorteile liegen auch auf der Hand: Kaum Implementierungszeit, kein Speichern nötig, ...
Das Problem mit dem Bookmarken wird wieder über den bereits vorgeschlagenen Tip des Droppens der Parameter umgangen.
Ein Vorteil der "komplizierten" Methode ist ja auch, dass Formulare nicht mehr ausversehen mehrfach abgeschickt werden können. Das ginge hier dann ja schon nicht mehr. Aber wenn man es rein aus sicherheitstechnischer Sicht betrachtet ... ist das eine deutlich simplere Variante mit wahrscheinlich ausreichendem Sicherheitsgrad.
/edit: Nochmal nachgedacht: Die Methode ist Unfug! Der Angreifer holt sich einfach alle paar Minuten ein Token aus dem Spiel (sind ja leicht einsehbar) und fügt das in sein Angriffsscript ein.
Das Token muss natürlich die jeweilige Session ID als Salt im Hash haben.
Original von Fobby
/edit: Nochmal nachgedacht: Die Methode ist Unfug! Der Angreifer holt sich einfach alle paar Minuten ein Token aus dem Spiel (sind ja leicht einsehbar) und fügt das in sein Angriffsscript ein.
Es gibt sicherlich keine spielweiten Tokens, sondern für jeden Spieler spezifisch. Also kann der Angreifer nicht seine Tokens benutzen, weil die an seine Session gekoppelt sind. Das bringt ihn nicht wirklich weiter