Ob Autorisierung von Funktionsaufrufen oder Überprüfung eingebetteter digitaler Signaturen, Web-Services besitzen ganz eigene Sicherheitsaufgaben. Genau diese wollen Web-Service-Security-Gateways als vorgeschaltete Lösung übernehmen.

Web-Service-Security-Gateways nehmen als zentrale Instanz Application-Servern die Zugangs- und Dokumentenkontrolle ab.

Seit dem Turmbau zu Babel weiß jeder, wie verheerend sich unterschiedliche Sprachen auf ein gemeinsames Vorhaben auswirken. Die Menschen mussten ihren Plan aufgeben, weil Gott sie durch unterschiedliche Sprachen verwirrte. Computer-Anwendungen kämpfen ebenfalls mit dieser Sprachverwirrung. Allerdings zeichnet sich mit den Web-Services (WS) eine Lösung ab, welche die Not zumindestens lindert. Denn diese schaffen einen einheitlichen Kommunikationstandard, der unabhängig von dem dahinter liegenden Betriebssystem und der Entwicklungssprache arbeitet. So muss ein System lediglich ein WS-Interface bereitstellen, das Anfragen beziehungsweise Antworten zwischen interner Sprache und dem Web-Service-Format umwandelt. SOAP (Simple-Object-Access-Protocoll) und WSDL (Web-Service-Description-Language) bilden die Basis für die Web-Service-Kommunikation. SOAP dient als Transportprotokoll, während WSDL die Schnittstellen beziehungsweise Funktionsaufrufe definiert, die eine Anwendung als Web-Services anbietet. So sehr diese die Anwendungskommunikation, gerade auch mit externen Partnern über das Internet, vereinfachen, ist jedoch Vorsicht beim Einsatz dieser Services geboten. Zum einen basiert SOAP auf XML. Damit können SOAP-Nachrichten relativ einfach, auch von Menschen, gelesen werden. Zum anderen existieren in den Kernstandards SOAP und WSDL keinerlei Sicherheitsmechanismen. Auch andere Themen wie Transaktions-Steuerung oder Work-flow-Steuerung behandeln SOAP oder WSDL übrigens nicht. Diese Einfachheit macht deren Stärke aus, bringt dadurch aber, was die Sicherheit anbelangt, WS-spezifische Probleme mit sich, auch bei der Implementierung. Zudem betreffen Web-Services auch die Bedrohungen, die allgemein für alle auf dem Web aufsetzende Anwendungen und Dienste gelten.

Beispielsweise verwendet SOAP in den allermeisten Fällen HTTP als Transportprotokoll. Damit erbt SOAP alle potenziellen Bedrohungen, die HTTP betreffen. So hat etwa eine Syn-Flood-Attacke gegen einen ungeschützten Web-Service die gleichen Auswirkungen, als würden sie gegen einen ähnlich konfigurierten Web-Server erfolgen. Wenn also der Administrator nicht den darunter liegenden Transport-Service absichert, gefährdet dies auch die Web-Services selbst. Beinahe jede WS-bezogene Spezifikation, die sich mit Sicherheit beschäftigt, verweist auf SSL (Socket-Secure-Layer) und TSL (Transport-Layer-Security), um den Transport-Weg abzusichern. Leider ist SSL kein Allheilmittel. SSL und andere Transport-Verschlüsselungs-Protokolle schützen zwar den SOAP-Inhalt während der Übertragung. Aber diese Protokolle sichern keine Schwachstellen ab, die speziell mit dem WS-Einsatz auftauchen. Damit eignen die Protokolle sich nicht, speziell dabei auftretende Gefahren abzusichern.

Offene Einladung

Weil XML keine Codierung von Nachrichten vornimmt, können Menschen diese direkt lesen. Interessante Informationen in abgefangene Nachrichten kann ein Lauscher diesen daher sofort entnehmen. Dabei geht es nicht nur um die Daten, wie über Kunden oder Aufträge, welche die XML-Nachricht enthält. Vielmehr gibt eine XML-Nachricht auch die Struktur der Daten preis. Während HTML lediglich Daten für eine Formatierung etwa in einem Web-Browser auszeichnet, beschreibt XML mittels Markierungen (Tags) im Text allgemein die Struktur. Dabei arbeitet XML hierarchisch, was die Gliederung der Tags anbelangt. Sehr oft gibt diese Struktur, in Dokument-Typ-Definitionen (DTD) oder XML-Schemata festgehalten, das interne Modell einer Datenbank wieder. Mit XML statt mit HTML ausgezeichnete Nachrichten lassen sich daher leichter interpretieren und geben eher Aufschluss über interne Strukturen. Das gleiche Problem taucht auch auf, wenn die Internet-Information-Services (IIS) direkt XML ausgeben. Das Schema und den Output einer Anfrage holt sich das System direkt von der Datenbank. Dies kann ein Angreifer verwenden, um Tabellen und Spalten zu identifizieren, was ihm eventuell einen interessanten Aufschluss über die interne Arbeit in einem Unternehmen gibt. Zum anderen kann es einem Angreifer helfen, in einem zweiten Schritt den SQL-Server wirkungsvoller zu attackieren.

Die meisten WS-Entwicklungs-Tools und -Plattformen versprechen eine rasche Entwicklung von Services. Dabei kümmern sie sich aber nicht um kritische Details. Gibt der Web-Service beispielsweise sensible Informationen über die Unternehmensstrukturen preis? Dies geschieht, wenn die erzeugte WSDL-Datei und das XML-Schema für diesen Service, entsprechende Informationen enthalten.

Außerdem kann bei einem Web-Service jeder die spezifischen Methoden oder Funktionen sehen, die dieser bereitstellt. Im Allgemeinen sind die Methoden, welche die WSDL-Datei dokumentiert, direkt aus dem Quellecode der Anwendung übernommen und wenig verschleiert worden, wie dies auch bei Web-Formularen der Fall ist. Eine WS-orientierte Architektur verlangt, dass die notwendigen Funktionen sehr fein definiert werden. Aus diesen detaillierten Definitionen können dann andere auf den zugehörigen Geschäftsprozess schließen. Ein HTML-Formular übergibt zwar einige Antworten an die dahinter liegende Anwendung zurück. Die dahinter liegenden Funktionsaufrufe gibt das Formular aber nicht preis.

Es könnte nun jemand einwenden, dass jeder den HTML-Code sehen kann und Dinge findet, die ein potenzieller Angreifer nicht sehen sollte. Verborgene Felder stellt ein Browser lediglich nicht dar. Sie existieren aber auf der Web-Seite und können leicht gelesen werden. Der Submit-Aufruf muss auf der Web-Seite existieren, und diesen gibt der Source-Code ohne größere Anstrengungen preis. Außerdem werden Cookies direkt als reiner Text abgelegt, ebenfalls so leicht lesbar wie der Quellcode einer Web-Seite. Allerdings liegt der große Unterschied zu Web-Service-Anwendungen darin, dass in den allermeisten Fällen Fremde Informationen über andere Funktionen einer konventionellen auf dem Web basierenden Anwendung gar nicht erhalten können. Die Anwendung stellt sicher, dass ein Nutzer nur die Funktionen sieht, für die er auch die Erlaubnis hat, sie aufzurufen. Web-Services dagegen stellen alles zur Verfügung, unabhängig davon, ob die betreffende Person oder Anwendung darauf zugreifen darf oder nicht.

Die meisten Web-Anwendungen beschränken den Zugriff präventiv, also vor einer Ausführung. Web-Services dagegen erledigen dies erst beim beziehungsweise nach dem Aufruf. Genau darin liegt das Problem. Um hier einen Schutz bereits während der Entwicklungszeit zu integrieren, müssen die Entwickler jede Funktion sorgfältig anschauen, um bei den passenden eine Routine zu integrieren, die prüft, ob der aufrufende Anwender diese Funktion auch ausführen darf. Die Autorisierungsfrage kann eine Applikation zwar so lösen. Dies verringert aber einmal die Performance, wenn solche Prüfroutinen sehr oft starten. Zum anderen muss die Entwicklungsabteilung diesen Schutz pflegen, was gerade bei größeren Anwendungen einen deutlichen Mehraufwand bringt und zudem auch fehleranfällig ist.

Um die Sicherheit von Web-Services zu garantieren, muss der Schutz von einem reaktiven zu einem präventiven Modell für Authentifizierung und Autorisierung wechseln. Es ist einfacher, eine Einladung an der Tür zu verlangen, als jemanden von einer Party zu entfernen, wenn er einmal drin ist. Ein präventives Modell stellt eine zentralisierte Sicherheitsarchitektur bereit, die ein Unternehmen nicht nur leichter verwalten kann, sondern es setzt die Policies auch einheitlich über das gesamte Unternehmen hinweg durch.

Der Reisepass zum Backend

WS-Security und SAML (Security-Assertion-Markup-Language) stellen einen Mechanismus bereit, um eine Vertrauensbeziehung zwischen einem Konsumenten (Client) und einem Produzenten (Web-Service) zu etablieren. Ganz grob gesagt, beschreibt WS-Security, wie WS-Encryption und WS-Security gemeinsam mit SOAP-Nachrichten funktionieren. SAML-Token dienen als Nachweis, dass der Absender einer Nachricht sich gegenüber einem System authentifiziert hat. Beide Spezifikationen sind flexibel und offerieren unzählige Optionen, um den Berechtigunsnachweis (Credentials) des Konsumenten zu überprüfen. Solche Nachweise können Username/Passwort, X.509, E-Mail-Adressen oder Signaturen beziehungsweise Tokens sein, um die Identität festzuzustellen und den Konsumenten zu autorisieren. Web-Services sind von Natur aus offen. Deshalb versteht es sich von selbst, dass der Service den Berechtigungsnachweis des Consumers zunächst untersucht und dann erst diesem vertraut. »Die Integrität hat eine viel größere Bedeutung als die Geheimhaltung«, sagt Dr. Phillip Hallam-Baker, Autor von SAML und Mitautor der WS-Security-Spezifikation. »Es geht nicht einfach nur um Sicherheit, sondern es ist eine Frage des Vertrauens.«

Einige Produkte können den Anwenderberechtigungsnachweis aus Elementen innerhalb des XML-Dokumentes entnehmen. Aber die Methode, wie ein WS-Anwendung den Berechtigungsnachweis überprüft, bedeutet lange nicht so viel wie die Tatsache, dass dieser Prozess Teil der WS-Sicherheitsstrategie ist. WS-Security besitzt genauso wie SAML eine breite Unterstützung. Tatsächlich wurde SAML als eine Methode entworfen, um innerhalb von WS-Security einen Berechtigungsnachweis vom Konsumenten zum Produzenten zu übertragen. SAML besitzt die Unterstützung der Hersteller einer Reihe von Identitäts-Management-Systemen wie Computer Associates, Netegrity, Novell oder Oblix. SAML integriert sich daher leicht in die bestehende Infrastruktur.

Zusätzlich zur Kontrolle des Berechtigungsnachweises eines Konsumenten muss der Produzent auch die Dokumentstruktur der Nachricht mit dem erwarteten Schema vergleichen. Web-Services zeigen sich genauso verletzlich gegenüber Angriffen auf der Datenebene wie SQL-Injizierung bei Formularen. Bei einem guten Design beschreibt das XML-Schema nicht nur das Format eines Dokumentes, sondern enthält auch die Typen der Daten, die es an der jeweiligen Stelle erwartet. Wenn das Schema für den Typen eines Elementes Integer vorschreibt, dürfen hier nur numerische Werte stehen. Legt das Schema die Länge eines Strings (Zeichenkette) für ein Element fest, dann sollte ein Service Dokumente zurückweisen, die längere Strings in solchen Elementen enthalten. Es gehört den Pflichtaufgaben jedes Programms, dass es Anwendereingaben überprüft. Web-Services bilden hier keine Ausnahme.

Hat ein Konsument ein Dokument oder Teile davon digital signiert, muss die WS-Anwendung das Zertifikat überprüfen und eine CRL (Certificate-Revocation-List) konsultieren. Diese enthält etwa Zertifikate, deren Gültigkeit widerrufen wurde. Wenn die Anwendung dieses dort nicht findet, überprüft sie klugerweise die Beglaubigungen entlang der Ausstellerkette bis hin zur CA (Certificate-Authority), die das Root-Zertifikat ausgestellt hat. Verschlüsselte Elemente muss die WS-Anwendung entschlüsseln und anschließend ebenfalls überprüfen. Hat die Anfrage die Prüfungen bestanden, kontrolliert die Anwendung noch an Hand der Berechtigungsnachweise des Konsumenten, ob dieser überhaupt Zugang zu diesem Web-Service und zu der aufgerufenen Funktion bekommen darf. Nur dann und erst dann sollte die WS-Anwendung die Anfrage bearbeiten.

Türsteher für Web-Services

Einen Web-Service abzusichern, bedeutet immer Teamarbeit. Eine Web-Service-Architektur mit einem guten Design enthält sowohl einen einzigen Zugangspunkt (Single-Point-of-Entry) auf der Netzwerkebene, als auch eine feine, sehr detaillierte Kontrolle auf der Service-Ebene.

Ein Web-Service-Security-Gateway, manchmal auch XML-Gateway, XML-Firewall oder SOAP-Proxy genannt, sichert auf der Netzwerkebene den Zugang zur WS-Anwendung ab und schützt die Applikation gegen Angriffe auf der Netzwerk- und Anwendungsebene. Network Computing testete sechs dieser Geräte in den Real-World Labs. Den Testbericht finden Sie auf Seite 28ff.

Ein WS-Produzent, typischerweise ein Application-Server von einem Hersteller wie Bea, IBM, Microsoft, Novell oder Sun, erlaubt die Ausführung spezifischer Operationen in Abhängigkeit von der Zugangsberechtigung des Konsumenten sowie der Daten, die der Konsument übergeben hat oder anfordert. Ein WS-Security-Gateway sichert den Zugang auf der Nachrichtenebene, um etwa bestimmte Operationen zu erlauben. Es gibt manchmal aber Situationen, in denen dies so nicht funktioniert, wenn es um die Sicherheit bei Services von Drittanbietern geht. CRM- (Customer-Relationship-Management), ERP- (Enterprise-Resource-Planing) oder HR-Anwendungen (Human-Resource) wiederum können Web-Services als Integrationsmethode verwenden. Aber sie nutzen manchmal interne, proprietäre Methoden für Authentifizierung und Autorisierung. In solchen Fällen muss sicher sein, dass die Anwendung auf Operationsebene die Autorisierung vornimmt.

Zum einen überprüft der Produzent am besten auch die Daten, während er diese für die Weiterverarbeitung vorbereitet. Zum anderen stellt er sicher, dass der Konsument die Erlaubnis besitzt, die gewünschte Operation mit den übergebenen Parametern auszuführen. Bei einer HR-Web-Service-Anwendung haben wahrscheinlich alle Mitarbeiter Zugriff auf das System. Aber jeder Angestellte hat, in Abhängigkeit von seiner Rolle im Unternehmen, nur begrenzte Rechte, innerhalb des Systems Daten anzuschauen. So könnte ein Mitarbeiter Zugang zum Service »EmployeeInformation« haben, um dort die Funktion »GetSalary« aufzurufen, allerdings nur für sich selbst.

Hilfe durch Zwei-Ebenen-Architektur

Die Zwei-Ebenen-Sicherheitsarchitektur stellt wegen der Performance, einem einzigen Zugangspunkt (Single-Point-of-Entry) und der Herstellerunabhängigkeit auf der Anwendungsebene den besten Ansatz dar. Verschlüsselung, Entschlüsselung oder die Erstellung einer Signatur beziehungsweise deren Überprüfung nehmen die CPU stark in Anspruch und beeinträchtigen damit die Performance. Obwohl Kryptografie-Beschleuniger-Hardware wie von Broadcom, N-Cipher oder Rainbow die Last der CPU mindern kann, ist es besser, die Aufgaben bereits am Netzwerkrand zu erledigen. Dieses Vorgehen ermöglicht auch die Integration mit anderen Geräten wie Intrustion-Detection-Systemen oder Load-Balancern. Dank der Entlastung kann der Application-Server seine Ressourcen voll für die Verarbeitung von Anfragen verwenden. Außerdem sinken die Kosten durch Beschleuniger-Karten und die Verwaltung von Zertifikaten.

Ein WS-Security-Gateway stellt nicht nur einen zentralen Zugangspunkt für Web-Services im Unternehmen bereit, sondern auch eine einzige Stelle, um Policies über das ganze Unternehmen hinweg durchzusetzen. Dadurch kommt es zu weniger Widersprüchen in der Anwendung der Sicherheits-Policies, und es verringert auch die Kosten für die Administration. Audit und Log führt das Gateway ebenfalls in einem Gerät zusammen, um so Anfragen und Antworten genau aufzuzeichnen. Die Integrationskosten sinken, insbesondere beim Einsatz von Identitäts-Management-Lösungen von Drittherstellern, indem statt vieler Server im Unternehmen nur ein oder zwei Geräte zum Einsatz kommen.

Integriert ein Unternehmen die Sicherheits-Policies in die Anwendungslogik, kann es sich dadurch eng an einen bestimmten Hersteller binden. Erledigt ein separates Gerät die Sicherheitsaufgaben, dann fällt die Abhängigkeit von einer bestimmten Implementierung weg. Dies sorgt ebenfalls für eine bessere Interoperabilität: WS-Security-Gateways müssen mit einer Menge verschiedener Herstellerimplementierungen gut zusammenarbeiten. Daher kommen die Gateways eher mit den verschiedensten Web-Services- und Identitätsmanagement-Plattformen zurecht.

Kein Ersatz durch andere Sicherheitslösungen

Die Idee, für Sicherheitsaufgaben ein separates Gerät als Mittler zu verwenden, ist nicht neu. Ein WS-Security-Gateway arbeitet nach den gleichen Prinzipien – und sorgt für die gleichen finanziellen und operativen Vorteile – wie andere Sicherheitsmittler beispielsweise Proxies, Firewalls oder Web-Application-Security-Gateways. Allerdings unterliegt ein Administrator einem Irrtum, wenn er denkt, dass diese anderen Geräte das gleiche Sicherheitniveau bieten, um Web-Services zu schützen. Keine dieser Lösungen kann die Funktionen wie Validierung, Authentifizierung oder Authorisierung bereitstellen, wie sie sich in WS-Security-Gateways finden.

WS-Security-Gateways sichern ebenfalls die Verbindung nach außen, wichtig für B2B-Anwendungen (Business-to-Business). Außerdem können sie abgehende Dokumente digital signieren und verschlüsseln oder Security-Header einfügen, um Geschäftsprozesse über Web-Services zu automatisieren.

Die Frage nach dem Kosten-Nutzen-Verhältnis

Return-on-Investment-Modelle (ROI) für Sicherheitsprodukte lassen sich schwer berechnen, da sie zuerst darauf beruhen, dass die Implementierung das Risiko und die damit verbundene Kosten verringert. Diesen Berechnungen basieren solange auf Vermutungen, wie ein Unternehmen keine empirischen Daten für die mit den Risikoszenarien verbundenen Kosten besitzt. Setzt ein Unternehmen Mustermann beispielsweise Web-Services ein, um damit Geld zu verdienen, hängen die Kosten eng mit den Auswirkungen eines Angriffs auf die oder Betrugs mit Hilfe der Web-Service-Anwendung zusammen.

Info Mögliche Schwachstellen eines SOAP-Services

Einen SOAP-Service (Simple-Object-Access-Protocol) zu betreiben, erfordert, viele Software-Komponenten bereitzustellen. Wie bei jeder anderen Anwendung auch bedeuten mehr Komponenten auch mehr Code-Zeilen, was wiederum zu zusätzlichen Möglichkeiten an Schwachstellen führt. Damit ein Administrator seine Applikation schützen kann, muss er die möglichen Zugänge und Methoden kennen, die ein Hacker verwendet.

Der erste Weg einer Anfrage (Request) führt über den Server, der das Transport-Protokoll implementiert, sei es FTP, SMTP oder HTTP. Im Falle von SOAP wird dies ein kompletter Web-Server sein, anfällig für eine Reihe von Web-Server-Angriffen wie Buffer- und Format-String-Overflows oder Denial-of-Service.

Die Anfrage übergibt der Web-Server dann einem SOAP-Application-Server. In einigen Fällen kann der Application-Server einen Web-Server auch als interne Komponente integrieren. Wenn die Anfrage einmal den Application-Server erreicht, gibt es neue Angriffsmöglichkeiten. Eventuell erhält ein XML-Parser die SOAP-Anfrage, um sie zu lesen. In Abhängigkeit von der Architektur des Parsers kann dieser beispielsweise einer XML-Struktur-Attacke, einer Struktur/Schema-Fehl-Validierung oder einem XML-External-Entities-Angriff (XXE) zum Opfer fallen.

Wenn der Parser die Überprüfung des SOAP-XML-Bodies abgeschlossen hat, kann die Anwendung die Daten in der Nachricht interpretieren, um herauszufinden, welchen SOAP-Dienst sie aufrufen und welche Parameter sie diesem übergeben muss. In dieser Phase könnte ein Angreifer versuchen, Services aufzurufen, die gewöhnlich nicht zugänglich oder erlaubt sind. Oder der Hacker versucht, Service-Parameter zu übergeben, die ungültig sind oder welche die Anwendung nicht erwartet. Dies verhindert gewöhnlich eine Überprüfung der Daten gegenüber der WSDL-Datei des SOAP-Services. Diese Kontrolle kann aber nur so gut sein wie die WSDL-Datei, die den Service beschreibt. Einige WSDL-Generatoren erzeugen keine WSDL-Dateien, die sicherheitsrelevante Attribute enthalten wie die maximale Länge für Zeichenkettenparameter (Strings).

Falls die WSDL-Datei keine Anweisungen enthält, um den SOAP-Service zu schützen, könnte die XML-Firewall es schädlichen Daten gestatten zu passieren. Eine WSDL-Datei beschreibt auch nicht den konkreten Inhalt, den die aktuellen Parameter einer Nachricht besitzen dürfen. Dies führt zu der letzten Stufe der Ausnutzung von Schwächen beim den SOAP-Services selbst. Die gleiche Verwundbarkeit, wie sie sich bei normalen CGI-/Web-Anwendungen (Common-Gateway-Interface) findet, existiert auch bei den SOAP-Services. Aller Code, der die Logik eines SOAP-Services umsetzt, ist verwundbar durch Angriffe wie Buffer-Overflows, Signed-Integer-Comparion-Angriffe oder SQL-Manipulationen.

Mustermann verdient etwa 4375 Dollar pro Stunde durch seine Web-Services. Wenn ein Angriff einen Ausfall von 24 Stunden verursacht, würde das Unternehmen ungefähr 105000 Dollar verlieren. Beeinträchtigt die Attacke zudem die Integrität einer zentralen Datenbank, etwa durch einen SQL-Injektions-Angriff, steigen die Kosten nochmals, um die Datenbank wiederherzustellen und online zu bringen. Wenn auch nur ein Prozent aller Bestellungen mit betrügerischer Absicht erfolgt, würde Mustermann jährlich 230000 Dollar verlieren. Verglichen mit den zu erwartenden Kosten für ein WS-Security-Gateway führt dies zu einer schnellen Amortisierung.

Dieses Szenario berücksichtigt allerdings noch keinen Aufwand durch gesetzliche Vorschriften. Auch betrachtet es keine Kosten durch Glaubwürdigkeitsverlust, Prozesse vor Gericht oder die vielfältigen zusätzlichen Aufwände, die mit Angriffen oder nicht autorisiertem Zugriff auf Daten über Web-Services zusammenhängen.

Außerdem gilt es auch die Kosten zu betrachten, die mit der Implementierung einer Lösung mit nur einer Architekturebene entstehen. Hier sorgt die Web-Service-Plattform selbst für die Sicherheit der Dienste, die sie bereitstellt. Verglichen mit dem Performanceverlust, der vermutlich mit

der zusätzlichen Last durch die Verschlüsselung einhergeht, benötigt der Administrator mindestens zwei Server, um die gleiche Performance zu erhalten wie durch ein einziges WS-Security-Gateway. Hinzu kommen die Kosten für SSL-Zertifikate sowie Anwendungssoft- und -hardware. Dies alles zeigt, dass ein WS-Security-Gateway zusätzlich zu seinem Sicherheitsbeitrag auch messbar die Kosten verringert. [ wve, nwc ]