BLOG

Wie verringert eine WAF Schwachstellen?

Lori MacVittie Miniaturbild
Lori MacVittie
Veröffentlicht am 18. Dezember 2017

In unserem bevorstehenden Bericht „State of Application Delivery 2018“ stellen wir fest, dass die Verwendung von Web Application Firewalls (WAF) seit Jahren stetig zunimmt. Das ist eine gute Sache, denn Apps sind heutzutage das Tor zu Kunden- und Unternehmensdaten und herkömmliche Methoden der Zugriffskontrolle auf Netzwerkebene reichen nicht aus. Der Grund hierfür ist, dass es immer häufiger zu Angriffen böswilliger Akteure auf Identitäten und Anwendungen selbst ankommt, um nach dem digitalen Gold zu schürfen.

Wie also genau verringert eine WAF all diese Schwachstellen, die immer wieder wie Unkraut im Garten auftauchen? Eine WAF verwendet drei Hauptmethoden zum Erkennen und Verhindern von Webangriffen: Ablehnen/Zulassen von Anforderungen, Prüfen und Ablehnen sowie Signaturen.

Lassen Sie uns jeden einzelnen erkunden, einverstanden?

Anfragen ablehnen/zulassen

Die Methode zum Ablehnen/Zulassen von Anforderungen ähnelt stark dem herkömmlichen Doorway-Modell, das von Netzwerk-Firewalls verwendet wird. Anfragen werden auf Grundlage der verfügbaren Informationen entweder abgelehnt oder zugelassen. Diese Informationen können einfach sein – wie eine IP-Adresse – oder komplexer und HTTP-spezifisch, wie OPTIONEN oder METHODEN.

  • Sperr-/Zulassungslisten
    Wenn Sie wissen, dass ein böswilliger Akteur von einer bestimmten IP-Adresse oder einem IP-Adressbereich ausgeht, blockieren Sie ihn. Wenn Sie wissen, dass eine Anwendung nur zum Empfangen von Anfragen von einer bestimmten IP-Adresse oder einem IP-Adressbereich berechtigt ist, lassen Sie nur diese zu. Dies ist die einfachste Schutzmethode und basiert auf einem ziemlich statischen Satz von Informationen: den IP-Adressen/Bereichen, von denen Anfragen kommen sollten oder nicht.

    Sie fragen sich jetzt: Warum verwenden Sie hierfür nicht einfach eine Netzwerk-Firewall? Schließlich ist es das, was sie tun. Vor Ort funktioniert das großartig. Wenn Sie jedoch Apps haben, die Sie in der öffentlichen Cloud schützen müssen, ist dies möglicherweise keine Option. Und wenn Sie zu den 59 % unserer Teilnehmer an unserer Umfrage „State of Application Delivery 2018“ gehören, die bereits in 2–6 verschiedene Cloud-Anbieter investiert haben, können Sie sich nicht darauf verlassen, dass die Netzwerk-Firewall-Richtlinien bei allen Anbietern dieselben sind. Während Sie natürlich dieselben Regeln in mehreren Clouds implementieren können, bedeutet die Durchsetzung von Regeln bei einer WAF, dass Sie dieselbe Richtlinie in derselben WAF in mehreren Umgebungen verwenden können. Konsistenz ist der Schlüssel zum Erfolg und Umfang der Sicherheit.
  • Optionen einschränken
    HTTP basiert auf einer Reihe von Headern, um der App-Plattform (und der App) mitzuteilen, was der Benutzer tun möchte. HTTP-METHODEN können beispielsweise zum Abrufen, Einfügen, Posten und Löschen von Ressourcen verwendet werden. Auch das OPTIONS-Feld verfügt über einen RFC-beschränkten Wertesatz, der problemlos von einer WAF gesteuert werden kann. Einige Schwachstellen – wie Optionsbleed – nutzen diese Felder aus. Um die Möglichkeit auszuschließen, solche Schwachstellen auszunutzen, können Sie mithilfe der WAF die möglichen Werte auf diejenigen beschränken, die Sie für die ordnungsgemäße Ausführung der Anwendung benötigen. In einigen Fällen schränkt die WAF diese Werte standardmäßig ein. Beispielsweise lässt BIG-IP ASM (F5 WAF) die HTTP OPTIONS-Methode standardmäßig überhaupt nicht zu.

Signaturen

Signaturen sind eine weitere Schutzmethode, die in vielen verschiedenen Sicherheitslösungen üblich ist. Antiviren- und Anti-Malware-Dienste basieren auf Signaturen, die es ihnen ermöglichen, schnell nach Hinweisen auf Viren und Malware zu suchen und diese zu kennzeichnen. Auch IPS/IDS und WAF verlassen sich stark auf diese Methode. Es gibt zwei Arten von Signaturen: benutzerdefiniert und vom Anbieter verwaltet.

  • Vom Lieferanten verwaltet
    Vom Anbieter verwaltete Signaturen werden normalerweise in einer „Datenbank“ gespeichert, die vom Anbieter automatisch gepflegt wird. Hierzu gehört die Aktualisierung der Datenbank, wenn neue Schwachstellen anhand einer eindeutigen, digitalen Signatur identifiziert werden können. Eine WAF prüft eine eingehende Anfrage anhand der Datenbank und reagiert entsprechend, wenn sie eine Übereinstimmung mit einer Signatur in der Datenbank findet. Signaturen können aus reinem Klartext bestehen, sind aber häufiger komplexe Kombinationen undurchsichtiger Zeichenfolgen, die Schadcode darstellen, der Remoteausführungsfunktionen auslöst oder die App-Plattform auf andere Weise beschädigt und Zugriff gewährt oder den Dienst verweigert.
  • Benutzerdefiniert
    Benutzerdefinierte Signaturen ermöglichen es Bedienern, schnell eine Signatur zur Datenbank hinzuzufügen. Diese Funktion ist wichtig, um eine schnelle Reaktion (in vielen Fällen Zero-Day) auf neue Sicherheitslücken zu gewährleisten und Sicherheitslücken zu beheben, für die noch keine vom Anbieter verwaltete Signatur ausgestellt wurde.

Inspektion

Schließlich ist eine Inspektion enthalten, um eine vollständige Kontrolle über Anfragen (und Antworten) zu gewährleisten. Durch die Überprüfung von Anfragen kann die WAF die Informationen in der Anfrage mit bekannten guten/schlechten Zeichenfolgen und Werten vergleichen, um zu ermitteln, ob die Anfrage böswillig oder legitim ist. Für HTTP-Anwendungen (und damit für die meisten Anwendungen im heutigen Internet) ist dies die wichtigste Funktion, die eine WAF bieten sollte. Wenn ein WAF keine programmierbare Inspektion bietet, sollten Sie diese Wahl noch einmal überdenken. Da HTTP textbasiert und erweiterbar ist, gibt es praktisch keine Möglichkeit, eine umfassende „Kontrollkästchen“-Liste mit Optionen und Methoden bereitzustellen, mit denen Sie Anforderungen überprüfen können. Nur sehr wenige HTTP-Header verfügen über eingeschränkte Optionen. Daher ist es sehr schwierig zu begrenzen, was in den Header gepackt werden kann und was nicht. Dies bedeutet, dass häufig eine Überprüfung erforderlich ist, um in Headern oder in der Nutzlast selbst eingebetteten Schadcode aufzuspüren. Es gibt zwei Möglichkeiten, die Überprüfung durchzuführen: bekannte Header und Nutzlast.

  • Bekannte Header
    Jede HTTP-Anfrage enthält eine Reihe klar definierter Header. Host, User-Agent, Content-Type usw. sind nahezu allgegenwärtig. Bei jedem handelt es sich lediglich um eine Textzeichenfolge mit einer so großen Kombinationsvielfalt, dass es schwierig ist, Werte auf eine Whitelist zu setzen. Stattdessen müssen diese einzeln auf bösartig wirkende Werte geprüft werden. Generell kann eine WAF die HTTP-Header sehr schnell analysieren und ihre Überprüfung ermöglichen. Sie stehen am Anfang jeder Anfrage und werden nachweislich für eine Vielzahl von Angriffen auf App-Plattformen verwendet: ApacheKillerOptionenanschnitt, Und Apache-Struts gehört zu den bekannteren Schwachstellen.
  • Nutzlastinspektion
    Bei der Payload-Inspektion handelt es sich um das, was der Name vermuten lässt: Sie prüft die gesamte Nutzlast – vom ersten bis zum letzten Byte – auf bekannte Kombinationen alphanumerischer Daten, die auf einen Versuch hinweisen, eine Schwachstelle auszunutzen. Mithilfe der Payload-Inspektion können Betreiber benutzerdefinierte HTTP-Header sowie den Hauptteil einer Anfrage auf bestimmte Hinweise auf böswillige Aktivitäten untersuchen. Dies erfordert, dass die WAF zunächst den gesamten Inhalt der Anfrage speichert. Dies ist notwendig, da Pakete nur eine begrenzte Datenmenge enthalten. Wenn sich die schädlichen Daten über zwei Pakete erstrecken, können sie von Diensten, die lediglich Paket für Paket prüfen, unbemerkt bleiben. Durch die Überprüfung der gesamten Nutzlast stellt eine WAF sicher, dass schädliche Daten, egal wo sie auftreten, aufgespürt und daran gehindert werden, ihr Ziel zu erreichen.

Eine WAF kann viel mehr als nur Schwachstellen beseitigen, um Anwendungen zu schützen. Viele beinhalten auch Bot-Erkennung, Ratenbegrenzung, DDoS-Prävention und mehr. Der Hauptzweck einer WAF besteht jedoch darin, Anwendungen durch die Beseitigung von Schwachstellen zu schützen. Obwohl SQLi, XSS und CSRF häufig erwähnt werden, sind diese mittlerweile fast schon „alter Hut“. Böse Akteure haben sich inzwischen nicht mehr nur auf die offensichtlichen Schwachstellen der Apps konzentriert, sondern zielen nun auf die Plattformen ab, da diese einen weitaus größeren Pool an Opfern bieten, aus denen sie schürfen können. Plattformschwachstellen – etwa in HTTP und seinen Frameworks – stellen eine zunehmende Quelle von Sicherheitsverletzungen dar, die durch den Schutz einer WAF der Enterprise-Klasse verbessert werden können.

Durch den Einsatz herkömmlicher Deny/Allow- und signaturbasierter Scans mit der Möglichkeit, eine vollständige Anfrage (und Antwort) zu überprüfen, bietet eine WAF den Schutz, den Unternehmen heute benötigen, um sich selbst und ihre Kunden zu schützen.