nicht angemeldet
Hi,
Umfeld: Server bei Provider mit MYSQL, Perl, PHP, Linux, Apache. Als Protokoll geht leider nur http.
Ansatz:
Client: JavaApplet
Server: PHP-Skript
Du meinst Apache mit einem PHP-Skript.
DB dahinter: MYSQL
Auf dem rechner Lokal?
Ist der MYSQL-Server und die Datenbank daraus gegen draussen abgeschotten und erlaubt nur Zugriff vom Webserver?
Bist du sicher, dass wirklich nur Port 80 offen ist?
Applet bekommt Usereingabe
- Verschlüsselung mit Blowfish
- Umwandeln in Base64 (nur zwecks einfacherem Handling wegen NULL)
- Übertragung zum Server
- Speicherung in DB
Könnte man so machen...
Umgekehrt beim Lesen wird Base64 dekodiert und dann wieder mit Blowfish entschlüsselt (alles im lokalen Applet).
Tabelle sieht dabei so aus:
ID (integer)
data (mediumtext)
Was hat die Table damit zu tun?
ich denke, das PHP-Skript decodiert und wandelt dann die Eingaberequests in entsprechende Abfragen an die datenbank um, die dann aber natürlich ganz anders aussehen können.
Somit bin ich sicher vor dem lokalen Browser-Cache und die Leitung ist auch sicher und selbst wenn jemand an die DB rankommen sollte kann er die Daten zwar zerstören aber nicht lesen. Es bleibt aber ein Problem:
Auf dem Server gibt es logischerweise ein öffentliches PHP-Skript mit folgenden Funktionen:
-gib größte ID (wäre mir egal)
wieso?
-gib alle Records (wäre mir egal, kann ja keiner was mit anfangen)
wieso?
-füge neuen Record an (passt mir schon nicht mehr so da dies ja Schrottdaten wären)
urg
-lösche Record mit ID (passt mir überhaupt nicht)
Warum kann dein PHP-Skript dies alles?
Einfach wäre natürlich das PHP-Skript per .htaccess zu schützen dann muss das Applet sich anmelden aber das ist natürlich wieder "unsecure" wegen dem cleartext Passwort das über die Leitung geht.
Du machst doch schon eine Verschluesselung.
Warum machst du dann nicht auch damit eine Identifizierung des Clients?
Du kannst entweder der Clientsoftware eine zeitabhaengige Identifation mitgeben, die eine Checksumme aus einen Private/Public-key verfahren nutzt.
Ausserdem kannst du natuerlich auch eine Usereingabe fordern.
Alternativ hätte ich noch die Idee:
- ein Client sagt zum Server erstmal HELLO
- der Server schickt eine zufällige Zeichenkette zurück und speichert sich diese mit der Session-ID in einer DB
- der Client wird diese Zeichenfolge dann mit einem Kennwort verschlüsseln (Blowfish) und zurückschicken
- Der Server führt auf seine Zeichenfolge die gleiche Verschlüsselung durch und bei Übereinstimmung wird der DB-Eintrag als "VALID" gekennzeichnet und in der DB mit einem Timestamp versehen. Bei jedem Aufruf wird dann geprüft ob die Session-ID mit einer VALID Session übereinstimmt und ob die Zeit vom letzten Zugriff nicht länger als x Minuten her ist. Falls ok wird der aktuelle Timestamp reingeschrieben. Falls nicht ok liefert das Skript nur eine Fehlermeldung als Response zurück.
Klar, kann man machen.
Aber das waere nur die eine Seite.
Du willst doch den Zugriff auf relevante Daten unterbinden.
Und nicht nur einfach die Verschluessung/Decodierung der Übertragung erschweren!
Anmerkungen? Denkfehler? Verbesserung?
Jede Kritik und jeder Verbesserungsvorschlag sind gerne willkommen.
1. Ueberleg dir ein Rollenkonzept für die Datenbank:
Lege verschiedene User an, dieauch nur verschiedene Aktionen auf
Tables machen dürfen.
Hierbei wäre auch die Überlegung angebracht ob du nicht besser
eine professionelle datenbank anstelle von MYSQL nutzt. Zum
Beispiel Firebird.
Jeder Client kann z.B. eine Userkennung haben, die übermittelt und
genutzt wird.
2. Ueberleg dir, ob die Serverkonfiguration sicher ist.
Gerade PHP ist in letzter zeit wegen Sicherheitslücken aufgefallen.
Siehe BUGTRAQ.
Ein Konzept wäre:
Client ----> Firewall -> Apache-Server -> Datenbankserver
Kostet zwar mehr, aber wenn es z.B. um schützenswerte Personendaten
handelt, wäre sowas wichtig.
Dir kann naemlich passieren, dass jemand aufgrund eines Fehlers in
ein PHP-Skript oder in PHP selbst, einfach auf den Server
reinkommt. Der kann dann alles mitverfolgen.
3. Dein Verfahren zur Austausch von Daten sollte Zeitabhaengig sein.
D.h. eine Session-ID sollte nru eine bestimmte Zeit lang gültig
sein.
4. Dein PHP-Skript tut nur dann was, wenn es eine korrekte
Identifizierung des Gegenuebers hat. Auf keinen fall soll es
irgendwelche daten rausgeben oder IDs, wenn es nicht weiss an
wem.
Ciao,
Wolfgang