Christoph Zurnieden: User und Pw in JDBC->Sicherheitsrisiko?

Beitrag lesen

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