Bundesamt für Sicherheit in der Informationstechnik

M 4.454 Schutz vor unerlaubter Nutzung von Web-Services

Verantwortlich für Initiierung: Verantwortliche der einzelnen Anwendungen, Leiter IT

Verantwortlich für Umsetzung: Administrator, Leiter IT

Um zu gewährleisten, dass Web-Services nur von berechtigten Parteien genutzt werden dürfen, ist es erforderlich, konkrete Anforderungen an die Authentisierung und Autorisierung einzelner Benutzer oder Clients zu stellen. Diese Anforderungen müssen im Rahmen eines sorgfältig gewählten Authentisierungs- und Autorisierungsmodells durch einen oder eine Kombination mehrerer verfügbarer WS-Standards realisiert werden. Dies gewährleistet die Einschränkung und Kontrolle einzelner Zugriffe auf den Web-Service. Welche Web-Service-Standards für die Umsetzung einer geeigneten Authentisierung und Autorisierung eingesetzt werden können, ist näher in den Maßnahmen M 4.456 Authentisierung bei Web-Services und M 4.455 Autorisierung bei Web-Services beschrieben.

Um Angriffe auf einen Web-Service zu erschweren, die im schlimmsten Fall zu einer Umgehung des Berechtigungssystems führen und somit unberechtigten Zugriff auf vertrauliche Daten oder schützenswerte Funktionen ermöglichen, sollten zusätzliche Maßnahmen gegen Brute-Force-Angriffe oder andere automatisierte Angriffe auf Web-Services ergriffen werden. Automatisierte Angriffe zeichnen sich durch eine hohe Zahl an Zugriffsversuchen innerhalb einer kurzen Zeitspanne aus. Hoch frequentierte Anfragen (zum Beispiel zum Erraten von Passwörtern) sollten durch festgelegte Schwellwerte erkannt werden und zu geeigneten Reaktionen führen (Alarmierung von Verantwortlichen, Sperrung des Zugangs). Solche Schwellwerte können sich zum Beispiel auf die Anzahl der Zugriffe, Fehlanmeldungen, die übertragene Datenmenge oder die Größe der übertragenen XML -Nachrichten beziehen. Im Falle eines erkannten Angriffsversuches kann eine temporäre Sperrung des Zugangs erfolgen. Eine Alternative zur Sperrung des Zugangs ist die inkrementelle Verzögerung von Antworten (das heißt eine bei jedem Fehlversuch ansteigende Wartezeit), die automatisierte Angriffe effektiv ausbremst.

Bei der Festlegung von Schwellwerten ist darauf zu achten, dass legitime Dienstnutzer (Clients und ihre Benutzer, andere Web-Services) nicht in der Funktionalität und der Bedienung des Web-Service eingeschränkt werden.

Grundsätzlich sollte immer sichergestellt werden, dass nur berechtigte Systeme oder Benutzer auf den Web-Service zugreifen dürfen. Durch eine Firewall kann sichergestellt werden, dass nur berechtigte IP -Adressen oder IP -Adressblöcke auf den Web-Service zugreifen können. In geschlossenen Umgebungen bietet sich dieser Whitelisting-Ansatz an. Wird ein Web-Service betrieben, der aus dem Internet erreichbar sein soll (zum Beispiel API s zur freien Nutzung durch Dritte), empfiehlt sich ein Blacklisting-Ansatz. Durch die Sperrung bekannter IP -Adressen, die zum Beispiel Spam-Servern zugeordnet werden können, kann sichergestellt werden, dass Zugriffe von Systemen ausgeschlossen werden, die als bösartig angesehen werden müssen. Auch unberechtigte Zugriffe aus bestimmten Regionen oder Ländern können durch solche Sperrlisten verhindert werden. Alternativ kann die Sperrung von IP -Adressblöcken auch direkt beim Provider veranlasst werden. Durch eine entsprechende Konfiguration der Firewall kann auch sichergestellt werden, dass auffällig häufige Aufrufe aus einem IP -Adressbereich oder von einer einzelnen IP -Adresse begrenzt werden, um so einem potenziellen Denial-of-Service-Angriff entgegenzuwirken.

Eine weitere Möglichkeit, den Zugriff auf einen Web-Service nur für berechtigte Benutzer einzuschränken, bietet der Einsatz eines VPN s. Durch ein Standort-zu-Standort- VPN kann beispielsweise sichergestellt werden, dass nur ein ausgewählter Kreis von Geschäftspartnern unter Wahrung der Vertraulichkeit und Integrität auf den Web-Service zugreifen darf. Weitere Hinweise zum Einsatz eines VPNs finden sich im Baustein B 4.4 VPN . Ein VPN trägt zum Schutz des Web-Service bei, da keine externen Brute-Force-Angriffe auf den Web-Service durchführbar sind, wenn dieser nur aus einem internen Netz erreichbar und somit nicht im Internet exponiert ist.

Web-Services sind oft darauf ausgelegt, dass diese sowohl intern als auch extern (zum Beispiel durch Geschäftspartner) aufgerufen werden können, wobei jeweils ein Zugriff auf unterschiedliche Funktionen erfolgen kann. Externe Benutzer dürfen zum Beispiel nur in der Lage sein, eine Bestellung aufzugeben, während die internen Benutzer auch die Möglichkeit haben sollten, die eingegangenen Bestellungen zu verwalten und zu bearbeiten. Oft werden diese unterschiedlichen Funktionen über ein und denselben Web-Service-Endpunkt angeboten. Dadurch, dass allerdings alle Funktionen über den selben Endpunkt aufrufbar sind, kann ein externer Angreifer durch Auslesen der WSDL -Datei oder andere Verfahren der Informationsgewinnung Aufrufpunkte der internen Funktionen ermitteln, um Daten zu manipulieren oder auszulesen. Aus diesem Grund sollte bei der Realisierung des Web-Service darauf geachtet werden, dass die Bereitstellung von Funktionen für interne und externe Aufrufer nicht auf dem selben Endpunkt erfolgt. Idealerweise befinden sich die unterschiedlichen Web-Service-Endpunkte auf unterschiedlichen Systemen. Durch die Trennung der zugehörigen URLs kann dann auch eine feingranulare Kontrolle auf den Web-Service durch eine Firewall erzielt werden, da der Web-Service durch unterschiedliche URLs und Ports, oder sogar nur aus bestimmten Netzen aufrufbar ist.

Sofern nicht gewollt ist, dass auf bestimmte Operationen zugegriffen werden kann, kann auch die Beschreibung der XML -Struktur (Schema) für den Dienstaufruf derart modifiziert werden, dass die unerwünschten Operationen entfernt werden. Sofern eine Anfrage gestellt wird, die eine aus dem Schema entfernte Operation enthält, wird diese im Rahmen der Validierung der XML-Anfrage gegen das Schema als nicht valide identifiziert und entsprechend abgelehnt.

Die Zugriffsbeschränkung auf einen Web-Service über Authentisierung und Autorisierung der Dienstnutzer kann sich als wirkungslos erweisen, wenn der Angriff seinen Effekt zeigt, bevor die Mechanismen der Zugriffskontrolle zur Geltung kommen. Aus diesem Grund muss im Vorfeld eine adäquate Validierung der gesamten Nachricht erfolgen, bevor der Web-Service diese weiter verarbeiten darf. Dieser Prozess wird auch als Schemavalidierung bezeichnet. Durch die Schemavalidierung wird sichergestellt, dass Nachrichten und Angriffe abgewehrt werden, die vom definierten Schema abweichen. Dies bedeutet, dass das Schema so restriktiv wie möglich zu gestalten ist, das heißt nur eine begrenzte Menge an XML -Formaten zur Nutzung des Dienstes verfügbar sein darf. Bei der Schemavalidierung ist es daher notwendig, das Schema so einzuschränken, dass Nachrichten mit bekannten Angriffsmustern ausgeschlossen werden. Zusätzlich ist es notwendig, die Nachricht auf bestimmte Zeichenfolgen zu untersuchen, die eventuell für Injection-Angriffe genutzt werden können (siehe G 5.174 Injection-Angriffe ).

Weiter müssen die Schemata eines Web-Service so angepasst werden, dass nur Nachrichten bis zu einer bestimmten Größe verarbeitet werden können. Die Verarbeitung einer übergroßen Nachricht kann die Ressourcen des verarbeitenden Systems auslasten und somit zu Leistungseinbußen oder Ausfällen führen. Bei der Beschränkung der Nachrichtengröße ist darauf zu achten, dass keine unbeschränkten Nachrichtenteile verarbeitet werden dürfen, die folgende Merkmale besitzen:

  • xsd:any,
  • xsd:anyType,
  • xsd:anySimpleType,
  • rekursive Definition von Elementen oder Typen,
  • unbeschränkte Listen.

Die Validierung eines Schemas kann entweder bereits an einem XML -Gateway oder direkt auf dem System erfolgen, welches den Web-Service bereitstellt. Die Entscheidung, an welcher Stelle die Validierung erfolgen soll, ist bereits während der Planungsphase zu treffen, da dies auch Auswirkungen auf die Gesamtarchitektur haben kann.

Prüffragen:

  • Wurden geeignete Standards für die Authentisierung und Autorisierung gewählt und umgesetzt?

  • Sind Maßnahmen umgesetzt, die automatisierte Angriffe erkennen und abwehren können, zum Beispiel durch die Überwachung von Schwellwerten für Anfragen?

  • Ist darüber hinaus sichergestellt, dass nur berechtige Teilnehmer auf den Web-Service zugreifen dürfen?

  • Erfolgt eine Trennung zwischen internen und externen Operationen und ist sichergestellt, dass nur die jeweiligen Benutzer die für sie benötigten Operationen aufrufen dürfen?

  • Wurde das XML -Schema entsprechend restriktiv aufgebaut, und wird die Einhaltung des Schemas überprüft?

Stand: 14. EL Stand 2014