Eine Anwendung so gut wie möglich beschützen

Bitte aktiviere JavaScript!
Guten Tag,

nehmen wir an, man schreibe eine Anwendung (z.B. ein Spiel) und speichert die Daten auf einer externen Datenbank. Nun möchte man, wenn man das Spiel verloren hat, eine Top 10 Liste ausgeben lassen, die in der Datenbank drin steht, welche mit Passwort gesichert ist. Nun meine Frage, wie setzt man das am besten und am sichersten um?

Meine Ideen:
Man sollte auf keinen Fall das Passwort in der Anwendung stehen haben. Deswegen bevorzuge ich einen Server, welcher für eine Verifikation sorgt, dass man dann die Daten bekommt. Der Server greift dann auf die Datenbank zu.
Aber.. wie führe ich die Verifikation durch?
Ich dachte anfangs, die Hash Daten der Application zu nehmen und dies als Verifikation zu benutzen, aber dann sind wir beim üblichen Java Problem:
Da man Anwendungen einfach decompilen kann, kann man dies umgehen und trotzdem die Daten bekommen.
Führt man eine Obfuscation aus, dann benutzt man Reverse Engineering und kann jederzeit trotzdem auf den Inhalt des Servers zugreifen.

Es ist halb so schlimm, wenn man die Daten, die man eh sehen soll, sieht..
Aber: Wenn man in der Anwendung z.B. Punkte sammelt, dann schickt man die Punkte (Req -> Client zu Server) an den Server, damit er dies in die Datenbank reintut.
Wie umgehe ich das? Reverse Engineering ist eine schwere Sache. Ich weiß, dass man nicht 100% sich schützen kann, aber was wäre die beste Möglichkeit dagegen vorzugehen?

Ich meine.. in Handy Spielen kann man sich das auch nicht zwingend manipulieren, welche Online gehen, egal wie oft man versucht. Sollte man wirklich auf eine gute Obfuscation, ByteCode Manipulator verlassen?

Selbst wenn man eine Mischung aus Hash, random-Text und FileSize nimmt, kann man das immer noch sehen in Java und dementsprechend manipulieren.
Was mich aber am meisten stört ist, dass man sich so oft Punkte geben kann, wie es auch nur geht. Siehe das Beispiel von oben.

Meine Frage ist nun.. wie geht ihr da voran? Natürlich erwarte ich keine 100%tige Lösung. Es ist Reverse Engineering, man kann nichts vor Reverse Engineering schützen. Aber trotzdem wäre es nicht schlecht, es sicher wie möglich zu gestalten.

Würde mich um Antworten freuen.

Vielen Dank!

MfG
 
A

Anzeige


Vielleicht hilft dir dieser Kurs hier weiter: (hier klicken)
Einfach den User vorher am Server registrieren lassen und beim Start des Spiels muss der User sich halt jedesmal mit seinem Passwort anmelden. Das ist 100% sicher
 
Alleine schon die Tatsache, dass sich der CLIENT Punkte geben kann, indem er das dem Server einfach sagt, ist schon unglaublich verkorkstes Design und ruft ja geradezu zum Cheaten/Ausnutzen auf.
Spiele, die einigermaßen sicher sind, implementieren immer eine serverseitige Simulation des Spiels und Validierung der Usereingaben. Das heißt, der Server weiß als einziger, wann ein Spieler wieviele Punkte bekommt und ein Client kann den Server selbstverständlich nie einfach anweisen, ihm eine bestimmte Punktezahl zu geben oder sonstirgendwie den Zustand des Spieles zu beeinflussen, nur weil er (der Client) das sagt.
Eine der allerallergrundlegendsten Regeln beim Entwickeln einer sicheren Client/Server-Architektur ist: Traue dem Client NIEMALS! Gehe IMMER davon aus, dass der Client z.B. einen Netzwerksniffer verwendet, um einmal mit dem echten Client seinen Punktestand (z.B. auch mit einem korrekten Passwort) zu setzen und dann netzwerkbasierte Replay-Attacken mit erhöhten Punkteständen sendet. Hierzu muss man noch nichtmal deinen Java-Code decompilieren und verstehen.
Am sichersten ist es, wenn der Client nur Usereingaben (User betätigt Button X, Y oder Z oder User klick Maustaste 1, 2 oder 3) an den Server sendet und dieser die gesamte Simulation und Kontrolle über das Geschehen hat. Natürlich wird ein vernünftig implementierter Client hier Latenzüberbrückungsstrategien (Dead Reckoning bzw. Event-Extrapolation) anwenden, um dem Spieler ein flüssiges Spielerlebnis zu gewährleisten.
 
Einfach den User vorher am Server registrieren lassen und beim Start des Spiels muss der User sich halt jedesmal mit seinem Passwort anmelden. Das ist 100% sicher
Das würde nicht viel bringen, wenn serverseitig nicht viel kommt. Man kann einfach einen Debugger verwenden und die Passwortabfrage überspringen. Wäre auch nicht die optimale Lösung.

Am sichersten ist es, wenn der Client nur Usereingaben (User betätigt Button X, Y oder Z oder User klick Maustaste 1, 2 oder 3) an den Server sendet und dieser die gesamte Simulation und Kontrolle über das Geschehen hat. Natürlich wird ein vernünftig implementierter Client hier Latenzüberbrückungsstrategien (Dead Reckoning bzw. Event-Extrapolation) anwenden, um dem Spieler ein flüssiges Spielerlebnis zu gewährleisten.
Daran hatte ich auch gedacht. Aber dann kommt die Frage: Was passiert, wenn der Spieler den "Button" spammt oder den Button überspringt? Wie muss das serverseitig gemacht werden? Außerdem.. wenn man in einem Spiel sich bewegen kann, kann man ja unmöglich die einzelnen Bewegungen vom Server verwalten lassen. Soweit ich weiß, machen das nicht mal so viele Spiele. Die Bewegung vom Client serverseitig zu machen, sodass bei der Modifizierung des Clients der Server dann den Spieler darauf hinweist, dass seine Bewegungen falsch sind, verbraucht das nicht viel Leistung? Was ist, wenn der Spieler Latenz Probleme hat? > 100ms und man müsste Toleranzen einbauen. Hast du ja schon drauf angesprochen.

Man könnte Limitierungen zu den Buttons einbauen, aber man könnte dann in anderen Zeitpunkten andere Buttons betätigen, die den Anwender zum Vorteil bringen können. Serverseitig dies abzufragen ist gar nicht mal so leicht, da man immer die States überprüfen muss, wie die Lage ist uvm.

Hätte nie gedacht, dass das serverseitige Programmieren so eine harte Nummer ist. Ist auch der Grund, warum Spiele Entwickler für ihre Spiele ein Hackshield verwenden, da vieles vom Client ist.

Eine entscheidende Frage habe ich:
Wie überprüft man, ob die Anwendung modifiziert ist oder nicht? Man könne ja die Hash vom File nehmen, aber dies kann man ja modifizieren. Was wäre die optimale Verifikation?
 
Zuletzt bearbeitet:
Eine entscheidende Frage habe ich:
Wie überprüft man, ob die Anwendung modifiziert ist oder nicht?
Abgesehen davon, dass ich mir ziemlich sicher bin, dass es kein sicheres Verfahren dafür gibt (in irgendeiner Form ist die Anwendung beteiligt), ist das m. E. auch die falsche Frage.

Es geht nicht darum, die Integrität der Client-Anwendung, sondern in erster Linie die Identität des Anwenders festzustellen. Hierfür bietet Mehrfaktor-Authentifizierung ein vergleichsweise hohes Sicherheitsniveau. Auch gegen Replay-Attacken gibt es geeignete Maßnahmen (z. B. Einmal-Passwörter).

Das alles bitte vor dem Hintergrund, dass ich kein Sicherheitsexperte bin :)
 
Die Authentizität des Nutzers zu beweisen, bringt dir nur etwas, wenn es eben nicht gerade ein authentisierter Benutzer ist, der das System hacken will und sich einen höheren Punktestand zuweisen möchte.
Du möchtest sicherstellen, dass der Client im Auftrag des Users eben keine unplausiblen/inkonsistenten/unerlaubten Kommandos zum Server sendet. Und das ist nur möglich, wenn es sich bei solchen Kommandos eben nicht um absolute Befehle wie etwa "Gib mir 100000 credits" handelt, sondern um Aktionen, die der Server auch validieren bzw. auf Plausibilität prüfen kann.
Ich weiß ja nicht, um welches Spiel oder welches Genre es bei dir geht, aber so ziemlich jeder AAA First-Person-Shooter macht genau das: Er sendet nur die Tastatur/Maus/Controller-Eingaben an den Server und der Server simuliert für alle aktiven Spieler das Spielgeschehen samt Physik. Natürlich simuliert der Client das Spiel auf seiner Seite auch nochmal, um eben Latenzen zu verstecken und es werden Kompromisse eingegangen, basierend auf dem Gameplay. Für Overwatch schau dir z.B. mal das hier an:
 
Was passiert, wenn der Spieler den "Button" spammt oder den Button überspringt? Wie muss das serverseitig gemacht werden?
Du musst das Spiel so designen, dass es entweder irrelevant ist, ob ein Spieler einen Button "spammt": Z.B. ist es in einem First-Person-Shooter ja egal, wenn ein Spieler zwanzigmal pro Sekunde "Vorwärts" drückt. Im Zweifel ist ihm das sogar zum Nachteil verglichen mit einem Spieler, der eben Vorwärts die ganze Zeit gedrückt hält. Wenn pro Tastendruck tatsächlich eine wichtige Aktion ausgelöst wird, dann gilt wieder: Server muss auf Plausibilität prüfen und du brauchst dann wohl eine Art cooldown-Zeit für den Tastendruck, der vom Server enforciert wird.
Außerdem.. wenn man in einem Spiel sich bewegen kann, kann man ja unmöglich die einzelnen Bewegungen vom Server verwalten lassen. Soweit ich weiß, machen das nicht mal so viele Spiele. Die Bewegung vom Client serverseitig zu machen, sodass bei der Modifizierung des Clients der Server dann den Spieler darauf hinweist, dass seine Bewegungen falsch sind, verbraucht das nicht viel Leistung?
Und genau das tun eigentlich alle Spiele. (siehe oben) Natürlich verbraucht das "Leistung". Musst dein Spiel dann halt effizient implementieren.
Was ist, wenn der Spieler Latenz Probleme hat? > 100ms und man müsste Toleranzen einbauen. Hast du ja schon drauf angesprochen.
Genau, das ist ein großes Problem für viele Spiele. Insbesondere z.B. PLAYERUNKNOWN'S Battlegrounds, wo es für den Client sogar von Vorteil ist, einen hohen Ping zu haben (wird auch im Overwatch-Video angesprochen).
Man könnte Limitierungen zu den Buttons einbauen, aber man könnte dann in anderen Zeitpunkten andere Buttons betätigen, die den Anwender zum Vorteil bringen können. Serverseitig dies abzufragen ist gar nicht mal so leicht, da man immer die States überprüfen muss, wie die Lage ist uvm.
Natürlich. Und genau das musst du tun.
Wie überprüft man, ob die Anwendung modifiziert ist oder nicht? Man könne ja die Hash vom File nehmen, aber dies kann man ja modifizieren. Was wäre die optimale Verifikation?
Gar nicht. Das einzige, was der Server sieht, ist ja, was der Client ihm über das Netzwerk sendet. Versuche dir also vorzustellen: Es gibt gar keinen Client bzw. du weißt nicht, wie dieser aussieht. Du siehst nur die Informationen, die der Client dem Server sendet. Alles kann abgegriffen werden, alles kann geforged/fabriziert werden. Es bringt z.B. auch nichts, die Informationen mit einem Schlüssel zu verschlüsseln. Mit asynchroner Verschlüsselung könnte man diese Informationen zwar nicht wieder entschlüsseln (das kann dann nur der Server), aber man kann sich dann wiederum den Quellcode angucken und herausfinden, wie denn die noch unverschlüsselten Informationen generiert werden und diese dann mit dem notwendigerweise bekannten Schlüssel verschlüsseln. Ein großer Faktor für die Sicherheit deines Spiels wird also notwendigerweise "Security through Obscurity" werden.
 
Die Authentizität des Nutzers zu beweisen, bringt dir nur etwas, wenn es eben nicht gerade ein authentisierter Benutzer ist, der das System hacken will und sich einen höheren Punktestand zuweisen möchte.
Du hast natürlich vollkommen Recht. In meinem Umfeld habe ich genau mit dem von Dir geschilderten Fall zu tun :)

Sein Beispiel wäre dagegen in etwa so, als würde sich der Server bei einer Bestellung auf den vom Client übermittelten Preis verlassen.
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben