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 nichts weiter als ein Blitzangriff. Ein Datenschwall wird auf einen bestimmten Dienst gerichtet mit der Absicht, das Gerät/die Infrastruktur/die Software, die die Anfragen bearbeitet, zu überlasten. Dabei gilt das Prinzip, dass alle Geräte – ob Hardware oder Software, vor Ort oder in der Cloud – über begrenzte Ressourcen verfügen. Wenn also genügend Anfragen gesendet werden, kann das Gerät überlastet werden und den Zugriff auf alles dahinter liegende System unterbinden.
Der Grund, warum Entwickler diesen Angriff nicht wirksam verhindern können, liegt darin, dass Anwendungen zur Verwaltung der Netzwerke auf Plattformen und Host-Betriebssysteme angewiesen sind. Ein volumetrischer DDoS-Angriff zielt auf diesen Netzwerkstapel ab und kann so viele der gemeinsam genutzten Ressourcen verbrauchen, dass die Anwendung kaum noch in der Lage ist, Anfragen zu verarbeiten, um festzustellen, dass sie angegriffen wird.
Eine sichere Codierung kann dies nicht verhindern – es handelt sich nicht um einen Exploit aufgrund einer Sicherheitslücke. Und es liegt wirklich nicht an Code in irgendeinem Teil des Systems. Es ist ganz einfach so: Egal, wie sehr wir versuchen, so zu tun, als gäbe es keine Hardware, die Ressourcen stammen von dort 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.
Es gibt im Allgemeinen zwei Arten von Layer-7-DDoS-Angriffen: langsame und schnelle. Langsames Layer-7-DDoS verbraucht Ressourcen, indem es eine schlechte Netzwerkverbindung vortäuscht und langsam Antworten von legitimen Anfragen abzweigt. Dies verbraucht Ressourcen, da Web-Apps verbindungsbasiert sind und die Ressourcen zum Aufrechterhalten dieser Verbindungen wiederum begrenzt sind. Indem sie Verbindungen zu einer ausreichend großen Anzahl von Clients herstellen und legitime Anfragen stellen, aber nur langsam Antworten erhalten, sind Angreifer in der Lage, Anwendungsressourcen zu blockieren. Dies hat zur Folge, dass es für legitime Clients nahezu unmöglich ist, eine Verbindung herzustellen, wodurch praktisch ein Denial-of-Service-Angriff durchgeführt wird.
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.