Aufbau einer Defense-in-Depth-Sicherheitsstrategie für Webanwendungen

Cyberangriffe nehmen zu und Regierungen drängen sowohl Bürger als auch Unternehmen dazu, ihre Sicherheitsvorkehrungen zu überprüfen und zu verbessern. Daher stellen sich viele Kunden die Frage, welche Maßnahmen sie heute ergreifen können, um ihre Webanwendungen bestmöglich zu schützen. Es gibt zwar kein Patentrezept, um alle Angriffe zu stoppen, dafür aber eine Reihe von Best Practices, die im Rahmen einer Defense-in-Depth-Strategie eingesetzt werden können, um deren Auswirkungen zu begrenzen.

In diesem Blogpost erfahren Sie, welche Schritte Sie unternehmen können, um Ihre Anwendungen auf mehreren Ebenen zu schützen. Zuallererst wollen wir uns aber ansehen, wie Sie die Angriffsmöglichkeiten von vornherein einschränken können. 

Bestandsaufnahme der Angriffsflächen und der von den Anbietern bereitgestellten Schutzmaßnahmen

Zunächst einmal ist es hilfreich, sich über die zahlreichen Schritte Gedanken zu machen, die ein Client beim Senden und Empfangen von Informationen während einer typischen Anfrage einer Webanwendung durchläuft. Die meisten von uns betrachten zum Beispiel die Eingangstür als Angriffsfläche ihres Hauses. Man sollte aber auch die Fenster, die Zufahrt, die Wasserleitung und den Telefonmast an der Straße berücksichtigen. Analog dazu sind auch Komponenten, die die Verfügbarkeit einer Anwendung für die dafür vorgesehenen Nutzer verhindern könnten, bedroht.

Betrachtet man diese Komponenten einer Webanfrage der Reihe nach, muss in der DNS-Phase zunächst der Domain-Name in eine IP-Adresse aufgelöst werden. Anschließend wird eine Verbindung zur IP-Adresse hergestellt und eine HTTP-Anfrage gesendet. In der Regel ist diese IP-Adresse an einen Reverse Proxy wie ein CDN oder einen Loadbalancer gebunden. Schließlich muss der Reverse Proxy eine Anfrage an ein Origin-Netzwerk stellen, in dem sich die Originalversion der Inhalte befindet. Und all diese Komponenten müssen geschützt werden.

In allen drei Phasen ist es notwendig, dass das gesamte OSI- (Open Systems Interconnect) oder TCP/IP-Verbindungsmodell durchlaufen wird, um eine Datenverbindung, eine Verbindung, eine Sitzung und schließlich eine vollständige Anfrage zu erstellen. Vereinfacht kann man sich das so vorstellen:

Aus Sicherheitssicht handelt es sich bei all diesen Punkten um kritische Funktionen, die angegriffen werden können. Um ihre Verfügbar zu gewährleisten, ist es wichtig, überall Schutzmaßnahmen zu haben und zu wissen, welche Schutzmaßnahmen Ihr Anbieter für Sie getroffen hat. 

Beispiele für solche Schutzmaßnahmen sind: verteilte DNS, global verteilte CDNs zum Cachen von Inhalten, Rate Limiting zur Durchsetzung von Geschwindigkeitsbegrenzungen mit unterschiedlichen Identifiern, die eine Umgehung erschweren, und eine robuste WAF im Blocking Mode. Wir stellen uns diese Schutzmaßnahmen wie einen Trichter vor, wobei die einzelnen Schutzebenen zu einer umfassenden Sicherheitsstrategie für die Infrastruktur führen. Im weiteren Verlauf dieses Blogposts werden wir genauer auf die einzelnen Segmente und Schutzmaßnahmen eingehen.

Schutz auf jedem Layer 

Schutzmaßnahmen auf dem Infrastruktur-Layer

Bei der überwiegenden Mehrheit moderner Webanwendungen haben sich Unternehmen dafür entschieden, alle drei der oben beschriebenen Phasen einer Webanfrage an Cloud-Anbieter auszulagern, anstatt eigene Netzwerke zu betreiben. Da DNS aber als erste Phase einer Webanfrage ein häufiges Angriffsziel ist, ist es ratsam, mehrere DNS-Anbieter zu nutzen, um größtmögliche Verfügbarkeit zu gewährleisten. Wir empfehlen unseren Kunden auch, einen Reverse-Proxy wie ein CDN vor einen möglichst großen Teil ihres Traffics zu schalten und nur Traffic von ausgewählten IP-Adressen wie diesen Proxys zum Origin-Server durchzulassen, um direkte Angriffe auf das Origin-Netzwerk zu vermeiden. Als weitere Maßnahme lässt sich auch die Funktion des Origin-Servers an sich an einen Cloud-Anbieter oder mehrere Anbieter auslagern, wobei das Loadbalancing über das vorgeschaltete CDN erfolgt.Damit liegt die Hauptverantwortung für den Schutz des Origin-Netzwerks beim Anbieter und nicht bei Ihrem eigenen Team.

Sobald diese Maßnahmen umgesetzt sind, müssen sich einzelne Website- oder Anwendungsbetreiber nicht mehr direkt um die Abwehr von Angriffen auf die unteren Layer, wie UDP-Amplifikation oder TCP-SYN-Floods, kümmern. Der Schutz dieser Layer wird nämlich von den Anbietern übernommen. Fastly verfügt beispielsweise über ein großes globales Netzwerk mit großer Bandbreite, Abwehrfunktionen und ein Team von Netzwerkspezialisten, das unsere Infrastruktur ständig überwacht, um für unsere Kunden sofort auf Angriffe wie diese zu reagieren.

Kunden, die ihre eigenen Netzwerke betreiben, verfügen oft über Scrubbing-Funktionen ihres ISPs oder anderer Anbieter, die eine IP-Adresse aus BGP umleiten, bösartigen Traffic herausfiltern und an das Origin-Netzwerk zurückleiten können. Mit diesem Service lassen sich die oben genannten Access Control Lists auch bei Traffic-Spitzen durchsetzen.

Schutzmaßnahmen auf dem Anwendungs-Layer

Da die Kerninfrastruktur nun geschützt ist, können sich die Betreiber auf „protokollinterne“ oder auf dem OSI-Modell basierende Layer-7-Angriffe konzentrieren, also auf Angriffe, die echte Nutzeranfragen an die Anwendung simulieren.

Angriffe auf Anwendungen können zweierlei Formen annehmen. Die Erste davon ist eine Art Fortsetzung des Infrastrukturangriffs, bei dem es zu einer Traffic-Flut durch Anfragen kommt, die den typischen Kundenanfragen ziemlich ähnlich sind. Das Ziel des Angriffs könnte beispielsweise darin bestehen, die Anwendung so sehr zu überlasten, dass sie keine legitimen Anfragen mehr bearbeiten kann (Denial of Service), oder aber darin, Daten, Geld oder Inventar zu erlangen.

Bei der zweiten Form des Angriffs handelt es sich um eine gezielte Anfrage, die selbst böswillig ist, da das Ziel letztlich darin besteht, die Kontrolle über die Systeme einer Anwendung zu übernehmen. SQL Injection (SQLi), Befehlsausführung (CMDEXE), Cross Site Scripting (XSS), Zugriffsversuche auf Admin-Seiten und Anfragen unter Ausnutzung der Log4j-Schwachstelle sind allesamt Paradebeispiele für diese Art von Angriffen.

Achtung auf Sicherheitslücken 

Durch die Verbreitung von internetbasierten Geräten und groß angelegten Botnetzen ist es inzwischen einfacher denn je, ein System mit Protokollangriffen zu überfluten. Auch der zunehmende Reifegrad solcher Angriffe bietet Aufschluss darüber, wie diese Angriffe aussehen könnten. Im Folgenden erfahren Sie, wie ich diese Entwicklung sehe und wie Sie Ihre Anwendungen schützen können:

Auslieferung aus dem Cache

Im einfachsten Fall kann jemand dieselbe Ressource milliardenfach anfragen und versuchen, die Systeme, auf denen diese Ressource bereitgestellt wird, zu überlasten. Alleine indem Sie sicherstellen, dass möglichst viele Ressourcen aus dem Cache bedient werden, können Sie die Auswirkungen dieser Angriffsform verringern. Passive Vorteile wie Request Collapsing und Abschirmung, die hohe Cache-Hitraten ermöglichen und das Traffic-Volumen in Richtung des Origin-Servers verringern, können sich als besonders hilfreich erweisen, wenn Anfragen von Bots und nicht von echten Nutzern stammen. Darüber hinaus können aktive Bemühungen, die Cache-Abdeckung zu erhöhen, zum Beispiel durch das Ordnen und Bereinigen von Anfrageparametern, so viele Inhalten wie möglich im Cache halten. Die Bereitstellung von Traffic aus dem Cache ist oft die Möglichkeit, einen Angriff auf eine protokollinterne Anwendung zu beheben, die am wenigsten Rechenleistung beansprucht und die geringsten Kosten verursacht.

Hohe Raten, hohes Risiko

Die nächste Entwicklungsstufe von Angriffen besteht darin, die URL ganz einfach so zu verändern, dass sie einen zufälligen Hash darstellt, oder andere Anfrageparameter so zu verändern, dass ein Cachen unmöglich wird. Auf diese Weise wird ein großes Traffic-Volumen mit hoher Geschwindigkeit zurück zum Origin-Server gesendet. Zusammenfassend lassen sich solche Angriffe als „Cache Busting HTTP Floods“ bezeichnen.

Beim Edge Rate Limiting wird die Gesamtrate des Traffics anhand eines Client Identifiers betrachtet. Ein Angreifer kann zwar die IP-Adresse, den User Agent, das Netzwerk usw. verändern, es können aber mehrere Richtlinien gemeinsam verwendet werden, um allgemeine Geschwindigkeitsbegrenzungen für den Traffic auf Grundlage des typischen Traffic-Profils für eine Website festzulegen. Solche Richtlinien könnten zum Beispiel bis zu 100 RPS pro IP-Adresse, 100 RPS pro User-ID oder 500 RPS pro Netzwerk (z. B. ASN) zulassen.Das Ziel besteht nicht darin, den Angriff vollständig zu unterbinden, sondern den Traffic so gering zu halten, dass die nachgelagerten Systeme in der Lage sind, das Volumen zu bewältigen. 

Allmählich und schleichend

Nicht jeder Angreifer wählt den Brute-Force-Ansatz. Um möglichst unauffällig zu bleiben, verstecken sie sich oft hinter einem geringeren Datenvolumen und greifen lieber langsame und weniger zentrale Komponenten an, während sie sich darauf verlassen, dass die Probleme, die sie verursachen, in den Backend-Systemen zu spüren sind. Wenn ein Angreifer eine API findet, die Datensätze in großem Umfang verändern kann, oder eine Authentifizierungsanfrage stellt, die mehrere Systeme beansprucht, könnte er sich also darauf verlassen, dass die Anwendung seine Angriffskraft verstärkt. Ebenso wollen Angreifer auf der Suche nach anfälligen Systemen das Volumen so gering halten, dass sie nicht auffliegen. 

Für eine genauere Kontrolle bietet Rate Limiting für Anwendungen chirurgische Präzision bei niedrigvolumigen Angriffen. So lässt sich beispielsweise leicht eine Regel erstellen, die IP-Adressen auf fünf Anfragen innerhalb einer Minute an eine Liste von API-URLs beschränkt. Die Logik kann aber auch sehr anspruchsvoll sein, zum Beispiel beim Rate Limiting nur für bestimmte Quellen (wie ausländische Quellen oder TOR-Knoten) oder beim Ausschluss von Listen mit bekanntermaßen unbedenklichen Anfragequellen. Es ist in der Regel nicht empfehlenswert, sämtliche Anfragen aus einem bestimmten Land zu blockieren, es sei denn, dies ist ausdrücklich gesetzlich vorgeschrieben. Vielmehr ist es oft besser, das Volumen und die Akzeptanz von Anfragen aus risikoreicheren Regionen, in denen Ihr Unternehmen gegenwärtig nicht tätig ist, strenger zu kontrollieren.

Der lästige Kleinkram

Wenn die verschiedenen Arten von Flood-Traffic herausgefiltert werden, verbleiben die böswilligen Anfragen, die selbst bei kleinsten Anfragevolumina schwerwiegende Auswirkungen haben können. Viele dieser Angriffsarten sind in der Liste der wichtigsten Angriffe der OWASP Foundation definiert und können als Abkürzung für bösartige Webanfragen verwendet werden. Darüber hinaus gibt es einzelne Angriffe, die sich Common Vulnerabilities and Exposures (CVEs) bedienen, um Schwachstellen in Anwendungen auszunutzen. Neben dem Patchen und Verwalten kritischer Schwachstellen war es bisher die Aufgabe einer Web Application Firewall (WAF), den eingehenden Traffic daran zu hindern, die Schwachstelle selbst anzugreifen.

Bei einer herkömmlichen WAF ist es ratsam, sicherzustellen, dass die WAF-Regeln im Blocking Mode sind und so viele Ressourcen wie möglich abdecken, um den Schutz zu maximieren. Next-Gen WAF-Lösungen bieten jedoch den Vorteil einer verbesserten Sprachverarbeitung, um bösartige Anfragen besser zu erkennen und False Positives zu vermeiden. Darüber hinaus nutzt unsere Next-Gen WAF Schwellenwerte, die sicherstellen, dass sowohl die Angriffsklassifizierung als auch die Geschwindigkeit des Angriffs berücksichtigt werden, bevor Anfragen abgelehnt werden. Dadurch sinkt die Wahrscheinlichkeit, dass eine „subjektiv harmlose“ Anfrage blockiert wird, zum Beispiel, wenn ein Mitarbeiter Code in ein CMS eingibt, der zufällig ein Angriffssignal darstellt. In Kombination ermöglicht dies die Anwendung von WAFs auf eine größere Anzahl von Assets bei gleichzeitiger präziser Blockierung in der Produktivumgebung. Wie bereits erwähnt, setzen die Rate-Limiting-Funktionen Grenzen für den Traffic durch, die über die typische Rolle einer herkömmlichen WAF hinausgehen.

Ihre allgemeine Sicherheitsstrategie

Alle in diesem Blogpost behandelten Themen, wie die Nutzung von WAFs und CDNs, sollten als Teil einer ganzheitlichen, umfassenden Sicherheitsstrategie betrachtet werden. Rollenbasierte Zugriffskontrollen und eine Multi-Faktor-Authentifizierung (MFA) über ein zentrales Authentifizierungssystem können die Sicherheit der Nutzer gewährleisten und unbefugte Zugriffe auf Sicherheitssysteme abwehren.Eine WAF ist auch kein Ersatz für die Einhaltung bewährter Praktiken beim Schwachstellenmanagement und das aktive Scannen der an einer Anwendung vorgenommenen Änderungen. 

Die überwiegende Mehrheit des Traffics im öffentlichen Internet basiert jedoch auf HTTP(S). Die in diesem Blogpost vorgestellten Methoden spiegeln einige der häufigsten Herausforderungen für die Cybersicherheit von Webanwendungen wider. Stellen Sie gemeinsam mit Partnern Ihres Vertrauens sicher, dass Systeme zum Schutz Ihrer Anwendung vorhanden sind, bevor ein Angriff erfolgt. Unsere Technologie- und Support-Teams unterstützen Sie bei der Implementierung dieser Technologien und helfen Ihnen, sich so gut wie möglich zu schützen. Kontaktieren Sie uns für Unterstützung und weitere Informationen.