No WAFs

Ihr Security-Team hat Ihnen gerade ein düsteres Bild möglicher Cyber-Bedrohungen gezeichnet, und Ihnen ist klar: Ihre Web-Anwendung ist ein Minenfeld voller Schwachstellen. Diese Sicherheitslücken zu schließen, scheint eine Aufgabe zu sein, die irgendwo zwischen ewig und nie dauert.

WAF – nicht das, was Sie sich erhofft haben

Aber halt! Es gibt eine Lösung: eine Web Application Firewall (WAF), die gängige Schwachstellen wie Injection-Angriffe und Distributed Denial of Service (DDoS) abfängt. Ganz ohne Code-Änderungen. Sie leiten einfach den gesamten Web-Traffic an die WAF; sie inspiziert alle HTTPS-Requests und blockiert die gefährlichen.

WAFs prüfen alle HTTPS-Requests an Ihre Web-Anwendung und blockieren alles, was verdächtig wirkt. Sie entschlüsseln HTTPS-Requests und durchsuchen Header und Body nach potenziellen Bedrohungen, um anhand von Inhalt, IP-Adresse oder Request-Mustern zu blockieren.

Zusätzlich schützen WAFs vor DDoS-Angriffen, indem sie plötzliche Traffic-Spitzen abfangen. Das funktioniert über einfache Regeln wie die Request-Rate und die Quell-IP-Adressen. Alternativ können WAFs künstliche Intelligenz einsetzen, um die für DDoS-Angriffe typischen Zugriffsmuster zu erkennen und zu blockieren.

Tun Sie es nicht.

Die WAF ist ein Fehler. Hier sind einige Gründe dafür:

Sie blockieren Ihre eigene App

WAFs können legitime Nutzer am Zugriff auf Ihre Web-Anwendung hindern, weil sie normales Verhalten fälschlich als Angriff einstufen. Tatsächlich verlangt Ihre Web-App ziemlich wahrscheinlich Eingaben, die "verdächtige" Zeichenfolgen enthalten – und die regulären Ausdrücke schlagen darauf fälschlich an: Wenn Ihre App etwa technische Kunden bedient, sind möglicherweise JavaScript-Snippets im Spiel, die wie ein Angriff aussehen. Schlimmer noch: Ihre App kann grundsätzlich gefährliche Eingaben sogar benötigen: Wenn sie zum Beispiel HTML aus einer Rich-Text-Web-Editor-Komponente entgegennimmt und direkt rendert, dann kann ich Ihnen sagen, was Sie ohnehin schon wissen: Sie könnten und sollten die Strings escapen, statt das Äquivalent eines Angriffs herumzureichen. Aber solche Schwächen, einmal entstanden, wieder auszumerzen, ist schwer – und solange Sie kein Team dafür abstellen können, macht die WAF Ihre Web-App unbenutzbar.

Beim DDoS-Schutz blockiert die WAF plötzliche Traffic-Anstiege – aber das lädt geradezu zur schlimmsten Sorte False Positive ein: nämlich genau dann, wenn Ihre App viral geht und Ihre Besucher die Web-App nicht nutzen können. Genau hier kann das fortgeschrittene, mit Machine Learning (ML) gestützte Filtern der WAF helfen. Es ist nicht perfekt, aber besser als die musterbasierten Ansätze der meisten WAF-Filter.

Einzelne IP-Adressen zu blockieren ist offensichtlich zu kleinteilig, also blockiert man als Nächstes ganze Länder und schließt damit Kunden eines kompletten Landes aus. Vielleicht bedienen Sie heute keine Kunden in diesem Land – mit der WAF verbauen Sie sich aber auch die Chance, neue Märkte zu entdecken.

Der empfohlene Weg im Umgang mit False Positives ist, die WAF im Dry-Run-Modus zu betreiben: Statt zu blockieren, schreibt sie verdächtige Eingaben ins Log. Anschließend analysieren Sie die Logs auf False Positives und lockern entweder die Regeln (und ignorieren damit potenziell echte Angriffe) oder beheben Ihren Code (was Sie aber schon seit Jahren vor sich herschieben). Ich habe Organisationen gesehen, die ihre WAF zwei Jahre lang im Dry-Run laufen ließen – aus durchaus berechtigter Angst, die Funktionalität ihrer eigenen App zu zerstören. Sie haben damit ihre App verlangsamt, keinerlei Sicherheitsgewinn erzielt – und Zehntausende Dollar an Lizenzgebühren bezahlt, ohne je einen Sicherheitsnutzen zu sehen.

Angriffe rutschen durch

Die Vielfalt möglicher neuer Angriffe übersteigt die Fantasie von WAF-Entwicklern und auch Ihre eigene – nicht aber die der Hacker. Damit bleibt Ihnen das Spiegelbild des False Positive: das False Negative, also echte Angriffe, die durchgelassen werden.

Reguläre Ausdrücke, die häufigste Methode zum Filtern von Text, sind in dem, was sie erkennen können, begrenzt. Sie müssen für spezifische Angriffe vordefiniert sein und für schnelle Verarbeitung einfach gehalten werden. Aus Geschwindigkeitsgründen werden nur die ersten Kilobyte von HTTP-Header und -Body gescannt; und selbst wenn Sie diesen Wert erhöhen, gibt es immer eine Grenze, jenseits derer Angriffe durchgelassen werden.

Auch das Blockieren von IP-Adressen ist eine Quelle von False Negatives, denn Angreifer können über Proxies problemlos auf neue IP-Adressen ausweichen.

Die Hauptquelle von Angriffen, gegen die WAFs nichts ausrichten können, liegt in der Logik Ihrer eigenen Anwendung. Wenn eine Seite eigentlich passwortgeschützt sein sollte und es nicht ist, oder wenn die Autorisierung einem Benutzer Schreibzugriff erlaubt, obwohl nur Lesezugriff vorgesehen war, liegt das an Ihnen. Niemand erwartet von WAFs, solche Schwachstellen zu finden – aber sie machen umso deutlicher, dass der entscheidende Ort für Web-Sicherheit Ihr eigener Code ist.

Flexibilität?

Während Sie sich durch False Positives und False Negatives kämpfen, ist es verlockend, die Regeln nachzujustieren, präzise auf Ihre Bedürfnisse zuzuschneiden oder gleich eigene zu bauen. Lassen Sie es bleiben.

Sicherheitsexperten haben die Angriffsarten, die Hacker nutzen, längst erforscht. Hacker werden für Sie keine speziellen Angriffe erfinden – und falls doch, werden Sie es ebenfalls nicht im Voraus wissen. Die Schwachstellen Ihrer App sind ziemlich sicher dieselben, die in den Standard-Regelwerken bereits abgedeckt sind. Sollte Ihre App tatsächlich so besondere Schwächen haben, dass Sie eigene Schutzregeln diagnostizieren und schreiben müssten, sollten Sie diese Entwicklungszeit lieber nicht ins Pflaster, sondern in die App selbst stecken.

Die Balance zwischen Accuracy und Recall – False Negatives vs. False Positives – auszutarieren, ist selbst für Experten schwer bis unmöglich. Sie definieren Schutzstufen, damit Sie den Trade-off zwischen False Positives und False Negatives selbst wählen können. Dieses Gleichgewicht gegen Millionen potenzieller künftiger Web-Requests feinzujustieren, lohnt sich nicht.

Zusätzliches Risiko

Diese Nachteile machen WAFs unterm Strich meist zum Minusgeschäft. Mehr noch: WAFs selbst können ein Sicherheitsrisiko sein. Sie müssen HTTPS entschlüsseln, um die Daten zu inspizieren – ein weiterer potenzieller Punkt für Datenlecks. Der WAF-Code selbst kann Schwachstellen haben. Außerdem können sie die Kommunikation verlangsamen, da jeder Request durch sie hindurchläuft.

Allzu oft entscheiden sich Manager trotz all dieser Fakten dennoch für eine WAF – als Übergangslösung, mit dem Vorsatz, Sicherheitslücken später zu beheben. Aber sobald die WAF einmal steht, wird das Team bequem, solide Sicherheitspraktiken werden nie etabliert, und der Anwendungscode wird immer unsicherer. Währenddessen liefert die WAF die vermeintliche Sicherheit gar nicht.

Trotz dieser Nachteile gibt es Situationen, in denen der Einsatz einer WAF sinnvoll sein kann – auch wenn Sie sicherheitstechnisch trotzdem nicht viel davon haben:

Wenn eine externe Anforderung eine WAF vorschreibt – etwa eine Ausschreibung eines Kunden oder eine Branchenregulierung, die einen formalen Sicherheitsstandard verlangt –, dann führen Sie sie natürlich ein: Die WAF ist notwendig, aber nicht aus Sicherheitsgründen.

Wenn Sie eine Drittanbieter-Web-App betreiben, die Sie nicht selbst entwickelt haben und nicht reparieren können, ist eine WAF unter Umständen Ihr einziger Weg, zumindest etwas Sicherheit hinzuzufügen. Sie riskieren auch hier, sich in falscher Sicherheit zu wiegen, aber zumindest entfernen Sie sich in diesem Fall nicht noch weiter von guten Entwicklungspraktiken.

Es gibt allerdings einen guten sicherheitstechnischen Grund, eine WAF zu nutzen: DDoS-Schutz. Wenn ein Denial-of-Service-Angriff massiven Traffic schickt, kann Ihre WAF Angriffe erkennen und blockieren. Die Erkennung von Angriffsmustern per ML liefert dabei eine gute Trefferquote.

Für noch besseren DDoS-Schutz lohnt sich bei den größten Web-Apps zusätzlich ein Team menschlicher Experten, das im Ernstfall reagiert – etwa Google Cloud Armor Managed Protection und AWS Shield Advanced.

Viele Kunden melden sich erst dann dringend, um DDoS-Schutz – sei es eine WAF oder ein Expertenteam – einzukaufen, wenn der Angriff bereits läuft und keine Zeit mehr bleibt. Sorgen Sie lieber vorher dafür.

Wenn Sie eine WAF einsetzen, dann die Ihres Cloud-Anbieters: Google Cloud Armor oder AWS Shield. Bei den Cloud-Diensten zahlen Sie nutzungsbasiert, statt sich an eine teure monatliche Gebühr für ein Produkt zu binden, das Sie womöglich gar nicht ernsthaft einsetzen. Außerdem fließen die Daten ohnehin durch die Cloud, und in vielen Architekturen entschlüsseln Cloud-Dienste Ihre Daten sowieso – ein WAF-Service Ihres Cloud-Anbieters minimiert daher die Auswirkungen auf Performance, Sicherheit und Datenschutz.

Dieser Artikel von Mac Chaffee und dieser StackExchange-Thread liefern wertvolle technische Details zu diesen Punkten.