Drei Angriffe, die Sie mit sicherem Code nicht stoppen können

Bei Sicherheitsverletzungen im Zusammenhang mit Apps und der Offenlegung von Daten werden fast immer die Entwickler dafür verantwortlich gemacht. Oft ist dies die richtige Richtung. Injektionsangriffe und stapelbasierte Exploits sind fast immer das Ergebnis von unsicherem Code. Normalerweise, weil Sicherheitsregel Null verletzt wurde.

Allerdings können wir nicht für alle Sicherheitsverletzungen die Entwickler verantwortlich machen. Die Wahrheit ist: Selbst wenn Entwickler vollkommen sicheren Code schreiben könnten, bräuchten Sie dennoch Anwendungsdienste zum Schutz vor vielen anderen Angriffen.

Das liegt daran, dass Anwendungssicherheit ein Stapel ist . Bei manchen Angriffen werden Protokolle und Netzwerkprinzipien ausgenutzt, die sich nicht einfach durch „Sicherheitscodierung“ beseitigen lassen. Die Sicherheit wird dadurch zusätzlich erschwert, dass diese Angriffe von Anwendungen oft nicht erkannt werden, da ihnen die Sichtbarkeit fehlt, um böswillige von legitimen Anforderungen zu unterscheiden.

Insbesondere gibt es drei Angriffe, für deren Bewältigung die Entwickler einfach nicht verantwortlich sein sollten. Stattdessen lassen sich diese Angriffe am besten durch vorgelagerte Anwendungsservices erkennen und abschwächen, wo Transparenz und Kontext zur Verfügung stehen, um sie zu stoppen.

Volumetrischer DDoS-Angriff

Wir verwenden den Begriff volumetrisch zur Beschreibung eines herkömmlichen Distributed-Denial-of-Service-Angriffs, um die auf Netzwerküberlastung basierenden Angriffe von denen zu unterscheiden, die sich „im Stapel nach oben“ bewegt haben, um die Anwendungsschicht anzugreifen. Es handelt sich um unterschiedliche Angriffsklassen und wir müssen uns daher gegen beide verteidigen können. Die Art und Weise, wie wir dies tun, erfordert allerdings ganz unterschiedliche Lösungen.

Ein volumetrischer Angriff ist ein kurzer, heftiger Angriff. Dabei wird großer Datenverkehr gezielt auf einen Dienst gelenkt, um das Gerät, die Infrastruktur oder Software, die Anfragen verarbeitet, zu überlasten. Alle Geräte – ob Hardware oder Software, lokal oder in der Cloud – verfügen über begrenzte Ressourcen. Indem Sie viele Anfragen senden, überlasten Sie das Gerät und blockieren den Zugriff auf alle dahinterliegenden Systeme.

Entwickler können diesen Angriff nicht effektiv verhindern, weil Anwendungen auf Plattformen und Host-Betriebssysteme angewiesen sind, um die Netzwerkverwaltung zu übernehmen. Ein volumetrischer DDoS-Angriff fokussiert diesen Netzwerk-Stack und nutzt so viele gemeinsame Ressourcen, dass die Anwendung kaum noch Anfragen bearbeiten kann, um den Angriff zu erkennen.

Sichere Programmierung verhindert das nicht – es handelt sich nicht um einen Exploit aufgrund einer Sicherheitslücke. Und der Code in keinem Systemteil ist schuld daran. Fakt ist einfach: Egal wie sehr wir ignorieren wollen, dass Hardware existiert, von dort stammen Ressourcen – und diese sind begrenzt.

Volumetrische DDoS-Angriffe lassen sich am besten durch leistungsstarke Anwendungsdienste erkennen und abwehren, die einer Anwendung vorgelagert sind. Je näher an der Quelle des Angriffs, desto besser.

Kein Exploit, keine sichere Codierungslösung.

Schicht 7 DDoS

Wenn wir uns im Stapel nach oben zur Anwendungsebene bewegen, finden wir eine heimtückische Form der Dienstverweigerung namens Layer 7 (oder HTTP) DDoS. Diese Angriffe sind ärgerlich, weil es sich dabei um Exploits handelt, sie beruhen jedoch nicht auf einer Sicherheitslücke oder unsicherer Codierung. Diese Angriffe funktionieren aufgrund der Natur von HTTP und der Systeme, die es implementieren.

Man unterscheidet grundsätzlich zwei Arten von Layer-7-DDoS-Angriffen: langsam und schnell. Langsame Layer-7-DDoS-Angriffe zehren an Ressourcen, indem sie eine schlechte Netzwerkverbindung vortäuschen und die Antworten auf legitime Anfragen langsam abgreifen. Das belastet die Ressourcen, weil Web-Anwendungen verbindungsbasiert arbeiten und die Kapazitäten zur Aufrechterhaltung dieser Verbindungen begrenzt sind. Angreifer binden Anwendungsressourcen, indem sie viele Verbindungen zu Clients aufbauen und zwar legitime Anfragen stellen, jedoch die Antworten nur langsam entgegennehmen. Dadurch erschweren sie legitimen Nutzern den Zugriff so stark, dass effektiv ein Denial-of-Service-Angriff entsteht.

Dieser Angriff ist besonders heimtückisch und schwer zu erkennen – es sei denn, Sie vergleichen die Netzwerkgeschwindigkeit mit der Empfangsgeschwindigkeit. Das heißt, dass vorgelagerte Anwendungsdienste Einblick in die Netzwerkeigenschaften der Clients haben und genauer bestimmen können, ob diese Clients absichtlich langsame Empfangszeiten haben oder ob tatsächlich ein Netzwerkproblem vorliegt.  Um derartige Angriffe zu verhindern, ist es entscheidend, die Legitimität festzustellen.

Diese Angriffe greifen grundsätzlich die Protokollebene (HTTP) an und können durch sichere Codierung nicht verhindert werden.

Keine Schwachstelle, keine sichere Codierungslösung.

Credential Stuffing

Zu guter Letzt gibt es noch Credential Stuffing . Angesichts der unglaublichen Zahl an Anmeldeinformationen, die in den letzten Jahren durch Sicherheitsverletzungen offengelegt wurden, ist dieser Angriff ein sehr ernst zu nehmender Angriff, gegen den man sich verteidigen muss.

Credential-Stuffing-Angriffe basieren im Allgemeinen auf Bots oder Tools, da sie auf Brute-Force-Prinzipien beruhen, die die riesigen Pools vorhandener Benutzernamen-/Passwort-Dumps ausnutzen. Manuell ausgeführte Credential-Stuffing-Angriffe kommen nur selten vor. Ein erfolgreicher Credential-Stuffing-Angriff ist nicht das Ergebnis unsicherer Codierung*.  Angreifer versuchen, etwas anderes auszunutzen als schlechte Kennwortpraktiken und die Unfähigkeit, einen laufenden Angriff zu erkennen.

Um diese Angriffe zu erkennen, müssen Sie feststellen können, dass es sich bei dem Client nicht um einen Menschen handelt. In einer Art umgekehrtem Turing-Test müssen Sie Aufgaben stellen und CAPTCHAs auf eine Weise verwenden, die diese automatisierten Systeme nicht beantworten können.

Kein noch so sicheres Codieren kann den Erfolg dieses Angriffs verhindern. Die Verbesserung des Passwortgebrauchs und die Erkennung von Angriffsversuchen sind die besten Möglichkeiten, dieser wachsenden Plage des Internets nicht zum Opfer zu fallen.

Kein ausnutzbarer Code, keine sichere Codierungslösung.

*Credential-Stuffing-Angriffe können durch unsichere Codierung ermöglicht werden. Schließlich sind viele Sicherheitsverletzungen auf Schwachstellen im Code zurückzuführen, die dazu führen, dass für solche Angriffe riesige Listen mit Anmeldeinformationen zur Verfügung stehen.

Differenzieren, um zu erkennen und zu verteidigen

Es ist wichtig zu erkennen, wann ein Angriff durch sichere Codierung verhindert werden kann und wann nicht. Das ist wichtig, weil wir nicht für jeden erfolgreichen Angriff einfach mit dem Finger auf die Entwickler zeigen können. Sicherheit erfordert systemweites Denken. Wir benötigen mehrere Lösungen, da es mehrere Arten von Angriffen gibt, gegen die wir uns verteidigen müssen.

Um die Vielzahl der Angriffe, denen die meisten Organisationen in naher Zukunft ausgesetzt sein werden, wirksam und erfolgreich abwehren zu können, ist eine Differenzierung wichtig. Verschwenden Sie keine Zeit damit, Entwickler zur Abwehr von Angriffen zu zwingen, wenn es sich (1) aufgrund unsicherer Codierung nicht um einen Exploit handelt oder (2) aufgrund mangelnder Transparenz nicht möglich ist.

Wir müssen das Thema Sicherheit strategisch auf der Grundlage eines Servicesystems angehen, das die richtige Sicherheit an den richtigen Stellen bietet, unabhängig von der Quelle oder Angriffsfläche.

Bleib sicher.