Browsergame - Cheaten verhindern

[Peter@Pan]

Hi @ll,

ich bastel auch garde so zum Spass ein Browsergame - ist auch ne gute Übung um sich J2EE beizubringen.
Aktuell beschäftig mich die Frage wie ich Cheaten in dem Browsergame verhindern kann.
Da in der Regel User-Actionen über Formulare an den Server übertragen werden, könnte man cheaten wenn man weiß wie sich die Parameter-Liste der URL aufgebaut wird.

Um das zu verhindern dachte ich daran mir ein ActionTransport-Objekt zu schaffen in dem die Parameter gespreichert werden. Dieses Objekt wird dann in einer Session gespeichert und an eine ID gebunden. Nur diese ID soll dann per Get übertragen werden. Im Controller (Servlet) wird dann über die ID aus der Session das ActionTransport-Objekt geholt und verarbeitet.

Was haltet ihr von dem Ansatz?
Es gibt doch sicherlich schon Lösungen für dieses Problem. Kennt ihr welche?

Ich frage nur - weil ich Angst habe im mit meinem Ansatz vielleicht was viel zu Kompliziertes zu implementieren und es vielleicht viel bessere lösungen gibt. Man könnte z.B.: Die Get-Parameter synchron verschüsselt übertragen oder so....

Gruß,
Andreas

 

[EgonOlsen]

Um das zu verhindern dachte ich daran mir ein ActionTransport-Objekt zu schaffen in dem die Parameter gespreichert werden. Dieses Objekt wird dann in einer Session gespeichert und an eine ID gebunden. Nur diese ID soll dann per Get übertragen werden. Im Controller (Servlet) wird dann über die ID aus der Session das ActionTransport-Objekt geholt und verarbeitet.

Vielleicht stehe ich da auf dem Schlauch, aber das verstehe ich nicht. Du willst auf Serverseite ein Objekt in die Session hängen, in dem was jetzt genau steht? Wenn der User über ein Formular Eingaben tätigt, dann kann doch das Objekt vorher nicht wissen, was das sein wird? Also wie gesagt: So kapiere ich nicht, was du da vor hast.

 

[Evil-Devil]

Generell solltest du auf der Serverseite prüfen ob die vom User gewünschte Aktion überhaupt möglich ist und falls nicht, gib ihm eine Fehlermeldung. Das ist eigentlich das einfachste was man gegen Cheaten machen kann. Alles andere entsteht meist durch ausnutzen von Bugs im Browsergame.

Damit du nicht bei jeder Aktion eine SQL Abfrage starten muss um zu prüfen ob die Aktion möglich ist, würde ich die grundlegenden Werte (Geld, Produktion, etc) die einem Benutzer bei seinen Interaktionen zur Verfügung stehen in der Session speichern.

Hoffe das hilft dir ein wenig

Evil

 

[Peter@Pan]

Um das zu verhindern dachte ich daran mir ein ActionTransport-Objekt zu schaffen in dem die Parameter gespreichert werden. Dieses Objekt wird dann in einer Session gespeichert und an eine ID gebunden. Nur diese ID soll dann per Get übertragen werden. Im Controller (Servlet) wird dann über die ID aus der Session das ActionTransport-Objekt geholt und verarbeitet.

Vielleicht stehe ich da auf dem Schlauch, aber das verstehe ich nicht. Du willst auf Serverseite ein Objekt in die Session hängen, in dem was jetzt genau steht? Wenn der User über ein Formular Eingaben tätigt, dann kann doch das Objekt vorher nicht wissen, was das sein wird? Also wie gesagt: So kapiere ich nicht, was du da vor hast.

Ginge nur für Werte, die der Spieler nicht eingeben muss.

Zum Beispiel will ein Spieler Geld von einem Spieler zu dem anderen Übertragen. Die Geldmemge ist natürlich unbekannt und müsste über das Formular gesendet werden. Die Id vom Spieler, der das Geld erhalten soll könnte aber in dem ActionTransport-Objekt gespeichert werden und müsste nicht per Formular übertragen werden.

Generell solltest du auf der Serverseite prüfen ob die vom User gewünschte Aktion überhaupt möglich...

Beispiel oben: Spieler X überträgt Geld an Spieler Y.

Eine Action die Spieler X tun darf - aber er soll das Geld vielleicht nur an Spieler Y übertragen dürfen. Wenn die Identifkation des Geldempfänger-Spielers über eine im Formular übertragene ID geschieht - könnte man das manipulieren in dem man den id-Parameter in der URL ändert.


Kann ich vielleicht das Problem lösen wenn ich POST statt GET verwende?

 

[tfa]

Beispiel oben: Spieler X überträgt Geld an Spieler Y.

Eine Action die Spieler X tun darf - aber er soll das Geld vielleicht nur an Spieler Y übertragen dürfen. Wenn die Identifkation des Geldempfänger-Spielers über eine im Formular übertragene ID geschieht - könnte man das manipulieren in dem man den id-Parameter in der URL ändert.

Spieler X überträgt die ID von Spieler Y und den Geldbetrag an den Server. Der Server überprüft, ob Spieler X Spieler Y etwas überweisen darf und ob er überhaupt genug Geld hat. Wenn nein, sendet der Server eine Fehlermeldung und nichts passiert. Völlig egal, ob man da irgendwelche Parameter manipuliert hat.
Wie schon gesagt, muss die Überprüfung auf dem Server stattfinden.

 

[ARadauer]

Kann ich vielleicht das Problem lösen wenn ich POST statt GET verwende?

Damit kann dein Benutzer nicht über URL cheeten, natürlich kann er sich ein selber ein Formular oder ein Tool basteln, dass die Werte über POST überträgt.

wie tfa schon gesagt hat, kannst du ja serverseitig überprüfen ob das erlaubt ist, was er vor hat.

Also mir fallen jetzt keine Fälle ein, in denen der Benutzer ober POSt oder GET cheaten könnte, die du serverseitig niciht abfangen kannst.

 

[Peter@Pan]

Kann ich vielleicht das Problem lösen wenn ich POST statt GET verwende?

Damit kann dein Benutzer nicht über URL cheeten, natürlich kann er sich ein selber ein Formular oder ein Tool basteln, dass die Werte über POST überträgt.

wie tfa schon gesagt hat, kannst du ja serverseitig überprüfen ob das erlaubt ist, was er vor hat.

Also mir fallen jetzt keine Fälle ein, in denen der Benutzer ober POSt oder GET cheaten könnte, die du serverseitig niciht abfangen kannst.

Ok - stimmt man kann alles kontrollieren. Nur dachte ich an ein Konzept bei dem ich keinen großen Kontrolllogiken brauche, sondern halt schon im Vorfeld ein Cheaten verhindere.

 

[sliwalker]

Hoi,

stell Dir folgendes vor:
Es gibt...

Spieler A
Spieler B
BöserBube

Aktion: Geld überweisen
(So nicht) Wäre ich ein BöserBube, würde ich versuchen, mir selbst Geld zu überweisen, indem ich die zu sendenden daten so manipuliere , dass ich Gewinne.

ALSO -->

(So sollte es sein) A füllt ein Formular aus, trägt 1000 Gold ein, wählt einen Spieler B aus einem Dropdown und klickt auf senden.
Methode ist gängiger- und sinnvollerweise POST.

Der SERVER erhält den Request, nimmt sich den egrade angemeldeten Spieler und überträgt von ihm das Geld zum Ziel., sofern er genug hat und das Ziel nicht die Quelle ist. Es darf keine Möglichkeit geben, die Quelle zu manipulieren. Das darf nur im Server geschehen.

Cheatschutz ist also "nur" eine gute Plaung und sicheres Programmmieren. Die wichtigen Sachen muss der Server regeln. Das sind zum einen die kritischen Daten Stellen(Quelle) zum anderen die abschließende Überprüfung auf Richtigkeit der Daten.
So darf man zB nicht auf der "Gebäude-Seite" ein Formular zum Upgraden eines Gebäudes generieren und sich einzig dadurch darauf verlassen, dass der User ja nur das zur Vefügung gestellt bekommt, was er auch darf. (Nach dem Motto: Er darf gerade nichts bauen, also erstelle ich das Formular so das er nicht darf und damit bin ich safe).
Na klar muss man das Formular richtig erstellen, aber die Prüfung ob jemand etwas darf erfolgt im Server, bevor etwas ausgeführt wird. Sonst nimmt BöserBube mal ein Formular wo er bauen darf, ändert das GebäudeLevel auf 99 und sendet es.

Einfach nachdenken und versuchen ein BöserBube zu sein.
Tester sind übrigens GoldWert.


greetz
SLi

 

[ice-breaker]

Ok - stimmt man kann alles kontrollieren. Nur dachte ich an ein Konzept bei dem ich keinen großen Kontrolllogiken brauche, sondern halt schon im Vorfeld ein Cheaten verhindere.

das ist ja das anstrengende an Web-Anwendungen, man muss wirklich ALLES prüfen.
Da hast du dann vllt schonmal 20 Prüfungsbedingungen (unbedingt ein gutes Framework nutzen) für ein klitzekleines Formular.
Aber sobald du JEGLICHE Benutzereingaben validierst, kann man nicht mehr cheaten

 

[EgonOlsen]

Der SERVER erhält den Request, nimmt sich den egrade angemeldeten Spieler und überträgt von ihm das Geld zum Ziel., sofern er genug hat und das Ziel nicht die Quelle ist. Es darf keine Möglichkeit geben, die Quelle zu manipulieren. Das darf nur im Server geschehen.

Und sofern der übertragene Betrag nicht negativ ist... :lol:

 

[Peter@Pan]

Vielen Dank für eure Antworten . Werde nun alle Benutzereingaben validieren - macht zwar nicht soviel Spass aber wenns nicht anders geht....

 

[AlexWerz]

Ich habe diesen Thre3ad nur kurz überflogen, aber wenn dein Problem ist, dass die Spieler die URL ändern und dadurch cheaten, dann benutz doch statt GET einfach POST.

Du hast also ein Formular in der Eingaben gemacht werden können. Als Action hast du GET eingetragen. Dadurch werden die Parameter in die URL kodiert und könnten geändert werden. Benutzt du stattdessen POST werden die Daten nicht in die URL kodiert, du kannst sie aber dennoch abfragen (jedoch dann im doPost und nicht im doGet).

Soweit ich weiß gibt es keine Möglichkeit die Parameter in einem Post zu ändern.

Gruß
Alex

 

[tfa]

Ich habe diesen Thre3ad nur kurz überflogen,

Du hättest doch genauer lesen sollen. GET oder POST ist völlig egal. Die Daten werden vom Client gesendet.
Ein potenzieller Angreifer hat völlige Kontrolle über den Client, kann also bestimmen, was gesendet wird. Die Überprüfung der Daten muss auf jeden Fall auf dem Server erfolgen. Alles andere ist unsicher.