nicht angemeldet
User und Pw in JDBC->Sicherheitsrisiko?
Ich beschäftige mich gerade mit JDBC, weil es darum geht, einen JAVA-Chat so umzuschreiben, dass er User-Accounts aus einer MySQL-Db auslesen kann um so nur registrierten Mitgliedern eines bestimmten Boards Zugang zu gewähren und eine zusätzliche Registrierung unnötig zu machen.
Nun müssen aber in dem entprechenden Applet auch Username und Passwort für die MySQL-DB angegeben werden.
Dann könnte doch aber auch ein weniger gut gesinnter User die .class-Datei runterladen, decomplimieren und so Username und Passwort erhalten.
Gibt es eine Möglichkeit dem vorzubeugen?
Danke im Voraus!
euer Rabe
-
Hi,
Nun müssen aber in dem entprechenden Applet auch Username und Passwort für die MySQL-DB angegeben werden.
Dann könnte doch aber auch ein weniger gut gesinnter User die .class-Datei runterladen, decomplimieren und so Username und Passwort erhalten.
Gibt es eine Möglichkeit dem vorzubeugen?Ja, einfach die Passwörter (am besten auch die Usernamen) vorher mit einem Einwegschlüssel (MD5, RMD160 o.ä.) verschlüsseln. Die vergleichst Du dann. MD5 ist meines Wissens im Standardjava enthalten.
so short
Christoph Zurnieden
-
Hallo,
Nun müssen aber in dem entprechenden Applet auch Username und Passwort für die MySQL-DB angegeben werden.
Dann könnte doch aber auch ein weniger gut gesinnter User die .class-Datei runterladen, decomplimieren und so Username und Passwort erhalten.
Gibt es eine Möglichkeit dem vorzubeugen?Ja, einfach die Passwörter (am besten auch die Usernamen) vorher mit einem Einwegschlüssel (MD5, RMD160 o.ä.) verschlüsseln. Die vergleichst Du dann. MD5 ist meines Wissens im Standardjava enthalten.
Ich hatte den Fragesteller so verstanden, daß er über das Applet auf
die Datenbank zugreifen möchte, ohne daß der Benutzer vorher das Passwort
dafür eingeben muß. (Sonst könnte er ja gleich die Autentifizierung
der Datenbank verwenden, und bräuchte noch zusätzlich eine solche
Zugangsbeschränkung im Applet.)Die Zugangsdaten _für die Datenbank_ müssten also im Applet stehen.
Gruß
Slyh-
Gibt es wirklich nicht IRGENDEINE Möglichkeit das zum umgehen?
Dann wäre doch die ganze Geschichte rund um JDBC ein einziges Sicherheitsproblem.mfg,
Raban-
Hi,
Gibt es wirklich nicht IRGENDEINE Möglichkeit das zum umgehen?
Nein, wie möchtest Du das denn sonst machen?
Dann wäre doch die ganze Geschichte rund um JDBC ein einziges Sicherheitsproblem.
Führe mich nicht in Versuchung über JAVA zu lästern! ;-)
Nein, ist es nicht. Wenn Du das denkst, solltest Du Dein Sicherheits_konzept_ einmal überdenken. _Das_ stimmt dann nämlich nicht.
so short
Christoph Zurnieden
-
Mit "irgendeiner Möglichkeit" meinte ich nicht nur in Java sondern generell. Also auch "mein"(ich hab das so nicht konstruiert, bin zwar in dem Forum SuperModerator, aber das war's dann auch) Sicherheitskonzept. An sich ist das Konzept gut. Das Board arbeitet mit SSL-Verschlüsselung, die Userdaten sind eben in einer MySQL-Tabelle gespeichert.
Sieht dann wohl so aus, als müsste da etwas anderes als Java her(jsp geht auf dem server nicht)...
Oder gibt es irgendwelche Möglichkeiten, diese Daten in irgendeiner Form "auszulagern"(z.B. nach Php? Wie sieht das mit der Kommunikation von Java und Php aus?)mfg,
Raban W.-
Hi,
Mit "irgendeiner Möglichkeit" meinte ich nicht nur in Java sondern generell.
Ah!
Na, das läßt einem doch deutlich mehr Möglichkeiten offen ;-)Also auch "mein"(ich hab das so nicht konstruiert, bin zwar in dem Forum SuperModerator, aber das war's dann auch) Sicherheitskonzept. An sich ist das Konzept gut. Das Board arbeitet mit SSL-Verschlüsselung,
Die Güte der Kryptographie sagt nichts, aber auch rein gar nichts über die Gesamtsicherheit aus.
Aber das nur am Rande.
die Userdaten sind eben in einer MySQL-Tabelle gespeichert.
Ah, dann doch wie der Kollege Slyh vermutete.
Und wie ich, dann stimmt nämlich Dein Konzept nicht.Oder gibt es irgendwelche Möglichkeiten, diese Daten in irgendeiner Form "auszulagern"(z.B. nach Php? Wie sieht das mit der Kommunikation von Java und Php aus?)
Du kannst also etwas mit PHP machen? Dann geht's auch. Die Datenbankzugriffe bleiben om Client weg, wenn Du sie über PHP bewerkstelligst. Also einfach Dein Javaapplet Username und Password MD5'en lassen und damit dann das PHP Skript füttern. Wenn Du keine MD5 für Java findest: es ist eins im GCC (in 3.4.1 habe ich es gerade gefunden, war bestimmt auch schon lange vorher drin) Wenn Dir das zuviel Holz ist (Du evt hinter einem Modem steckst, dsa sind fast 30 MiB!) kann ich es Dir schicken.
so short
Christoph Zurnieden
-
Die Güte der Kryptographie sagt nichts, aber auch rein gar nichts über die Gesamtsicherheit aus.
Das könnte ich zwar widerlegen, aber das gehört hier ja nun nicht wirklich her(wenn dann per e-mail ;)).
Wie läuft das dann ganz konkret, so dass Php an Java weitergibt,
ob der User zugangsberechtigung hat, bzw. welcher Username zu dieser Session-Id gehört?mfg,
Raban W.-
Hi,
Die Güte der Kryptographie sagt nichts, aber auch rein gar nichts über die Gesamtsicherheit aus.
Das könnte ich zwar widerlegen, aber das gehört hier ja nun nicht wirklich her(wenn dann per e-mail ;)).Paßte nicht auf den Rand dieser Seite, was? ;-)
Nein, wenn Du das könntest, dann hätten wir alle ein schweres Problem.
Folgendes sind zwei verschiedene Dinge, ich erlaube mir mal ein Trennung.
Wie läuft das dann ganz konkret, so dass Php an Java weitergibt,
ob der User zugangsberechtigung hat,Du hast:
- eine DB PWDB, die das Pärchen MD5Sum(Passwort),MD5Sum(Username)
enhält - ein PHP-Script SCRIPT, das als Mittler zwischen Client-Javaapp
CJAVA_APP und PWDB dient - CJAVA_APP, das die Kommunikation mit dem SCRIPT führt
Du arbeitest dann wie folgt.
- CJAVA_APP fragt nach Username und Passwort, verschlüsselt das mit
MD5 und schickt es an SCRIPT. - SCRIPT schickt Anfrage an PWDB ob MD5Sum(Passwort) zu
MD5Sum(Username) passt. - SCRIPT schickt Antwort an CJAVA_APP
- CJAVA_APP handelt entsprechend der Antwort.
bzw. welcher Username zu dieser Session-Id gehört?
Da verstehe ich den Sinn nicht ganz, aber gut, vielleicht können ja irgendwelche Einträge Ärger machen, wenn sie doppelt vorhanden sind.
- die Session-ID geht als Argument beim Aufruf von CJAVA_APP an
CJAVA_APP.
so short
Christoph Zurnieden
-
Danke für deine Mühe!
In der Theorie ist das ja alles so klar(wobei der user ja nicht wirklich verschlüsselt werden muss-man kann's auch übertreiben!).
Aber wie geht das GANZ KONKRET. Über welche Befehle läuft das ab, etc...
Wenn ich einen enstprechenden Links hätte, würde mir das schon weiterhelfen.greetings,
Raban W.-
Hi,
Danke für deine Mühe!
In der Theorie ist das ja alles so klarEs freut mich doch stets, wenn ich behilflich sein konnte.
»»(wobei der user ja nicht wirklich verschlüsselt werden muss-man kann's auch übertreiben!).
Ja, es reicht, wenn eines aus dem Pärchen Username/Paßwort verschlüsselt wird, das stimmt wohl.
Aber ich dachte mir: wenn man eh schon einmal dabei ist ... ;-)Aber wie geht das GANZ KONKRET. Über welche Befehle läuft das ab, etc...
Gut, ich kann Dir den Code auch schreiben, aber das wird dann _richtig_ teuer, so um die 15.000 EUR müßtest Du da schon anlegen ;-)
Wenn ich einen enstprechenden Links hätte, würde mir das schon weiterhelfen.
Puh, nein, da weiß ich nichts, da mußt Du Dich schon durch die Doku wühlen. Ist aber einfach, da DB-Anbindung bei PHP Gang und Gäbe ist und Sockets bei Java auch gut beschrieben sind.
Ist eigentlich fast schon Baukastenprinzip, dürfte nicht schwierig werden.
Bei Schwierigkeiten einfach hier wieder melden.so short
Christoph Zurnieden
-
Ich fühle mich schon sehr unverstanden.
Ich weiß einfach nur nicht wie DIE KOMMUNIKATION ganz konkret geht.
Der Rest ist klar.greetings,
Raban W.-
Hi,
Ich fühle mich schon sehr unverstanden.
Ja, dsa Gefühl kenn' ich ;-)
Ich weiß einfach nur nicht wie DIE KOMMUNIKATION ganz konkret geht.
Gaaaanz einfach:
CJAVAAPP:
GET /ich_check_das_Passwort.php?user=karlotto&pass=2D11C3FA0B00A5F726F869CF747657DE HTTP/1.1
Host: example.com
CRLF
CRLFIn ich_check_das_Passwort.php dann der normale Ablauf, Rückgabe per echo o.ä. primitives, Du brauchst ja mehr oder weniger nur true/false
Der Rest ist klar.
Das jetzt auch?
Besonders sicher ist das übrigens nicht, möcht' ich nur am Rande einmal erwähnt haben (m.i.t.m Attacke). Ganz nackt darfst Du das also nicht betreiben, Du brauchst schon noch einen "normalen" Schlüsseltausch oder noch besser SSL,
so short
Christoph Zurnieden
-
Hmm, den Umweg Java->Php->Java kann ich mir ja eigentich sparen.
Der Link aus dem Forum heraus wird also auf eine Html-Seite mit inline-php verweisen. Also der Php-Part zwischen <applet> und </applet>. Der erzeugt dann als ausgabe einen ParamTag und übergibt damit, falls der Benutzer die entsprechende Berechtigung erhält, den Username. SSL benutzt das Forum, wie gesagt, ja eh schon.
Aber eigentlich sollen mit dieser ganzen Sache zwei Dinge erreicht werden:
1)Keine Extra-Anmeldung(schon für das Forum erfolgt)
2)Man kann sich den Benutzernamen nicht raussuchen, sondern muss den aus dem Forum beibehalten.Jetzt könnte aber ein findiger Forumsbenutzer auf die Idee kommen, sich das Applet herunterzuladen und ihm in einer selbstgenerierten Html-Seite beliebiege Parameter zu übergeben. Somit wäre 2) ausgehebelt. Gebe es da noch eine Gegenmöglichkeit?
mfg,
Raban W.-
Hi,
Hmm, den Umweg Java->Php->Java kann ich mir ja eigentich sparen.
Der Link aus dem Forum heraus wird also auf eine Html-Seite mit inline-php verweisen. Also der Php-Part zwischen <applet> und </applet>. Der erzeugt dann als ausgabe einen ParamTag und übergibt damit, falls der Benutzer die entsprechende Berechtigung erhält, den Username.Aha, so weit, so gut. Der kann dann angeboten werden.
SSL benutzt das Forum, wie gesagt, ja eh schon.
Dein Applet auch?
Aber SSL ist ja auch nur eine Transportsicherung damit keiner lauschen kann. Du kannst Dir also das Hashing sparen.Aber eigentlich sollen mit dieser ganzen Sache zwei Dinge erreicht werden:
1)Keine Extra-Anmeldung(schon für das Forum erfolgt)
2)Man kann sich den Benutzernamen nicht raussuchen, sondern muss den aus dem Forum beibehalten.Wenn Du dann hier Schwierigkeiten hast, heißt das doch, das auch das Forum nicht richtig funktioniert?
Aber gut, darum geht es ja nicht.Jetzt könnte aber ein findiger Forumsbenutzer auf die Idee kommen, sich das Applet herunterzuladen und ihm in einer selbstgenerierten Html-Seite beliebiege Parameter zu übergeben. Somit wäre 2) ausgehebelt. Gebe es da noch eine Gegenmöglichkeit?
Ja, aber jetzt wird's ein wenig kompliziert. Aber wirklcih nur wenig:
Du mußt nämlich einen kryptographischen Hash aus den Informationen Username und Serverschlüssel basteln. Dann kann der übergebene Parameter nicht wirksam geändert werden.Gut, der Reihe nach:
Es gibt eine Link im Forum, der verweist auf eine Seite, die einen Link zu einem Applet anbietet, das wiederum ein Chat anbeitet.
Der User hat sich mit Username und Paßwort eingeloggt und soll unter seinem Username Siteweit bekannt sein und _nur_ darunter. So auch im Chat.
Die Seite mit dem Chat-Applet wird per PHP generiert.
Username/Passwort und sonstiges Zubehör wird in einer DB zentral gehalten.
Das Chat-generierende PHP-Script baut nun aus dem Username und einem Serverkey einen Schlüssel, der als Parameter zum Appletaufruf gegeben wird. Der Server kann nun aus diesem Schlüssel den Usernamen generieren, aber der User hat mit Änderungen am Wert wenig Erfolgsaussichten.
Der Serverkey kann - da PHP - günstig als Sessionkey generiert werden. Verschlüsselung kann dann XOR sein. (Länge des Key muß _gleich_ der Länge des Usernamen sein!)
Auch das kann natürlich umgangen werden, ist aber dann nur mit recht hohem Aufwand möglich. Wenn Du mehr willst, mußt Du wirklich ausgewachsene kryptograpische Methoden anwenden.
so short
Christoph Zurnieden
-
Nur, dass ich das jetzt richtig verstanden habe:
-Link aus dem Forum auf die Seite mit inline-Php(session-id wird übergeben)
-Php holt sich aus der Db den zur Session-ID zugehörigen Usernamen
-Verschlüsselt den Username mit Session-ID als Key
-Übergibt Session-Id und verschlüsselten Usernamen per automatisch generierten <param>-Tags an Java
-Java entschlüsselt den Username
...Stimmt das alles soweit?
Natürlich könnte man jetzt immer noch:
-den Quelltext dekomplimieren.
-Dann entsprechend einen beliebigen Key zum verschlüsseln wählen.
-Diesen und den damit verschlüsselten Username über eine veränderte Html-Datei dem Programm übergeben.Gegenmaßnahme: Java überprüft Ip[möglich?-wenn ja: wie?]
Jetzt bliebe natürlich noch das umschreiben des Quellcodes.
Aber den Aufwand wird wohl kaum jemand betreiben.mfg,
Raban-
Hi,
Nur, dass ich das jetzt richtig verstanden habe:
-Link aus dem Forum auf die Seite mit inline-Php(session-id wird übergeben)Ja, ganz normal, wie sonst in Deinem Forum auch.
-Php holt sich aus der Db den zur Session-ID zugehörigen Usernamen
Ganz genau.
-Verschlüsselt den Username mit Session-ID als Key
Nein!
Beidesist öffentlich, Du mußt schon irgendeinen privaten Key auf der Serverseite nehmen. Entwerder eine festen, aebr das brauchst Du ja nicht, Du kannst ja einfach einen Sessionkey generieren lassen. Daher kam wahrscheinlich auch Dein Irrtum.Dus hast also die ursprünlgiche SessionID.
Damit bekommst Du den Usernamen raus, der daran hängt.
Aus einem privatem Schlüssel auf Serverseite und dem Usernamen/SessionID generierst Du einen Key. Dadurch kann der Client die SessionID nicht ändern ohne das es auffällt. Das Javaapplet generiert den Usernamen zur Runtime, ist also auch nicht ohne großen Aufwand angreifbar.-Übergibt Session-Id und verschlüsselten Usernamen per automatisch generierten <param>-Tags an Java
Ja.
-Java entschlüsselt den Username
Nein. Dein Javaapplet macht gar nichts damit.
Stimmt das alles soweit?
Natürlich könnte man jetzt immer noch:
-den Quelltext dekomplimieren.Nützt nichts, da zur Runtime generiert.
-Dann entsprechend einen beliebigen Key zum verschlüsseln wählen.
Nützt nichts, da das gesamte nicht mehr stimmen würde.
-Diesen und den damit verschlüsselten Username über eine veränderte Html-Datei dem Programm übergeben.
Würde alles fehlschlagen.
Gegenmaßnahme: Java überprüft Ip[möglich?-wenn ja: wie?]
Der Client macht gar nichts, da Du auf die Clientseite keien EInfluß hast, alles geschieht auf der Serverseite.
Jetzt bliebe natürlich noch das umschreiben des Quellcodes.
Funktioniert nicht, da aus Serverkey und Clientkey gemeinsam gernerierter Code herauskomemnmuß, Manipulatzion ist so nicht möglich.
Aber den Aufwand wird wohl kaum jemand betreiben.
Das wäre kein Aufwand, aber Du spielst auf etwas sehr wichtiges an: die Frage, ob der Preis den Aufwand rechtfertigt.
Du arbeitest ja schon im Forum nur mit SessionIDs, die kann jeder, der möchte ändern. Ist das System vernünftig implementiert ist die Wahrscheinlichkeit, das die Änderung Sinn macht sehr gering. Damit arbeitest Du dann auch in Deinem Chat: Du gehst davon aus, das an der SessionID nicht manipuliert wurde. Ein guter Chat macht nun nichts anderes, als seinen Text an den _Server_ zu senden, der wiederum dann den Broadcast verschickt. Da kannst Du dann einsetzen:
SessionID(User) kommt vom Forum und möchte den Chat haben.
Der Server erzeugt zwei Schlüssel: eine für sich selber und einen öffentlichen Schlüssel. Den öffentlichen Schlüssel bekommt das Javaapplet und verschlüsselt damit und mit der SessionID(Username) den Usernamen. Der Server kann so kontrollieren, ob der Username zu SessionID(Username) gehört.
Manipulationen können so erkannt werden.
Da die Verschlüsselung Rechenzeit kostet wäre XOR zu empfehlen. Dafür muß aber der Schlüssel ausreichend zufällig sein. Deswegen schlug ich SessionIDs vor.Solltest Du da nicht hintersteigen sag' Bescheid.
so short
Christoph Zurnieden
-
-
-
-
-
-
-
- eine DB PWDB, die das Pärchen MD5Sum(Passwort),MD5Sum(Username)
-
-
-
-
-
-
Hi,
Ich hatte den Fragesteller so verstanden, daß er über das Applet auf
die Datenbank zugreifen möchte, ohne daß der Benutzer vorher das Passwort
dafür eingeben muß. (Sonst könnte er ja gleich die Autentifizierung
der Datenbank verwenden, und bräuchte noch zusätzlich eine solche
Zugangsbeschränkung im Applet.)Wäre dann ein _sehr_ merkwürdiges Sicherheitskonzept, das glaube ich nicht.
Die Zugangsdaten _für die Datenbank_ müssten also im Applet stehen.
Die haben beim Client _gar_ nichts zu suchen. Der darf da nämlich nicht direkt drauf zugreifen, nur über Dritte. Ist das nicht so, ist das eine Sicherheitslücke.
so short
Christoph Zurnieden
-
-
-
Moin!
Ich hab jetzt nicht den ganzen Thread gelesen, kann also sein, jemand anders hat es schon geschrieben.
Das Problem ist recht einfach, wenn man verschiedenes weis:[!] Ich gehe davon aus, Du meinst ein Java- Programm, welches auf dem Server läuft, also sowas wie JSP oder ein servlet aber kein applet.
Java hat sicher eine Möglichkeit Programmeinstellungen aus Dateien zu lesen. (Das weiss ich nicht, ich kann kein Java, aber jede brauchbare Programmiersprache hat sowas.)
Das gibt folgende Möglichkeiten:
Du kannst eine solche Datei sicher außerhalb des/der vom Webserver bereitgehaltenen Verzeichnisse(s) unterbringen.
Ein Apache in der gegenwärtigen Standardkonfiguration wird sich beharrlich weigern Dateien die mit ".ht" beginnen auszuliefern. Du kannst die Datei also z.B. ".ht_dbzugangsdaten" nennen. Ist kein Problem, lege mal eine solche Datei an und versuche sie abzurufen.
Ist der Server ein IIS hats Du sicher auch möglichkeiten den Zugriff von aussen zu verhindern.MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Development. Auch für seriöse Agenturen.-
Hallo,
Ich hab jetzt nicht den ganzen Thread gelesen, kann also sein, jemand anders hat es schon geschrieben.
Das hättest du mal besser. Dann hättest du nämlich folgendes nicht
geschrieben:[!] Ich gehe davon aus, Du meinst ein Java- Programm, welches auf dem Server läuft, also sowas wie JSP oder ein servlet aber kein applet.
Deine Antwort war damit vollständig an der Frage vorbei.
Gruß
Slyh
-