Die Sicherheit hinkt der Funktionalität hinterher

Bei Web-Services sind viele Sicherheitsfragen offen. Beispielsweise müssen erst noch spezielle Firewalls entwickelt werden. Außerdem ist die Authentifizierung der Server untereinander nicht ausgereift.

"Not described in this document." So lapidar handelt das Internet-Gremium W3C das Thema Security in der aktuellen Spezifikation seiner Web-Services-Norm Soap (Simple Object Access Protocol) ab. "Man hofft darauf, Sicherheitsfeatures im Nachhinein einbauen zu können, was zu erheblichen Problemen führen wird", ärgert sich Florian Weimer vom Sicherheitsteam RUS-Cert am Rechenzentrum der Universität Stuttgart. "Selbst wenn es bloß am Gefahrenbewusstsein der Anwender hapert, die sich fragen: Wieso absichern, es läuft doch auch so?"

Ein Kritikpunkt der Fachleute ist, dass das Datenaustauschprotokoll Soap extra so konstruiert wurde, dass es als HTTP-Verkehr getarnt unkontrolliert durch jede Firewall flutscht. "Da Soap auf HTTP als Transportmechanismus basiert und die meisten Firewalls HTTP einfach passieren lassen, werden Sie mit den Internet-Torwächtern keine Probleme mehr haben", rät Microsoft auf seiner Entwickler-Homepage. Daher wird Soap auch von einigen als "Firewall-friendly" gepriesen.
"Bei anderen Middleware-Protokollen wie Dcom oder Corba musste man sich wenigstens noch Gedanken machen und sich vom Firewall-Administrator die entsprechenden Ports freischalten lassen", schimpft Cirosec-Consulter Stefan Strobel. Mit Soap aber seien dem Leichtsinn Tür und Tor geöffnet.

Firewalls werden noch entwickelt

Christian Emmerich, Security-Chefberater bei IBM Global Services, regt deshalb die Entwicklung spezieller Soap-Firewalls an. Diese sollen als Application Level Gateway den Datenstrom detaillierter prüfen als die verbreiteten Paketfilter von Cisco, Checkpoint & Co.
"Aber dazu muss man in die übertragenen Nutzdaten hineinschauen, was einen relativ vollständigen Mime- und XML-Parser erfordert", gibt Weimer zu bedenken. "Das Ganze wird also ziemlich aufwändig." Marktreif sind solche Soap-Proxies noch nicht.
Möglicherweise entschärft sich dieses Problem von selbst. Denn Microsofts Dotnet-Chefentwickler Don Box hat kürzlich selbst betont, man müsse weg von HTTP als Soap-Transporteur. Er sieht jedoch mehr Leistungs- als Sicherheitsprobleme. Sorgen bereitet ihm, dass HTTP für kurze Antwortzeiten ausgelegt ist, komplexe Web-Services-Anwendungen aber eventuell mehrere Minuten pro Antwort brauchen.

Autorisierung liegt im Argen

HTTP ist aber nicht das einzige Security-Problem im Web-Services-Kontext. Die Fachleute mahnen zudem, dass es derzeit noch keine einsatzfähigen Ansätze gibt, wie bei der Koppelung von Anwendungen sich die beteiligten Server gegenseitig authentifizieren und so sicherstellen, dass kein Unbefugter aus der Ferne Prozesse anstößt.
"Beim W3C favorisiert man digitale Signaturen und Public-Key-Infrastrukturen", berichtet Von-zur-Mühlen-Berater Werner Metterhausen. Aber flächendeckende PKIs seien heute noch Sciencefiction. "Selbst wenn Verschlüsselung per SSL erfolgt, bleibt es immer noch Aufgabe der Anwendung, Soap-Requests auf ihre Berechtigung zu überprüfen", ergänzt Uni-Experte Weimer. "Da hierbei mehrere Protokollebenen übersprungen werden, ist es unwahrscheinlich, dass viele Implementierungen dies auf Anhieb richtig hinbekommen."
Deshalb befürchten die Fachleute nun, dass die Anwender jetzt ihre Applikationen und Server über das Internet eng miteinander verknüpfen, ohne dabei die entsprechenden Sicherheitsvorkehrungen zu treffen. IBM-Fachmann Emmerich: "Die Security hinkt mal wieder der Funktionalität hinterher." ab

Zurück zur Presseübersicht