Datenbankdaten nicht beim Client speichern?
Guten Tag,
für z.B. ein Login-System; macht es Sinn eine API für den Server zu schreiben welche ein boolean zurückgibt, ob das gehashte Passwort zum Nutzer passt. Für eine solche Art von Anfrage bräuchte ich ja dann nur die IP des Servers.
Oder gibt es einfachere Lösungen um dieses Problem zu umgehen? Im Endeffekt war das das erste, was mir bei dieser Frage in den Kopf gekommen ist.
Wie würdet ihr das Problem lösen?
5 Antworten
Hi AlessandroO6,
wie schon TheQ86 geschrieben hat, gehört die Login-Validierung immer auf dem Server und sollte nur dort durchgeführt werden. Man kann vorab, bevor man einen HTTP-Request sendet mit JavaScript die Eingaben prüfen auf Fehler oder Unschlüssigkeiten, aber die Hauptvalidierung und Passwortabgleich sollte auschließlich auf dem Server basieren. Es sollte auch der Datenbank-Server auf dem Server liegen und keine clientseitige Lösung.
Und bitte daran denken Passwörter nicht im Klartext zu speichern, sondern als Passwort-Hash. Und wenn es noch Professioneller machen möchte, änderst du regelmäßig den Passwort-Hash ab.
Gerne,
alles was Sicherheitsrelevant ist, sollte man auf dem Server laufen lassen. Zum Beispiel sollte man bei einer Bestellung nur die ID's der noch zu bestellenden Artikel übergeben und keine Preise oder Rabatte. Das soll erst auf dem Server geschehen, da sonst Daten manipuliert werden können und es spart Daten die übertragen werden müssten.
Du willst also, dass jeder, mehr oder weniger öffentlich, Daten an den Server senden kann? Also falls es ein Spiel sein sollte ein öffentliches Scoreboard, wo sich jeder beteiligen kann.
Wenn man vor allem auch das Dekompilieren (Source Code anschauen) des Programms betrachtet, dürfte man es nie zu 100% umsetzen können. Man kann lediglich Maßnahmen ergreifen, dass es sehr schwer ist.
Zum einen ist eine API, die nur das nötige Bereitstellt, ein wichtiger Punkt. So kannst du die Operationen auf der Datenbank stark begrenzen. Im Fall vom Scoreboard gäbe es z.B. getTopScoreboard und ein addScore Operationen. Ein Editieren oder Löschen ist damit komplett weg.
Damit die API nicht einfach von jedem genutzt werden kann, sollte dort auch eine Authentifizierung per z.B. Passwort oder Token davor sein. Auch wenn es gehasht ist, wird man es bestimmt extrahieren und selber nutzen können. Der integrierte Client ist ja auch in der Lage, den Hash zu benutzen.
Für Kommunikation sollte auch HTTPS (oder ein anderes sicheres Protokoll) genutzt werden, um die versendeten Daten bei der Übertragung zu schützen.
Um das Reverse Engineering zu erschweren könntest du die versendeten Daten auch beispielsweise als Base64 encoden, damit der konkrete Inhalt nicht direkt ersichtlich ist. Andere Verfahren als Base64 werden besser sein.
Falls doch irgendwann das Passwort/Token, die URL und das versendete Format bekannt ist, kannst du auch zum Inhalt ein Hash (z.B. SHA256) ergänzen. So kannst du eine Manipulation des Inhalts erkennen. Wenn z.B. der Score eine 0 mehr hat, passt die Hashsumme nicht mehr. Man müsste also die Verwendung einer Hashsumme erkennen und erneut berechnen, damit der Server die Anfrage akzeptiert.
Da es anscheinend um JavaScript geht und der Source Code eben immer offen ist, ist ein verstecken vom Source auch schwierig. Um den Code schwerer lesen zu können, könntest du den Code noch obfuscaten. Absolut sicher ist auch das nicht.
Mit den zahlreichen Maßnahmen kannst du es stark erschweren, sodass es nicht so häufig ausgenutzt wird bzw. es auch für das Reverse Engineering dauert.
Wie viel du davon umsetzen willst, musst du wissen. Da es nur für ein Projekt in der Schule ist, wird wohl ein Server mit API und Passwort/Token beim Client schon ein guter Schritt sein.
Als Alternative könnte auch jeder Nutzer ein eigenes Konto erhalten. Es kann zwar jeder Daten zur API senden/abrufen, aber du weißt am Ende, wer es war. Die Nutzer könntest du selber Verwalten oder via z.B. Login mit Google auslagern. Die Anbindung wäre z.B. über das OpenID-Connect Protokoll. Um Passwörter musst du dich dann noch nicht mal kümmern.
für z.B. ein Login-System; macht es Sinn eine API für den Server zu schreiben welche ein boolean zurückgibt, ob das gehashte Passwort zum Nutzer passt.
Login-Validierung gehört IMMER serverseitig gemacht. Clientseitig kann der Client sonst manipulieren, wie es ihm passt. Der Server muss verifizieren, dass der Benutzer authentifiziert ist und das geht nur, wenn er die Datenhoheit hat.
Das zurückgeben, ob das übertragene Passwort dem gehashten Passwort in der DB entspricht ist nur ein Schritt, den so ein Login-Service tun muss. In der Regel setzt dieser dann auch ein Session-Cookie.
Ich rate sehr stark dazu, als Anfänger da nichts selbst zu bauen, sondern sich an ein Framework zu halten und zu verstehen, was genau das macht.
Zum Üben und Rumspielen, für einen nicht echten Service kann man das aber so machen.
Es geht auch genau um das üben. Glaube kaum, dass der InformatikLK eines Gymnasium das nächste Facebook entwickelt :o
Eine Datenbank die auf einem entfernten Server liegt sollte niemals in irgendeiner Form von außen erreichbar sein. Die Kommunikation sollte nur über eine API erfolgen die nur das allernötigste annimmt und rausgibt.
D.h. das einzige was dem Client bekannt sein muss ist der Hostname. Aber niemals Username und Password für die DB.
API ist vielleicht etwas hoch gegriffen. Ich weiß ja nicht, um was es genau geht, in welcher Sprache du arbeitest und in welcher Umgebung, aber für ein Login-Script brauchst du nur die Zugangsdaten für den Datenbankserver: Host-Adresse - da könnte man sicher auch die IP nutzen, aber das ist eher unüblich - Nutzer und Passwort.
Wenn der Client direkt auf die Datenbank zugreifen kann währe das ein extremes Sicherheits risiko, da somit jeder Nutzer des Programms die DB login Daten aus dem Programm entnehmen könnte und somit alles in der DB lesen und manipulieren könnte.
Das meinte ich ja, danke. Logindaten in lokalen Variablen beim Client zu speichern ist praktisch das gleiche, als wenn ich dem Client direkt die Daten für die DB in Plaintext schicke und sage "Guck mal selbst nach". Und dem Angreifer in dem Fall zu sagen, dass er es für sich selbst macht und er bitte nicht schummeln soll, ist genauso leichtsinnig, wie der Mathelehrer, der die Lösungen der Aufgaben bereits im Voraus an die Schüler verteilt :o
Alles klar, also war da mein Gedankengang schon richtig. Danke.