Drei Angriffe, die sich durch sichere Programmierung nicht verhindern lassen

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Wenn es um Sicherheitsverletzungen bei Apps und die Offenlegung von Daten geht, wird fast immer mit dem Finger auf die Entwickler gezeigt. In vielen Fällen ist das auch berechtigt. Injection-Angriffe und Stack-basierte Exploits sind fast immer auf unsicheren Code zurückzuführen. Meistens, weil gegen Sicherheitsregel Null verstoßen wurde.

Aber wir können nicht alle Sicherheitsverletzungen den Entwicklern anlasten. Selbst wenn Entwickler vollkommen sicheren Code erstellen könnten, wären weiterhin Anwendungsdienste zum Schutz vor vielen anderen Angriffen erforderlich.

Das liegt daran, dass Anwendungssicherheit aus mehreren Ebenen besteht. Manche Angriffe nutzen Protokolle und Netzwerkprinzipien aus und lassen sich nicht einfach durch „sicheren Code“ verhindern. Erschwerend kommt hinzu, dass Anwendungen solche Angriffe häufig nicht erkennen können, da ihnen die nötige Transparenz fehlt, um bösartige von legitimen Anfragen zu unterscheiden.

Insbesondere gibt es drei Angriffe, für deren Abwehr Entwickler schlichtweg nicht verantwortlich sein sollten. Stattdessen lassen sich diese Angriffe am besten durch vorgelagerte Anwendungsdienste erkennen und abwehren, da dort die nötige Transparenz und der erforderliche Kontext vorhanden sind, um sie zu stoppen.

Volumetrische DDoS-Angriffe

Wir verwenden den Begriff „volumetrisch“ zur Beschreibung eines herkömmlichen Distributed-Denial-of-Service-Angriffs, um Angriffe, die auf einer Überlastung des Netzwerks basieren, von solchen zu unterscheiden, die sich im Stack nach oben verlagert haben und die Anwendungsschicht angreifen. Es handelt sich um unterschiedliche Angriffsklassen, weshalb wir uns gegen beide schützen können müssen. Dafür sind jedoch sehr unterschiedliche Lösungen erforderlich.

Ein volumetrischer Angriff ist nichts anderes als ein massiver Ansturm. Dabei wird eine bestimmte Dienstleistung mit einer Flut von Datenverkehr bombardiert, um das Gerät, die Infrastruktur oder die Software, die die Anfragen verarbeitet, zu überlasten. Das zugrunde liegende Prinzip besteht darin, dass alle Systeme – ob Hardware oder Software, lokal oder in der Cloud – nur über begrenzte Ressourcen verfügen. Werden genügend Anfragen gesendet, kann das System daher überlastet werden und den Zugriff auf alle dahinterliegenden Ressourcen blockieren.

Der Grund, warum Entwickler diesen Angriff nicht wirksam verhindern können, liegt darin, dass Anwendungen bei der Verwaltung des Netzwerkverkehrs auf Plattformen und Host-Betriebssysteme angewiesen sind. Ein volumetrischer DDoS-Angriff zielt auf diesen Netzwerk-Stack ab und kann so viele der gemeinsam genutzten Ressourcen beanspruchen, dass die Anwendung kaum noch in der Lage ist, Anfragen zu verarbeiten und festzustellen, dass sie angegriffen wird.

Sichere Programmierung kann dies nicht verhindern – es handelt sich nicht um die Ausnutzung einer Schwachstelle. Und tatsächlich ist auch nicht der Code irgendeines Teils des Systems dafür verantwortlich. Es ist schlicht so: So sehr wir auch versuchen, so zu tun, als gäbe es keine Hardware – von ihr stammen die Ressourcen, und diese sind begrenzt.

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

Kein Exploit, keine Lösung durch sichere Programmierung.

Layer-7-DDoS

Wenn wir uns im Protokollstapel nach oben zur Anwendungsschicht bewegen, stoßen wir auf eine heimtückische Form der Dienstverweigerung, die als Layer-7- (oder HTTP-)DDoS bezeichnet wird. Diese Angriffe sind besonders ärgerlich, da sie zwar Schwachstellen ausnutzen, jedoch nicht auf eine Sicherheitslücke oder unsichere Programmierung zurückzuführen sind. Sie funktionieren vielmehr aufgrund der Beschaffenheit von HTTP und der Systeme, die es implementieren.

Im Allgemeinen gibt es zwei Arten von Layer-7-DDoS-Angriffen: langsame und schnelle. Bei langsamen Layer-7-DDoS-Angriffen werden Ressourcen beansprucht, indem eine äußerst schlechte Netzwerkverbindung vorgetäuscht wird und die Antworten auf legitime Anfragen g a n z l a n g s a m abgerufen werden. Dies bindet Ressourcen, da Webanwendungen verbindungsbasiert arbeiten und die zur Aufrechterhaltung dieser Verbindungen verfügbaren Ressourcen begrenzt sind. Indem Angreifer Verbindungen mit genügend Clients herstellen, legitime Anfragen senden und die Antworten darauf nur langsam abrufen, können sie die Ressourcen der Anwendung blockieren. Dadurch wird es legitimen Clients nahezu unmöglich, eine Verbindung herzustellen, was faktisch einem Denial-of-Service-Angriff gleichkommt.

Dieser Angriff ist besonders heimtückisch und schwer zu erkennen – es sei denn, man vergleicht die Netzwerkgeschwindigkeit mit der Empfangsgeschwindigkeit. Vorgelagerte Anwendungsdienste haben Einblick in die Netzwerkeigenschaften der Clients und können daher genauer feststellen, ob diese absichtlich langsam Daten empfangen oder tatsächlich ein Netzwerkproblem haben. Die Feststellung, ob es sich um legitime Clients handelt, ist entscheidend, um derartige Angriffe abzuwehren.

Im Grunde nutzen diese Angriffe Schwachstellen auf der Protokollebene (HTTP) aus, und durch sichere Programmierung lässt sich nichts dagegen ausrichten.

Keine Schwachstelle, keine Lösung durch sichere Programmierung.

Credential Stuffing

Zu guter Letzt ist da noch das Credential Stuffing. Die unglaubliche Anzahl an Zugangsdaten, die in den vergangenen Jahren durch Datenschutzverletzungen offengelegt wurden, macht diesen Angriff zu einer ernst zu nehmenden Bedrohung, gegen die man sich schützen muss.

Credential-Stuffing-Angriffe stützen sich in der Regel auf Bots oder Tools, da sie auf Brute-Force-Prinzipien basieren und die riesigen Mengen vorhandener Datensätze mit Benutzernamen und Passwörtern ausnutzen. Credential-Stuffing-Angriffe werden nur selten manuell durchgeführt. Ein erfolgreicher Credential-Stuffing-Angriff ist nicht das Ergebnis unsicherer Programmierung*. Die Angreifer nutzen lediglich schlechte Passwortpraktiken und die mangelnde Fähigkeit aus, einen laufenden Angriff zu erkennen.

Um diese Angriffe zu erkennen, müssen Sie feststellen können, dass es sich beim Client nicht um einen echten Menschen handelt. In einer Art umgekehrtem Turing-Test müssen Sie daher Aufgaben stellen und CAPTCHAs so einsetzen, dass diese automatisierten Systeme sie nicht lösen können.

Auch noch so sichere Programmierung kann den Erfolg dieses Angriffs nicht verhindern. Bessere Passwortpraktiken und die Erkennung von Angriffsversuchen sind die besten Möglichkeiten, um dieser wachsenden Plage des Internets nicht zum Opfer zu fallen.

Kein ausnutzbarer Code, keine Lösung durch sichere Programmierung.

*Credential-Stuffing-Angriffe können durch unsichere Programmierung ermöglicht werden. Schließlich ist eine beträchtliche Anzahl von Sicherheitsverletzungen auf Schwachstellen im Code zurückzuführen, durch die umfangreiche Listen mit Zugangsdaten für diese Angriffe verfügbar werden.

Unterscheiden, um Angriffe zu erkennen und abzuwehren

Es ist wichtig zu erkennen, wann sich ein Angriff durch sichere Programmierung verhindern lässt und wann nicht. Das ist deshalb wichtig, weil wir nicht bei jedem erfolgreichen Angriff einfach den Entwicklern die Schuld geben können. Sicherheit erfordert ein Denken auf Systemebene; wir brauchen mehrere Lösungen, da wir uns gegen unterschiedliche Arten von Angriffen schützen müssen.

Es ist wichtig, hier zu differenzieren, um sich wirksam und erfolgreich gegen die Vielzahl von Angriffen zu schützen, denen die meisten Unternehmen in naher Zukunft ausgesetzt sein werden. Verschwenden Sie keine Zeit damit, Entwickler dazu zu drängen, Angriffe abzuwehren, wenn es sich dabei (1) nicht um die Ausnutzung unsicherer Programmierung handelt oder (2) dies aufgrund mangelnder Transparenz nicht möglich ist.

Wir müssen Sicherheit strategisch angehen und dabei auf ein System von Diensten setzen, das an den richtigen Stellen für angemessene Sicherheit sorgt – unabhängig davon, um welche Quelle oder Angriffsfläche es sich handelt.

Bleiben Sie sicher.

Ü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