Jump to content
Unity Insider Forum

Sicherheitskonzept [MySql DB]


Triky313

Recommended Posts

Hallo Leute,

ich arbeite gerade an einem kleines Spiel, welche über PHP-Scripte und MySQL Datenbank verschiedene Daten (CRUD) austauschen soll.

Zu Testzwecken habe ich die WWW-Class aus Unity verwendet. Das funktioniert auch bestens.

 

Nun ist es so, jeder hat erst einmal Zugriff auf die PHP-Scripte.

Der Transport wird per JSON-String gemacht und die PHP Scripte sind per prepare, execute und bindParam soweit abgesichert.

Meine Frage ist, wie verschlüsselt ihr das am besten?

Irgendeine SHA256 oder 512er Verschlüsselung?

 

Ich würde es gern vermeiden später offen wie ein Scheunentor zu sein.

 

Gruß,

Aaron

Link zu diesem Kommentar
Auf anderen Seiten teilen

Am besten direkt den JSON String 

{"name":"Aaron","age":31}

Der ist per URL ja sonst von allen abgreifbar und vor allem INSERTS können später Problematisch werden.

Ich möchte ja nur aus dem Spiel heraus den Server updaten können und nicht per URL unabhängig davon.

 

Oder was auch möglich wäre, eine Authentifizierung. Bearer oder ähnliches? Ist das mit Unity überhaupt möglich?

Link zu diesem Kommentar
Auf anderen Seiten teilen

So, habe jetzt mal ein wenig herum getestet.

Im Prinzip muss es doch möglich sein eine Session zwischen Unity und PHP aufzubauen oder nicht?

Ich kann das eingegebene Passwort ja in Unity schon verschlüsseln und rüber senden. Leider finde ich so gut wie nicht wenn ich nach sicheren Verbindungen zwischen Unity und PHP suche. Es kann doch nicht sein, dass dieser Aspekt so ignoriert wird?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Also geht es gar nicht um Passwörter, sondern einfach nur darum, dass der Benutzer nicht so einfach eigene Anfragen forgen kann.

Das geht grundsätzlich erstmal ganz einfach. Du schmeißt alle Anfragerelevanten Daten zusammen mit einem Timestamp (wenn der nicht eh schon drin ist) und einem geheimen Schlüssel in einen String und diesen dann wieder in eine beliebige Hashfunktion. SHA-256 ist schon ein dickes Ding, aber was soll's. Hauptsache nicht md5 oder sowas :)

Den Hash hängst du als weiteren Parameter an deine Anfragel. Dann nimmst serverseitig die gesendeten Parameter und machst genau dasselbe mit ihnen noch einmal. Wenn derselbe Hash dabei rauskommt, akzeptierst du die Anfrage.

Man darf sich nur halt nicht einbilden, dass so etwas zu 100% sicher ist. Es geht dabei immer nur darum, dass der Aufwand hoch genug gehalten wird, dass es sich für den Angreifer nicht mehr lohnt, so viel zu investieren.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Also ich würde ja grundsätzlich empfehlen, dass alles was vom Client kommt, per se erstmal als unsicher einzustufen.

Egal, was und wie man clientseitig verschlüsselt, kann von einem potentiellen Angreifer ausgelesen und nachgebaut werden. Daher macht es, zumindest aus einem Sicherheitsaspekt keinen Sinn, den Inhalt von Anfragen zu verschlüsseln.

Daher ist die einzige saubere Lösung, dass man den Server soweit absichert, dass er Anfragen entsprechend prüft und validiert und ungültige Daten verwirft, bzw. nicht weiter verarbeitet. Alles andere ist nur eine Illusion von Sicherheit...

Link zu diesem Kommentar
Auf anderen Seiten teilen

Okay also das hashen läuft zurzeit Testweise mit md5, da ich Sha256 nicht auf beiden Seiten (C# und PHP) mit gleichem Ergebnis bekomme.

Falls ihr da noch einen Tipp habt, wäre ich sehr dankbar.

 

Im Endeffekt kann ich aber festhalten, dass das Verbinden zu einem Server immer mit einem gewissen Risiko behaftet ist. Hätte nicht gedacht, dass es dann doch SO unsicher ist. Schade, dass sich die Clients so leicht dekompilieren lassen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Naja sobald Clientseitig einmal herausgefiltert wurde, welche Werte zum Hashen verwendet werden, ist die Katz' ausm Sack oder nicht? Das lässt sich dann doch ganz leicht nachbauen und direkt per URL im Browser übergeben. Ich würde es gern vermeiden, dass Leute sich Münzen oder sonstige Dinge erschleichen können. 

Zusätzlich werde ich wohl eine Grenze einbauen, welche Maximalwerte nicht überschreiten dürfen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 38 Minuten schrieb Overload:

Vor der selben Problemstellung stehe ich auch derzeit. Ebenfalls mit PHP Files auf SQL Datenbank.

Selbe Befürchtung: Wenn Quellcode dekompiliert wird ist der Secretkey aufgeflogen und man erkennt mit welcher Methode gehashed wurde oder nicht ?

So nehme ich das zurzeit auch wahr. Das beunruhigt mich etwas.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das ist genau der Punkt, warum es grundsätzlich egal ist, ob gehashed wurde oder nicht.

Daher sollte Dein Server, und die entsprechenden Mechaniken, eben so gestrickt sein, dass es einem Angreifer nicht möglich ist, sich Dinge zu erschleichen.

Maximalwerte sind da auch nicht die Lösung. Denn grundsätzlich ist es ja egal, ob sich jemand 10 Münzen erschleicht, oder 10.000 Münzen.

 

Vielleicht kannst du ja mal ein konkretes Beispiel aus deinem Projekt darstellen, bei dem Du Befürchtungen hast, dass sich Dinge erschlichen werden können. Dann können wir hier mal drüber schauen...

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich bin noch in der Testphase...

Zurzeit sieht es so aus, dass ich einen Type, die Werte und einen Hash dazu übergebe. Der Hash besteht dabei aus den angegebenen Values, DateTime angaben und einem Salt:

public bool ExistUser(ulong steamUserId)
        {
            var form = new WWWForm();
            form.AddField("type", "existUser");
            form.AddField("values", steamUserId.ToString());
            form.AddField("hash", Hash.GetHash(steamUserId.ToString()));

            var w = new WWW(UrlSelect, form);
            StartCoroutine(Select(w));

            return true;
        }

 

Auf der Server Seite mit PHP sieht es ähnlich aus.

Wenn der Hash-Wert aus der Request und der neu zusammengesetzte Hash aus Values der Request und DateTime + Salt vom Server passt, ist es okay.

if(!HashController::isHashOkay($_REQUEST['hash'], HashController::getHash($_REQUEST['values']))) {
	echo 'KEINE ÜBEREINSTIMMUNG';
} else {
	echo 'PASST!';
}

 

Trotzdem lässt sich dies ja dann wenn man den Client auslesen kann komplett umgehen, da die Struktur von [Value + DateTime + Salt] die gleiche ist wie auf dem Server.

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Genau.

Und deswegen ist das Hashen sinnlos. Bzw bringt dir praktisch kein Plus an Sicherheit.

Deswegen muss der Server so gestrickt sein, dass er validiert, ob die Daten vom Client grundsätzlich richtig sind. Und der Client darf eben keine kritischen Daten schicken.

Beispiel:

Der Client darf nicht festlegen, wie viele Punkte jemand hat oder wieviele Münzen/Coins/etc er gesammelt hat.

Sondern der Client schickt an den Server, welche Aktionen er durchgeführt hat und der Server schaut dann, ob diese Aktion für diesen Client/User valide und erlaubt ist und wenn diese Prüfung positiv ist, bekommt er Münzen/Coins/etc gutgeschrieben und schickt diese Info wieder an den Client, die der Client dann anzeigt.

Eiserne Regel: NEVER trust the client

Link zu diesem Kommentar
Auf anderen Seiten teilen

Puh,

das wäre ja ein RIESEN Aufwand für schon eine einzige Abfrage. Wenn ich mit einer Abfrage Münzen gut schreiben möchte, würde ich im Client natürlich gern variable Werte angeben können. 

Wenn ich jetzt aber versuche dem Server mitzuteilen, dass eine bestimmte Sache passiert ist, welche nicht unbedingt die Werte enthält, ist man ziemlich eingeschränkt.

Ich mein, ich schreibe gerade auf Arbeit eine Web.Api mit mehr als 300 Prozeduren, wenn ich das so wie hier machen müsste, wär ich ja locker 2000 Arbeitsstunden beschäftigt.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Also, jetzt würde ich gerne mal wissen, was du für ein Projekt machst., wenn du für eine Webschnittstelle 2000 Stunden veranschlagst.

In der Zeit habe ich einen kompletten Authoritative-Server für ein MMO mit ca. 50.000 Zeilen Code im Alleingang geschrieben...

 

Nichtsdestotrotz musst du dich fragen, was du willst. Entweder eine Serverschnittstelle, die jeder einfach manipulieren kann, oder eben nicht...

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Na aktuell habe ich ca. 500 Stunden für das Web.Api Projekt. Wir bauen eine komplett neue Verwaltungsanwendung für ein Unternehmen. Sollte ich aber das hier genannte Verfahren verwenden, bin ich (überspitzt gesehen) bei über 2000 Stunden.

Meine Frage ist nur, würde eine eigene Server Anwendung mehr Sicherheit bringen? Wahrscheinlich nicht.

Link zu diesem Kommentar
Auf anderen Seiten teilen

In Unity gibt es dazu noch nicht viel.

Jedoch habe ich vor mein BrowserGame in Unity umzusetzen. (verbessert)

https://aaronschultz.de/miniknights/

Zum testen einfach mal kurz mit irgend einem Namen anmelden.

Das sind alles statische Datenübertragungen, welche nicht permanent Daten an die DB schicken. Das soll auch in Unity so bleiben, nur dass ich alles mit ein paar Animationen usw. aufhübsche.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

×
×
  • Neu erstellen...