Mal ein paar grundsätzliche Dinge, damit du überhaupt eine Vorstellung davon bekommst, worum es in Bezug auf Netzwerksicherheit und dein Quiz geht:
Wann immer du eine Architektur schaffst, an der potentiell zwei Rechner beteiligt sind, brauchst du dafür auch mindestens zwei laufende Programme: eines auf dem einen Rechner und ein weiteres auf dem anderen.
Wenn du dein Quiz testen möchtest, sind nach den aktuellen Umständen zwei Rechner beteiligt: [c]localhost[/c] (das ist der generische Name für den eigenen Rechner aus Sicht dieses Rechners, aus deiner Perspektive also dein Rechner) und [c]www.javaquiz.de.to[/c]. Auf beiden Rechnern muss jeweils mindestens ein Programm laufen, damit dein Quiz funktionieren kann.
Nun ist es so, dass offensichtlich die beiden Programme unterschiedliche Dinge leisten müssen: Das eine Programm läuft auf [c]www.javaquiz.de.to[/c], es hält die Fragen für die Clients bereit, die am Quiz teilnehmen möchten. Es bietet also einen Dienst an (nämlich einen Quizfragen-Verwaltungsdienst) und wird deswegen
Server genannt. Auf dem anderen Rechner, [c]localhost[/c], läuft das Programm, das u.a. die Fragen von eben beschriebenem Server abholt, um sie dem Anwender zu präsentieren. Dieses Programm nimmt den vom Server angebotenen Dienst in Anspruch und wird deshalb
Client genannt.
Eine Architektur, die auf die beschriebene Art und Weise zwei unterschiedliche Programme (Server und Client) verknüpft, heißt Server-Client-Architektur. (Diese ist abzugrenzen von z.B. Peer-to-Peer-Netzen, wo jeder Teilnehmer gleichzeitig Server und Client ist. Aber das nur am Rande.)
Im Gegensatz zu den Clients muss der Server rund um die Uhr laufen, wenn eben rund um die Uhr Teinehmern der entsprechende Dienst (in unserem Fall ja der Quizfragen-Verwaltungsdienst) angeboten werden soll. Dieser Umstand ist unabhängig davon, um welchen konkreten Dienst es sich handelt, da er nur von der Zeit abhängt. Da du wahrscheinlich nicht jeden Tag zu [c]www.javaquiz.de.to[/c] läufst, um ihn hochzufahren, ist davon auszugehen, dass auch der Quizfragen-Verwaltungsdienst rund um die Uhr laufen wird.
In deiner bisherigen Umsetzung verwendest du ebenfalls eine Server-Client-Architektur. Allerdings benutzt du als Server kein speziell für dein Problem abgestimmtes Programm, sondern einen FTP-Server. Dieser Server läuft auch rund um die Uhr, du kannst dich selbst davon überzeugen, indem du in deinem Browser [c]ftp:
www.javaquiz.de.to[/c] aufrufst. In diesem Fall fungiert dein Browser (z.B. Firefox) als Client, genauer gesagt als FTP-Client.
Nun wieder etwas allgemeiner: Server und Client tauschen Nachrichten aus, um miteinander zu kommunizieren. Wie diese Nachrichten aussehen müssen, also welche Bytefolgen was zu bedeuten haben, regelt eine Vereinbarung zwischen beiden Teilnehmern, das so genannte
Protokoll. Davon kennst du auch sicherlich einige, zumindest vom Namen her, z.B. Hypertext Transfer Protocol (HTTP) und File Transfer Protocol (FTP). (Auf anderer Ebene gibt es bspw. noch das Transmission Control Protocol (TCP) und das Internet Protocol (IP). Aber auch das sei wieder nur am Rande erwähnt.)
Wie lässt sich nun dein Problem mit der bisherigen Architektur einordnen? Du hast bisher FTP benutzt. FTP ist zum Hoch- und Runterladen von Dateien gedacht. (Hochladen heißt, das Ziel der Datenübertragung ist der Server. Beim Herunterladen ist das Ziel der Client.) Dein FTP-Server verlangt die Eingabe eines Nutzernamens und eines Passworts. Nutzername und Passwort werden aber, wie im Protokoll spezifiziert ist (also vollkommen regelkonform!) unverschlüsselt(!) übertragen.
Das heißt ganz konkret, dass jedes Gerät zwischen deinem Client auf [c]localhost[/c] und dem Server auf [c]www.javaquiz.de.to[/c] die Login-Daten mitlesen kann. Befindest du dich z.B. in einem W-LAN, können alle, die dieses W-LAN nutzen, deine Login-Daten abfangen! Jeder, der sich mit diesen Nutzerdaten einloggt, könnte dann Unsinn anstellen (z.B. [c]www.javaquiz.de.to[/c] zum Verbreiten von Dateien fragwürdigen Inhalts oder Herkunft nutzen).
Was also kannst du machen, um diese eklatante Sicherheitslücke zu schließen?
Eine Möglichkeit wäre, den FTP-Server ohne Login nutzbar zu machen. Das würde zwar das Übertragen von Login-Daten verhindern, löst aber das gerade geschilderte Problem nicht.
Wesentlich besser wäre die Möglichkeit, anstatt beliebiger Dateien beliebigen Inhalts nur noch Quizfragen und ihre Antworten zu akzeptieren. Dann kannst du aber so FTP nicht mehr verwenden, sondern musst (zusätzlich) ein eigenes Protokoll entwerfen.
Ein Ansatz dazu wurde schon genannt: Du kannst z.B. einen PHP-Server verwenden. PHP ist eine Skriptsprache, und die in dieser Sprache geschriebenen "Programme" (Skripte) werden auf dem Server ausgeführt. Die Übertragung der Daten geschieht dann für gewöhnlich über einen HTTP-Server (z.B. Apache). Das ist auch hier bei diesem Forum der Fall.
Was musst du nun programmieren, wenn du z.B. mittels PHP (oder irgendeiner anderen Sprache) einen entsprechenden Quizfragen-Verwaltungsdienst zur Verfügung stellen möchtest?
Nun, du müsstest z.B. dafür sorgen, dass richtige Fragen von Unsinn (z.B. zufälligen Bytefolgen) unterschieden werden. Hast du dir überlegt, wie du das anstellen möchtest? Diese Frage steht übrigens unabhängig davon, ob du PHP oder Java verwendest, und ist zentral für die richtige Implementierung deines Quizdaten-Übertragungsprotokolls (das du dazu natürlich schon vorher entworfen haben musst). Hierbei geht es nämlich weniger darum, dass die Clients vernünftige Fragen präsentiert bekommmen, sondern vielmehr darum, dass dein Quizfragen-Server (<-- stell dir hier z.B. deine PHP-Skripte vor) nicht kompromittiert und letztendlich zweckentfremdet wird (denk an das Fragwürdige-Dateien-Problem von oben!). Potentiellen Angriffen ist der Server immerhin rund um die Uhr ausgesetzt.
Wie du nun hoffentlich siehst, kann man nicht "mal eben" im Internet einen Dienst anbieten. Bis dahin gibt es nämlich viele Fragen zu klären und viele Dinge zu beachten. Gerade in der Serverprogrammierung kann jeder noch so kleine Fehler verheerende Folgen haben, und solche Stolperfallen gibt es viele, sehr viele.
Ark