Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Wen meinst du mit "jemand" und wie sollte dieser Jemand Zugriff auf deinen Server erhalten?
Bei Serveranwendungen geht man grundsätzlich davon aus, dass ein Angreifer nicht den Prozess bzw. den Host selbst kontrollieren kann.
Irgendwo muessen sie unverschluesselt sein in deinem Applikationsspeicher, und wenn du so etwas wie Spring oder ein aehnliches Framework verwendest, kannst du das ohnehin nicht kontrollieren. System-Properties, trotz des Namens, propagieren *nicht* ins System. Die gelten nur fuer deinen Prozess und Aenderungen wandern nicht ueber deinen Prozess hinaus. Ich glaube Aenderungen sind sogar nur Java intern, also die wandern auch nicht in die Umgebung des Prozesses auf Betriebssystem-Ebene.
Also deinen *eigenen* Applikationsspeicher kannst du eigentlich immer als sicheren Ablageort fuer Informationen betrachten, weil wenn jemand den Speicher von deiner Applikation mitliest oder mitschneidet, ist ohnehin schon alles gelaufen, vorbei, erledigt, finito. Dann hast du bereits lange vorher verloren. Natuerlich gibt es das Prinzip "Geheimnisse sollte man nur so kurz wie moeglich im Speicher halten." aber in Java ist das etwas schwierig und die Idee kannst du eigentlich knicken. Weil nehmen wir mal an, dein Passwort wird aus einer Datei gelesen:
So, jetzt hast du zwar die *Variablenreferenz* auf null gesetzt, aber niemand und nichts sagt dir was mit dem Speicher von dem String ist. Schlimmer noch, nehmen wir an wir *koennten* den Speicher sicher loeschen:
Java:
String password = new String(Files.readAllBytes(Paths.get("password.text")), StandardCharSet.UTF8);
DatabaseConnection.init(password);
safelyDelete(password);
Selbst unter dieser Annahme, koennte dir die init Funktion einen Strich durch die Rechnung machen:
Java:
public class DatabaseConnection {
public static void init(String password) {
password = password.intern();
}
}
Und nun liegt dein Passwort im Java String-Cache...fuer immer, glaube ich. Ich kenne die Regeln nicht nach welchen der String-Intern-Cache ausgeleert wird. Das gleiche gilt wenn die Datenbankverbindung den JDBC-Connection-String speichert, da steht auch das Passwort drinnen.
Java:
public class DatabaseConnection {
private static connectionString;
public statitc void init(String password) {
connectionString = "jdbc://blabla:" + password + "/blabla";
// Verwendung hier.
}
}
Jetzt gibt es Leute die sagen "Mach' das doch char[], dann kannst du das sicher loeschen." Ja, ist richtig. Ein Array koennen wir tatsaechlich mit *sehr sehr hocher Wahrscheinlichkeit* sicher loeschen in dem wir die Daten darin einfach ueberschreiben:
Aber dennoch, *irgendwann* wurde das zu einem String umgewandelt wenn es eine Datenbank-Verbindung mit JDBC ist. Und ob der Speicher hier "korrekt" ueberschrieben wird, ist eigentlich ein Implementierungsdetail der JVM auf der du laeufst, nichts garantiert dir das.
Also wenn du nicht gerade eine extreme Anforderung hast, vertraue dem Speicher welcher deiner Applikation gehoert. Weil wenn du dem nicht vertrauen kannst, ist die Sache gelaufen.
Tatsaechlich habe ich mal an einem Projekt gearbeitet wo wir eine solche Anforderung hatten...es ist die Hoelle. Wir mussten eine komplett abgesicherte Hardware-Struktur aufbauen (zugesperrtes BIOS, abgesicherter Boot, signiertes Betriebssystem, signierte Applikation, nicht mal Admin kann mehr Sachen machen und so weiter) um die Anforderung zu erfuellen. Und da hoerte es nicht auf, physische Masznahmen kommen dann ja auch noch dazu (sonst geht jemand zum Server und tut dort einfach Dinge).
EDIT: ich hatte die Bemerkúngen von @Robert Zenz noch nicht gelesen
Hallo,
du hast ein grundsätzliches Problem: Das Programm muss sich mit der Datenbank verbinden und die Verbindungsdaten müssen dem Programm bekannt sein, "Jemand" kann diese Verbidungsdaten aus dem Programm oder seinen Property-Dateien auslesen.
Meist "löst" man dieses Problem, indem man den Client auf einen Server zugreifen lässt, der die Verbindungsdaten zur Datenbak kennt, Aber dies ist nur ene Erschwerung des Zugriffs (und so habe ich auch @httpdigest verstanden), aber es löst das Problem nicht entgültig.
Es kann also nur darum gehen, dem "jemand" (Angreifer) das Leben möglichst schwer zu machen . Einen erfolgreichen Angriff kannst du nicht verhindern.
Diese Aussage ist falsch. Der Datenbankzugang wird idR verschlüsselt im Buildsystem hinterlegt und nur während des Build-Vorgangs als Umgebungsvariablen promoted.
Diese Aussage ist falsch. Der Datenbankzugang wird idR verschlüsselt im Buildsystem hinterlegt und nur während des Build-Vorgangs als Umgebungsvariablen promoted.
Koenntest du mir dann bitte demonstrieren wie du in Java eine Datenbankverbindung herstellst *ohne* die Zugangsdaten (im Klartext) im Speicher der JVM zu haben?
Du solltest vllt mal single Source of truth in betracht ziehen im prinzip geht es darum
du gibst client das programm
derjenige decompiliert es
und ändert es um
oder spielt böse rum
um hier beispiel zu nennen
in unity kannst du als client deine FPS rate deinem Server vorgaukeln dass diese Doppelt so hoch,also bei fps basierter bewegung bewegst du dich doppelt so schnell , indem du eine readonly variable von außen im speicher änderst, das ist mal als "böse rum spielen" gedacht gewesen
das decompilieren ist nicht schwer... jaja es gibt obfuscatoren aber jemand der es will kommt auch ran
jetzt könntest du einen Server dazwischen stellen der auf deine Datenbank aufpasst und entscheidet "lass ich jetzt den dude rein oder nicht" ... der Server überprüfut alles und entscheidet immer auf basis der Einstellung dass der Gegenüber gelogen hat und rum gepfuscht hat
so wurde es in Call of duty, und so ziemlich allen Unity spielen mit photon umgesetzt, nur dein Server hat recht und der Client ist erst einmal immer falsch
deswegen braucht call of duden modern rechtschreibung auch kein "easy anti cheat" ( ist client seite überprüfung ob unfug getrieben wird ) sondern wenn jemand schwachsinn sagt beurteilt der server das und wenn das ZIEMLICHER schwachsinn ist wie rum fliegen ... DELETE FROM * .. .oder ähnliches dann wird die anfrage erstmal verworfen und abgespeichert dass da jemand grampf gemacht hat ( bzw in call of duden automatisches bannen )
ich weis nicht wie ich das single source of truth anders ohne spiele erklären soll...aber datenbank von außen zugänglich machen puh...
natürlich hast du damit neue probleme wie zb du machst nen port auf und da kann man auch wieder böse sachen tun ...wie zb gespammt werden mit fake anfragen ( denial of service )
Ich sehe eher hier einen Designfehler der Anwendung. Den direkte Zugriff auf eine zentrale DB sollte es niemals geben (Es geht nicht um eine lokale DB mit privatem Zugriff). Der Zugriff erfolgt immer über eine Zwischenschicht/Server. Am Server wird der Kunde authentifiziert und autorisiert, d.h. jeder Kunde hat eigene Zugangsdaten und diese werden nicht in der Anwendung als Konstanten hinterlegt. Die Autorisierung stellt sicher, dass keine Daten gelesen oder manipuliert werden können, welche nicht für den Kunden bestimmt sind. Werden die Zugangsdaten eines Kunden gestohlen, können also nur die Daten diese Kunden kompromittiert werden. Es ist also niemals "alles verloren". Du bist sogar verpflichtet so vorzugehen. Nimmt man mal "verloren" wörtlich, dann kommt hier noch ein weiterer Aspekt des Datenschutzes ins Spiel. Datenschutz bedeutet nicht nur Daten vor unberechtigtem Zugang zu schützen, sondern auch deren Verfügbarkeit und Integrität zu gewährleisten. Man muss sich bspw. auch überlegen, wie sind meine Daten im Falle von technischen Defekten, Feuer oder Naturkatastrophen geschützt.
Vielleicht sollte man mal klären, von was von einer Anwendung reden wir hier:
Client-Anwendung => DB Passwort hat nichts verloren in der Anwendung, es gibt zwischen Client und DB eine Schicht, die den Client authorisiert und dafür sorgt, dass er nur die Dinge tun darf, auf die er berechtigt ist
Server-Anwendung => DB-Passwort ist im Klartext verfügbar (man kann es zwar erschweren, aber im End-Effekt ist es im Klartext in der Anwendung verfügbar)
Besser ist es, davon auszugehen, dass jeder der Zugriff auf den Server hat auf ALLES Zugriff hat. Wer keinen Zugriff auf den Server hat, wird auch auf System.getProperty nicht zugreifen können.
Aber wenn du PHP und C benutzt: an welcher Stelle benutzt du System#getProperty?
Das ist ein Witz oder? Als ob man C-Code nicht dekompilieren oder debuggen könnte. Das habe ich früher immer gemacht, um für PC-Spiele keine CD einlegen zu müssen.
Das ist ein Witz oder? Als ob man C-Code nicht dekompilieren oder debuggen könnte. Das habe ich früher immer gemacht, um für PC-Spiele keine CD einlegen zu müssen.
Naja, du hast gesagt: "Jetzt sag nicht Daten auf einem Server ablegen",
woraufhin ich sagte: "Daten auf einem Server ablegen"
Andere Frage: Warum gibt Facebook nicht einfach die Datenbank-Credentials zum Ausführen von SQL-Statements auf ihrer gesamten Datenbasis jedem User, dann kann jeder User ja einfach selbst SQL-Statements abfeuern (jetzt mal angenommen, Facebook hat ein relationales Datenbank-Management-System im Einsatz).
Nein... stattdessen bietet Facebook dir ein Web UI, auf dem du dich eben mit deinem User anmelden musst + eine restriktierte Sicht auf die Daten in Form einer API.
Antwort: Principle of least privileges.
Natürlich braucht ein User erstmal eine Authentifizierung, um seine Identität deiner Anwendung gegenüber zu beweisen. Aber das heißt ja selbstverständlich lange noch nicht, dass das gleich die Datenbank-Credentials sein müssen, mit denen er sich gleich an der Datenbank anmelden. Das ist totaler Quatsch.
Ich habe eine Java App die auf dem Kunden PC laufen soll.
Zugriff auf Server passiert über UserAccount des Servers und dann über PHP auf die DB.
Im Programmablauf werden aber auch immer wieder per SFTP Dateien übertragen.
Der Zugriff auf die DB wird erst auf dem Server im PHP entschlüsselt.
Der User soll aber auch auf andere Server zugreifen können, ohne das Bewusst zu merken.
Der Punkt ist halt der das alles auf dem Rechner des Kunden läuft.
Zugänge werden dorthin erst bei Anwendungsstart verschlüsselt übermittelt und dann
deshalb meine Frage zu den Properties entschlüsselt.
Die Entschlüsselung übernimmt das C Programm.
Nach Anwendungsende befinden sich keine Zugangsdaten mehr auf dem Kunden PC.
Als ich gesehen wie einfach Java zu dekompilieren ist habe ich die Verschlüsselungsalgorithmen
in C geschrieben und dieses C Programm im Javaprogramm eingebunden.
Es ist auch nicht einfach zu starten aber im Dekompilierten Java-Progamm ist ja alles offen wenn man
nur genügend Zeit investiert.
Das muss doch sicher umsetzbar sein
oder muss ich alles umbauen und irgendwie versuchen die JavaApp vom Server zu starten ?
Wie könnte das gehen.
Das hört sich - gelinde gesagt - alles sehr strange an.
Wenn du wirklich Hilfe willst, musst du mal erklären was du eigentlich tust.
Es geht hier um DBs, SFTPs, Server und irgendwelche Zugangsdaten. Zugangsdaten wozu?
Also, wer kommunziert mit wem und wo werden Zugangsdaten benötigt?
Wenn die auf dem Server entschlüsselt werden, haben die mal gar nichts auf dem Client verloren. Dann kann man auf dem Client API-Keys hinterlegen, die auf dem Server gegen Zugangsdaten gemappt werden - aber niemals irgendwelche entschlüsselbaren Daten.
Wenn die auf dem Client entschlüsselt werden - egal ob Jave oder C - dann sind dem Client im Klartext bekannt und als unsicher anzusehen. Das heißt, es dürfen nur Zugangsdaten sein, wo nichts schlimmes passiert, wenn die dem User bekannt sind.
Zugangsdaten auf den Server des Clients werden von einem Headerserver abgefragt und verschlüsselt übermittelt.
Zum Programmstart werden diese entschlüsselt und stehen dem Client zur Laufzeit zur Verfügung.
PHPs werden mit verschlüsselten Daten für den Datenbankzugriff aufgerufen und im PHP auf dem Server entschlüsseln
dann greifen diese PHPs auf die DB zu und schicken Ihren Response.
Dateien werden per SFTP im UserAccount übertragen und stehen der Anwendung zur Laufzeit zur Verfügung.
SQLs können nur nach Entschlüsselung eines Codes verwendet werden,
DB Zugriffsdaten müssen auch erst im PHP entscchlüsselt werden.
Das läuft alles und zwar schnell.
Wenn Recompilen nicht möglich wäre, gäbe es kein Sicherheitsproblem.
Deshalb meine Frage zur Möglichkeit die JavaAnwendung auf dem Server zur Verfügung zu stellen
und diese ohne Programmdaten auf dem Client PC laufen zu lassen ohne den Server zu belasten.
Zugangsdaten auf den Server des Clients werden von einem Headerserver abgefragt und verschlüsselt übermittelt.
Zum Programmstart werden diese entschlüsselt und stehen dem Client zur Laufzeit zur Verfügung.
Okay, warum machst du das?
Warum müssen hier irgendwelche Zugangsdaten zu einem Server an einen Client transportiert werden?
Das Ziel sollte nicht sein, dass der Client sich gegenüber dem Server authentifiziert (bzw. beweist, dass er etwas "hat" - im Sinne der Informationssicherheit), sondern dass der User/Benutzer etwas weiß/hat, um sich mit Hilfe des Clients am Server (oder einem anderen Identity Provider - siehe z.B. OAuth) zu authentifizieren.
Man authentifiziert niemals Clients/Programme/Apps, sondern immer Benutzer/User, mit etwas, was der Benutzer entweder:
a) ist (Biometrie)
b) hat (z.B. Hardware-Dongle)
c) weiß (z.B. Passwort)
Wie @LimDul schon sagte: Vertraue NIEMALS dem Client/Programm. Nur dem User.
Das, was du machst, ist _genau_ die Definition von "Security by Obscurity" wie @Oneixee5 schon schrieb.
Zugangsdaten auf den Server des Clients werden von einem Headerserver abgefragt und verschlüsselt übermittelt.
Zum Programmstart werden diese entschlüsselt und stehen dem Client zur Laufzeit zur Verfügung.
PHPs werden mit verschlüsselten Daten für den Datenbankzugriff aufgerufen und im PHP auf dem Server entschlüsseln
dann greifen diese PHPs auf die DB zu und schicken Ihren Response.
Dateien werden per SFTP im UserAccount übertragen und stehen der Anwendung zur Laufzeit zur Verfügung.
SQLs können nur nach Entschlüsselung eines Codes verwendet werden,
DB Zugriffsdaten müssen auch erst im PHP entscchlüsselt werden.
Das läuft alles und zwar schnell.
Wenn Recompilen nicht möglich wäre, gäbe es kein Sicherheitsproblem.
Deshalb meine Frage zur Möglichkeit die JavaAnwendung auf dem Server zur Verfügung zu stellen
und diese ohne Programmdaten auf dem Client PC laufen zu lassen ohne den Server zu belasten.
@LimDul Der Headerserver wird zwingend für die App gebraucht.
In der App kann man Benutzer anlegen und alle müssen auf Ihren Server sowie auf den HeaderServer zugreifen.
Dabei kommt es auf beiden Servern zu Datenbankzugriffen und SFTP
Der Zugriff auf die Server erfolgt als User des Servers.
Jeder ClientServer hat einen eigenen User und der HeaderServer hat einen eigenen User.
Wie kann man das mit dem von Euch beschrieben Konzepten umsetzen.
Wäre toll wenn das jemand erklären wollte, aber sonst würde mir ein Link schon sehr helfen.
Es führt ja kein Weg an einem Umbau der Sicherheitskonzepte vorbei oder.
Wie dass sinnvoll geht wurde schon gesagt: die „geheimen Daten“ dürfen niemals den Server verlassen und auf dem Client-Rechner landen. Wie man das in deinem Fall löst kann dir niemand sagen, ohne zu wissen, was du eigentlich genau machen willst.
Was meinst du damit.
Auf jedem Clientserver ist eine eigene Datenbank.
Momentan übersende ich die SQLs mit einem Code, und diese werden nur im PHP verarbeitet wenn dieser stimmt.
Das allerdings kann dann ja auch so nicht bleiben.
Wo läuft welche Instanz, welche Instanz kommunziert über welchen Weg mit welcher anderen Instanz und welche Passwörter darf wer wissen. Da reichen 3 Kästen mit Pfeilen nicht.
Du brauchst minimum:
1 Kasten für:
* DB
* Header
* Client
* Server
* SFTP Server
Für jeden Kasten musst du beschreiben:
* Wo läuft der? Unter welcher Hoheit, wer "administriert" diesen? In welchem Netzwerk steht der
Die Verbindungen müssen dann exakt notwendigen Zugriffen entsprechen.
Für jede der Verbindung muss klar sein, wer authentifiziert sie. Und wer darf die Passwörter kennen?
Die Kästen sind gehostete Server.
Auf die Clientserver greifen die User zu und zwar immer geschlossene Gruppen.
Ich sehe ein das Bild ist äußert missverständlich.
Die Clientserver sind Schulen, auf diese greifen die Schüler und Lehrer zu.
Der Headerserver ist für den Datentausch zwischen den Schulen.
Ich denke jetzt ist es klar was ich bezwecke.
Ich möchte Konzepte wie Loadbalance und verteilte Datenbanken vermeiden
und die Daten der einzelnen Schule immer auf einem Server behalten
ohne auf einen gewissen Austausch zwischen den Schulen zu verzichten.
Klarer ja, aber nicht besser. Du brauchst wirklich das vollständige Bild aufgeschrieben und konzeptioniert. Und ja, das wird vielleicht mal 1-2 Stunden Kosten das sauber aufzuschreiben.
Mir ist nicht immer noch nicht klar, warum da Passwort für irgendwelche DBs auf den Client gehört. Warum muss der Server das Passwort vom Client bekommen? Warum kann er es nicht vom Header-Server bekommen oder direkt kennen? Das ist keinen Deut klarer geworden.
Ich scheue auf keinen Fall die zwei Stunden Arbeit, aber ich weiß nicht wie ich es darstellen soll.
Momentan bekommen die Clients einen verschlüsselten String vom Headerserver,
welcher auf dem Client zur Laufzeit aufgelöst wird.
Mit diesen Daten wird dann entsprechend auf die Server zugegriffen.
Also ein ClientPC bekommt die Zugriffdaten für seinen ClientServer und den HeaderServer.
Aber das ist ja das falsche Konzept.
Ich weiß aber nicht was Ihr vorhabt. Es ist ja nicht so das ssh mit Public und Private Key nicht kennen würde,
musste ich ja auf den Server für https verwenden, ich weiß nur überhaupt nicht wie ich das
für meinen Fall nutzen könnte um meine Probleme zu lösen.
Momentan bin ich an dem Punkt das ich vom Client PC den Zugriff auf den Client Server per PublicKey mache.
Dann bin ich im UserAccount und kann auf die PHP Scripts zugreifen.
Das wäre dann der einzige Schlüssel beim Client.
Mit dem Schlüssel könnte ich auch per SFPT Dateien vom ClientServer auf den ClientPC laden und speichern.
Der DBZugriff auf den HeaderServer würde vom ClientServer aus passieren.
Wieder mit einem SSH PublicKey auf den UserAccount des Headerservers.
Der Weg wäre dann ClientPC aktiviert ein PHP Script auf dem ClientServer.
In diesem Script wird ein https Connect auf den HeaderServer ausgeführt und das Ergebnis über den
ClientServer an den ClientPC zurückgegeben.
Das kann ich mir noch vorstellen.
Was ich mir aber überhaupt nicht vorstellen kann ist wie ich Dateien vom ClientPc über den ClientServer vom HeaderServer
laden kann und umgekehrt.
Aber bevor ich mich weiter versteige will ich erst mal warten ob das schon alles Unsinn ist.
nein... dein Client frägt bei einem server an ob er das ergebnis der DB anfrage theoretisch haben darf... der server entscheidet dann ob derjenige das haben darf und der startet das dann.. dem client hat es nichts anzugehen wie dein backend aufgebaut ist
Ich weiß nicht was Du meinst.
Am Ende brauche ich für die Abfrage auf die DB ein PHP Script.
Und diese wollte ich das User Verzeichnis auf dem Server legen.
Aus diesem Grunde muss ich mich doch erst mal auf dem Server anmelden.
Zielst Du auf die Berechtigungen des PHP Scripts auf dem Server ab ?
ich lasse mir das Login von laravel mit breeze managen... da sowas "sicher" selber zu bauen erstens schwer ist , und man muss immer darauf achten dass es auch wirklich sicher abläuft
mit der Begründung => die die ein login system zustande bringen werden schon ne ahnung davon haben
EDIT: zusätzlich ist sicherheit nich mein spezial gebiet... um gottes willen... was ich "gemacht" habe hat nicht wirklich viel bedeutung
was halt wichtig ist ist single source of truth dh alles was vom client kommt ist erstmal schwachsinn und nur dein server erkennt obs sinn ergibt oder nicht