Bundesamt für Sicherheit in der Informationstechnik

M 4.405 Verhinderung der Blockade von Ressourcen (DoS) bei Webanwendungen und Web-Services

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator, Entwickler

Webanwendungen und Web-Services bieten häufig ressourcenintensive Funktionen an, die zum Beispiel komplexe Datenbankabfragen oder Datenübermittlungen auslösen. Werden diese rechenintensiven Operationen bewusst gehäuft aufgerufen oder die Webanwendungen und Web-Services mit Anfragen überflutet, können hierdurch Ressourcen im Übermaß belegt und der Betrieb bis zur Unerreichbarkeit eingeschränkt werden. Dieses Vorgehen wird als Denial-of-Service-Angriff ( DoS ) bezeichnet.

DoS -Angriffe beruhen in den meisten Fällen ebenso wie Brute-Force- und Enumeration-Angriffe auf Automation (siehe M 4.396 Schutz vor unerlaubter automatisierter Nutzung von Webanwendungen ). Daher sollten zur Vorbeugung gegen DoS -Angriffe ähnliche Schutzmechanismen umgesetzt werden. Dazu zählen beispielsweise folgende Maßnahmen:

  • Grenzwerte festlegen (zum Beispiel die vorübergehende Blockierung einer Ressource oder des Benutzerkontos nach wiederholten Fehlzugriffen),
  • die Zeitspanne zwischen Anfrage und Verarbeitung durch die Webanwendung künstlich verzögern (zum Beispiel bei wiederholt erfolgloser Anmeldung),
  • die aufrufende IP -Adresse bei Verdacht auf einen Angriff temporär sperren,
  • CAPTCHAs verwenden,
  • Eingaben bei Eingabefeldern verifizieren, bevor rechenintensive Operationen angestoßen werden,
  • XML -Filtermechanismen und XML -Validitätsprüfungen einsetzen.

Zusätzlich geben die folgenden Beispiele Hinweise auf spezifische Schutzmaßnahmen, um Denial-of-Service-Angriffe bei Webanwendungen und Web-Services zu erschweren:

  • Ressourcenintensive Operationen sind besonders anfällig für DoS -Angriffe. Daher kann die Ressourcennutzung pro Benutzer auf ein Maximum eingeschränkt werden. Darüber hinaus können bestimmte Operationen nur angemeldeten Benutzern zugänglich gemacht werden (zum Beispiel komplexe Datenbankaufrufe).
  • Pro Benutzer sollte nur eine Anfrage zur gleichen Zeit bearbeitet werden. Mehrere Anfragen desselben Benutzers sollten sequenziell bearbeitet werden.
  • Die Last durch DoS -Anfragen kann teilweise durch Zwischenspeichern (cachen) der Webseitenaufrufe deutlich verringert werden. Somit wird die angeforderte, rechenintensive Operation nicht bei jedem Aufruf ausgeführt, sondern lediglich das zwischengespeicherte Resultat zurückgegeben. Stark Ressourcen belastende Anfragen können auch in lastarmen Zeiten vorberechnet werden (Voraggregation).
  • Die Architektur und Flusskontrolle der Webanwendung sollten darauf ausgelegt sein, rechenintensive Operationen zu vermeiden (zum Beispiel bei der Erstellung der Session-ID oder anderen kryptographischen Mechanismen sollten ressourcenintensive Operationen gemieden werden). Zur Erkennung rechenintensiver Operationen können Lasttests durchgeführt werden.
  • Ein Überlauf von Speicherplatz, zum Beispiel im Rahmen der Protokollierung, kann dazu führen, dass keine Schreibzugriffe mehr auf den Datenträger möglich sind. Werden Speichervorgänge von der Webanwendung oder dem Web-Service durchgeführt, kann dies den Betrieb gefährden. Daher sollte der Zugriff auf Datenspeicher begrenzt und die Kapazität der Datenspeicher regelmäßig geprüft werden. Ebenso sollte auch der Verbrauch von Arbeitsspeicher ( RAM ) pro Thread begrenzt werden.
  • SOAP -Nachrichten müssen gemäß dem entsprechenden XML -Schema validiert werden. Ist die Validierung nicht erfolgreich, da sie zum Beispiel eine undefinierte Zahl an Elementen enthält, darf die SOAP -Nachricht nicht weiter verarbeitet werden, da diese ansonsten zu Problemen bei der Verarbeitung durch den XML -Parser führen kann.
  • Ebenso sollten Webanwendungen und Web-Services vor SOAP -Flooding-Attacken geschützt werden. Diese sind vergleichbar mit herkömmlichen Flooding-Angriffen ( z. B. SYN-Flooding) und können deswegen auch mit ähnlichen Schutzmaßnahmen bekämpft werden. So lassen sich mit einem Intrusion-Detection-System wiederholt gesendete Nachrichten erkennen und direkt blockieren, z. B. durch Anwendung von Heuristiken.

Bei Web-Anwendungen und Web-Services, bei denen aufgrund ihrer Natur mit gezielten, zum Beispiel politisch motivierten DoS -Angriffen aus dem Internet zu rechnen ist, kann auch die Zusammenarbeit mit einem Dienstleister sinnvoll sein, der sich auf die Abwehr von DoS -Angriffen spezialisiert hat. Solche Dienstleister leiten den IP -Verkehr im Angriffsfall über eigene Systeme, die Zugriffe filtern und/oder die Zielsysteme durch andere Maßnahmen wie zum Beispiel Zwischenspeicher (Caching) entlasten. Dabei ist im Vorfeld abzuwägen, ob durch die Umleitung der Datenströme über die Systeme Dritter zusätzliche Gefährdungen oder Anforderungen entstehen. Eine beliebte Angriffsmethode für zwischengespeicherte Web-Seiten ist beispielsweise, dass der Angreifer nicht vorhandene Unterseiten aufruft. Wenn dies der Dienstleister nicht abfängt und die Anfrage nach der vermeintlich neuen Unterseite an die ursprüngliche Seite weiterleitet, kommt es zu einem unbeabsichtigten DoS -Angriff des Dienstleisters. Solchen neuen Angriffsvektoren muss bei der Auswahl des Anti- DoS -Dienstleisters begegnet werden.

In serviceorientierten Architekturen ( SOA ) müssen zudem die Einträge in der Service-Registry von SOA -Diensten vor Manipulationen geschützt werden. Deshalb ist in der WS-Policy festzulegen, wer schreibenden Zugriff auf die Service-Registry hat. Das sind üblicherweise Service-Provider der eigenen technischen Domäne und Administratoren. SOAP -Nachrichten, die von Providern an die Service-Registry zwecks Registrierung übersandt werden, sind zusätzlich über das Provider-Zertifikat abzusichern, z. B. im Label der SOAP -Nachricht. Anhand der Zertifikate kann die Service-Registry überprüfen, ob der Eintrag echt ist. Ebenso muss sich ein Quality-of-Service-( QoS )-Agent mit einem Zertifikat gegenüber der Service-Registry ausweisen, wenn er QoS -Parameter an einen SOA -Dienst übermittelt. Zum Schutz der in der Regel periodisch erfolgenden Synchronisation zwischen verteilten Service-Registries sind die SOAP -Nachrichten, die die Synchronisationsinformation beinhalten, mittels des Zertifikats der absendenden Service-Registry abzusichern, z. B. im Label der SOAP -Nachricht.

Prüffragen:

  • Werden der Einsatz und die Nutzung ressourcenintensiver Operationen bei Webanwendungen und Web-Services gemieden, und werden diese besonders geschützt?

  • Wird ein möglicher Überlauf von Protokolldaten bei Webanwendungen und Web-Services überwacht und verhindert?

  • Werden SOAP -Nachrichten anhand eines entsprechenden XML-Schemas validiert?

  • Wurde bei kritischen Diensten und Anwendungen die Zusammenarbeit mit einem Anti-DoS-Dienstleister geprüft?

  • Sind in serviceorientierten Architekturen die Einträge in der Service-Registry von SOA-Diensten vor Manipulationen geschützt?

Stand: 15. EL Stand 2016