Client oder Server… das Hin und Her
Sep 11, 2012 | by J. Wagner | 0 Comments

Gerade blicke ich auf die Client-Server-Architekturen zurück, mit denen ich in meinen mehr als 25 Jahren als Software-Entwickler zu tun hatte. Dabei sehe ich vor meinem geistigen Auge so etwas wie ein Pendel, das zwischen Client und Server hin- und herschwingt.

Während meines Studiums in den 80er Jahren waren Mainframes/Hosts mit 3270er Terminals angesagt. Das Pendel hing also beim Server.

Als in den 90er Jahren die PCs dank Intel-486 immer leistungsfähiger wurden und durch sinkende Preise weite Verbreitung fanden, schwang das Pendel zur Client-Seite. Anwendungen wurden typischerweise als Fat-Clients gebaut.

Doch dann der Zoo genutzter Windows-Client-Plattformen zur Jahrtausendwende: 95, 98, ME, 2000, NT mit diversen Service-Packs. Die Client-Anwendungen waren sehr empfindlich… Stichwort DLL-Hölle. Das Pendel schwang wieder zurück zum Server, Web-Applikationen im Browser waren angesagt… bis die vielen Seitenladevorgänge wieder die Suche nach etwas Neuem anstießen.

Um also die Kommunikation zwischen Web-Applikation und Server zu optimieren, wurden Techniken wie Applets, Ajax u.a. eingesetzt, um doch wieder mehr Programmlogik auf dem Client auszuführen. Wieder schwang das Pendel… nun hängt es beim Client, so sehe ich den heutigen Stand.

Wo wird die Reise hingehen?

Ich denke, dass Sicherheitsaspekte das Pendel (…zumindest zum Teil) wieder zum Server zurückschicken werden.

Es ist zu einfach, auf dem Client laufende Applikationen zu untersuchen und zu verändern. Bei Ajax im InternetExplorer reicht bereits F12 („Entwicklertools“), um den gerade laufenden Javascript-Code zu debuggen und zur Laufzeit zu verändern; und für Firefox gibt es Firebug.

Signierte Java-Applets verändert einzusetzen ist zwar schwieriger, aber mit De-Compile und einem selbst kompilierten Bowser (mit abgeschalteten Sicherheitsmechanismen) auch möglich. (Bekannte gezielte Attacken wie Phishing, Cross-Site-Scripting u.ä. zum Stehlen von Logins/Sessions möchte ich hier nicht weiter betrachten.)

Mit den genannten Tools könnten Prüfungen und Verbote von Funktionsaufrufen umgangen werden. Daher sehe ich eine Notwendigkeit zur Verbesserung von Sicherheit in Anwendungen durch Mechanismen auf den Servern.

Dies ist z.B. beim Documentum Content Server der Fall, wo im Backend alle Ordner und Dokumente durch Zugriffsrechte geschützt und die Benutzer nur zugeordnete Privilegien/Funktionsrechte besitzen. Mit den o.g. Tricks könnten dann evtl. zwar Plausibilitätsprüfungen im Client umgangen werden, aber ein unberechtigter Zugriff auf geschützte Dokumente wird nicht möglich.

Greift die Client-Applikation aber auf einfache Datenbanktabellen ohne weitere Sicherungsmechanismen zu, so sind Tür und Tor weit geöffnet…

Einen möglichen Lösungsansatz zur Absicherung der Client-Server-Kommunikation sehe ich dann z.B. darin, dass die vom Server gelieferte Webseite die „Tokens“ für erlaubte Funktionsaufrufe enthält. Das können z.B. verschlüsselte Kombinationen aus Benutzerkennung, Zeitstempel, ObjektID und Funktionsname sein. Änderungen in den Eigenschaften eines Objektes werden an Server/Datenbank übermittelt, als Antwort gibt es neue Tokens entsprechend den nun erlaubten Funktionen. Damit wären manipulierte Funktionsaufrufe für den Server erkennbar.

Vielleicht wird es aber auch ganz andere Techniken für die Client-Programmierung geben, um gegen lokale Programmveränderungen zu schützen. Ich bin sehr gespannt, welche Frameworks sich für diese Aufgabe etablieren werden, welche Technik/Architektur sich durchsetzen und wo das Pendel in Zukunft hängen wird…

Nur ein Pendel, aber es bleibt spannend.