nicht angemeldet
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