Wie schützt eine WAF vor Sicherheitslücken?

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

In unserem demnächst erscheinenden Bericht „State of Application Delivery 2018“ stellen wir fest, dass der Einsatz von Web Application Firewalls (WAF) seit Jahren kontinuierlich zunimmt. Das ist eine gute Entwicklung, denn Anwendungen sind heute das Tor zu Kunden- und Unternehmensdaten, und herkömmliche Methoden zur Zugriffskontrolle auf Netzwerkebene reichen nicht mehr aus. Denn böswillige Akteure nehmen zunehmend Identitäten und Anwendungen selbst ins Visier, um an dieses digitale Gold zu gelangen.

Wie genau entschärft eine WAF also all diese Schwachstellen, die immer wieder wie Unkraut im Garten aus dem Boden schießen? Eine WAF nutzt drei grundlegende Methoden, um Webangriffe zu erkennen und zu verhindern: Anfragen ablehnen bzw. zulassen, prüfen und zurückweisen sowie Signaturen.

Sehen wir uns die einzelnen Methoden einmal genauer an.

Anfragen ablehnen/zulassen

Die Methode zum Ablehnen bzw. Zulassen von Anfragen ähnelt stark dem traditionellen Türstehermodell von Netzwerk-Firewalls. Anfragen werden anhand der verfügbaren Informationen entweder abgelehnt oder zugelassen. Diese Informationen können einfach sein – etwa eine IP-Adresse – oder komplexer und HTTP-spezifisch, wie OPTIONS oder METHODS.

• Sperr-/Zulassungslisten
  Wenn Sie wissen, dass ein Angreifer eine bestimmte IP-Adresse oder einen bestimmten IP-Adressbereich verwendet, blockieren Sie ihn. Wenn Sie wissen, dass eine Anwendung nur Anfragen von einer bestimmten IP-Adresse oder einem bestimmten IP-Adressbereich empfangen darf, lassen Sie ausschließlich diese zu. Dies ist die einfachste Schutzmethode und basiert auf relativ statischen Informationen: den IP-Adressen bzw. IP-Adressbereichen, von denen Anfragen stammen dürfen oder nicht stammen sollten.
  
  Falls Sie sich nun fragen, warum Sie dafür nicht einfach eine Netzwerk-Firewall verwenden sollten: Schließlich ist genau das ihre Aufgabe. In lokalen Umgebungen funktioniert das hervorragend. Wenn Sie jedoch Anwendungen in der Public Cloud schützen müssen, ist dies möglicherweise keine Option. Und wenn Sie zu den 59 % der Befragten unserer Studie „State of Application Delivery 2018“ gehören, die bereits in zwei bis sechs verschiedene Cloud-Anbieter investiert haben, können Sie nicht davon ausgehen, dass die Richtlinien der Netzwerk-Firewalls bei allen Anbietern identisch sind. Natürlich können Sie dieselben Regeln in mehreren Clouds implementieren. Wenn Sie die Regeln jedoch über eine WAF durchsetzen, können Sie dieselbe Richtlinie mit derselben WAF in mehreren Umgebungen verwenden. Einheitlichkeit ist der Schlüssel zu erfolgreicher und skalierbarer Sicherheit.
• Optionen einschränken
  HTTP verwendet eine Reihe von Headern, um der Anwendungsplattform (und der Anwendung) mitzuteilen, was der Benutzer tun möchte. HTTP-METHODEN können beispielsweise zum Abrufen (GET), Speichern (PUT), Senden (POST) und Löschen (DELETE) von Ressourcen verwendet werden. Auch das OPTIONS-Feld verfügt über eine durch RFCs eingeschränkte Menge von Werten, die sich mit einer WAF einfach kontrollieren lässt. Einige Schwachstellen – wie Optionsbleed – nutzen diese Felder aus. Um die Ausnutzung solcher Schwachstellen zu verhindern, können Sie mit der WAF die möglichen Werte auf diejenigen beschränken, die für die ordnungsgemäße Ausführung der Anwendung erforderlich sind. In einigen Fällen schränkt die WAF diese Werte standardmäßig ein. Beispielsweise lässt BIG-IP ASM (F5 WAF) die HTTP-Methode OPTIONS standardmäßig überhaupt nicht zu.

Signaturen

Signaturen sind eine weitere Schutzmethode, die bei vielen verschiedenen Sicherheitslösungen zum Einsatz kommt. Antiviren- und Anti-Malware-Dienste nutzen Signaturen, um schnell nach Anzeichen für Viren und Schadsoftware zu suchen und diese zu kennzeichnen. Auch IPS/IDS und WAF stützen sich in hohem Maße auf diese Methode. Es gibt zwei Arten von Signaturen: benutzerdefinierte und vom Anbieter verwaltete.

• Vom Anbieter verwaltet
  Vom Anbieter verwaltete Signaturen werden in der Regel in einer „Datenbank“ gespeichert, die automatisch vom Anbieter gepflegt wird. Dazu gehört auch die Aktualisierung der Datenbank, wenn neue Schwachstellen anhand einer eindeutigen digitalen Signatur identifiziert werden können. Eine WAF gleicht eingehende Anfragen mit der Datenbank ab und ergreift entsprechende Maßnahmen, wenn sie eine Übereinstimmung mit einer darin enthaltenen Signatur feststellt. Signaturen können aus reinem Klartext bestehen, sind jedoch häufiger komplexe Kombinationen kryptischer Zeichenfolgen, die Schadcode repräsentieren. Dieser kann die Ausführung von Code aus der Ferne auslösen, die Anwendungsplattform anderweitig kompromittieren und Zugriff gewähren oder den Dienst verweigern.
• Benutzerdefiniert
  Benutzerdefinierte Signaturen ermöglichen es Betreibern, der Datenbank schnell eine Signatur hinzuzufügen. Diese Funktion ist wichtig, um schnell auf neue Schwachstellen reagieren zu können (in vielen Fällen noch am selben Tag) und um Schwachstellen zu entschärfen, für die noch keine vom Anbieter verwaltete Signatur veröffentlicht wurde.

Inspektion

Schließlich ist auch eine Überprüfung vorgesehen, um die vollständige Kontrolle über Anfragen (und Antworten) zu gewährleisten. Durch die Überprüfung von Anfragen kann die WAF die darin enthaltenen Informationen mit bekanntermaßen unbedenklichen bzw. schädlichen Zeichenfolgen und Werten vergleichen, um festzustellen, ob die Anfrage bösartig oder legitim ist. Für HTTP-Anwendungen (also die meisten Anwendungen im heutigen Internet) ist dies die wichtigste Funktion, die eine WAF bieten sollte. Wenn eine WAF keine programmierbare Überprüfung ermöglicht, sollten Sie Ihre Wahl noch einmal überdenken. Da HTTP textbasiert und erweiterbar ist, gibt es praktisch keine Möglichkeit, eine umfassende Liste von Optionen und Methoden zum Ankreuzen bereitzustellen, mit denen sich Anfragen überprüfen lassen. Nur für sehr wenige HTTP-Header gelten Einschränkungen hinsichtlich der zulässigen Optionen, sodass sich nur schwer begrenzen lässt, was darin enthalten sein darf und was nicht. Daher ist häufig eine Überprüfung erforderlich, um in Headern oder in der Nutzlast selbst eingebetteten Schadcode aufzuspüren. Die Überprüfung kann auf zwei Arten erfolgen: anhand bekannter Header und anhand der Nutzlast.

• Bekannte Header
  Es gibt eine Reihe klar definierter Header, die jede HTTP-Anfrage enthält. Host, User-Agent, Content-Type usw. sind nahezu allgegenwärtig. Jeder davon ist kaum mehr als eine Textzeichenfolge. Aufgrund der Vielzahl möglicher Kombinationen ist es schwierig, Werte auf eine Positivliste zu setzen. Stattdessen müssen sie einzeln auf verdächtige Werte überprüft werden. Im Allgemeinen kann eine WAF die HTTP-Header sehr schnell analysieren und deren Überprüfung ermöglichen. Sie stehen am Anfang jeder Anfrage und wurden nachweislich für verschiedene Angriffe auf Anwendungsplattformen missbraucht. Zu den bekannteren Schwachstellen zählen ApacheKiller, Optionsbleed und Apache Struts .
• Payload-Inspektion
  Die Payload-Inspektion hält, was ihr Name verspricht: Sie untersucht die gesamte Payload – vom ersten bis zum letzten Byte – auf bekannte Kombinationen alphanumerischer Daten, die auf den Versuch hindeuten, eine Schwachstelle auszunutzen. Mithilfe der Payload-Inspektion können Betreiber sowohl benutzerdefinierte HTTP-Header als auch den Body einer Anfrage auf bestimmte Anzeichen schädlicher Aktivitäten untersuchen. Dazu muss die WAF zunächst den gesamten Inhalt der Anfrage vorhalten. Dies ist notwendig, da Pakete nur eine begrenzte Datenmenge enthalten können. Wenn sich die schädlichen Daten über zwei Pakete erstrecken, können sie von Diensten übersehen werden, die lediglich jedes Paket einzeln untersuchen. Durch die Untersuchung der gesamten Payload stellt eine WAF sicher, dass schädliche Daten unabhängig von ihrer Position erkannt und daran gehindert werden, ihr Ziel zu erreichen.

Eine WAF kann weit mehr leisten als nur Schwachstellen zu entschärfen, um Anwendungen zu schützen. Viele bieten außerdem Bot-Erkennung, Ratenbegrenzung, DDoS-Schutz und weitere Funktionen. Der Hauptzweck einer WAF besteht jedoch darin, Anwendungen durch die Entschärfung von Schwachstellen zu schützen. SQLi, XSS und CSRF werden zwar meist genannt, sind inzwischen aber beinahe schon „ein alter Hut“. Angreifer haben die offensichtlichen Anwendungsschwachstellen hinter sich gelassen und begonnen, gezielt die Plattformen anzugreifen, da diese einen wesentlich größeren Pool potenzieller Opfer bieten. Plattformschwachstellen – also Schwachstellen in HTTP und den zugehörigen Frameworks – sind eine zunehmende Ursache für Sicherheitsverletzungen, gegen die eine WAF der Enterprise-Klasse wirksamen Schutz bietet.

Durch den Einsatz herkömmlicher Sperr- und Freigabelisten sowie signaturbasierter Scans in Verbindung mit der Möglichkeit, vollständige Anfragen (und Antworten) zu prüfen, bietet eine WAF den Schutz, den Unternehmen heute benötigen, um sich und ihre Kunden zu schützen.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie