Coders Conquer Security: Infrastructure as Code-Reihe – Geschäftslogik

Das war es (vorerst). Wir sind am Ende unserer Serie über Infrastructure as Code angelangt. Wir hoffen, es hat Ihnen Spaß gemacht, Sicherheitslücken in Docker, Ansible, Kubernetes, Terraform und CloudFormation zu schließen. Bevor wir uns verabschieden, haben wir jedoch noch eine letzte Schwachstelle für Sie: Fehler in der Geschäftslogik.

Glauben Sie, dass Sie bereit sind, Ihr Wissen zu testen? Versuchen Sie es mit der letzten spielerischen Herausforderung:

Falls noch Fragen offen sind, lesen Sie einfach weiter:

Die Schwachstellen, auf die wir uns heute konzentrieren möchten, sind Geschäftslogikfehler. Diese können entstehen, wenn Entwickler Geschäftslogikregeln nicht korrekt umsetzen, wodurch Anwendungen anfällig für verschiedene Angriffe werden, sollten böswillige Akteure diese ausnutzen. Je nach Zweck und Funktionalität der Anwendung kann ein Fehler in der Geschäftslogik eine Rechteausweitung, eine missbräuchliche Ressourcennutzung oder die Ausführung einer Vielzahl unbeabsichtigter Geschäftsprozesse ermöglichen.

Im Gegensatz zu vielen anderen Schwachstellen kann eine fehlerhafte Implementierung von Geschäftslogikregeln überraschend subtil sein. Es ist besondere Wachsamkeit erforderlich, um sicherzustellen, dass sich solche Fehler nicht in Anwendungen und Code einschleichen.

Was sind einige Beispiele für Fehler in der Geschäftslogik?

Um zu veranschaulichen, wie leicht Geschäftslogikfehler entstehen können, betrachten wir das folgende Beispiel aus einer Docker-Umgebung, die mit einer Docker-Compose-Datei definiert wurde. Um Container für bestimmte Funktionen vorzubereiten, könnte ein Entwickler eine Standard-Ressourcenrichtlinie verwenden, die in der Docker-Compose-Datei wie folgt definiert ist:

deploy:
 resources:
   limits:
     cpus: "0.5"
   reservations:
     cpus: "0.5"

Obwohl das auf den ersten Blick in Ordnung aussieht, begrenzt diese Ressourcenrichtlinie für Container die Ressourcennutzung nicht korrekt. Ein Angreifer könnte diesen Geschäftslogikfehler ausnutzen, um einen Denial-of-Service-Angriff (DoS) durchzuführen.

Um zu verhindern, dass Benutzer zu viele Ressourcen beanspruchen, könnte ein Entwickler versuchen, die Kapazitäten der einzelnen Container genauer zu definieren. Der neue Code könnte daher eine Platzierungseinschränkung enthalten:

deploy:
 resources:
   limits:
     cpus: "0.5"
   reservations:
     cpus: "0.5"
   placement:
     constraints:
       - "node.labels.limit_cpu == 100M"
       - "node.labels.limit_memory == 0.5"

Auf den ersten Blick sieht es so aus, als würde dies den Geschäftslogikfehler beheben. Die neue Platzierungseinschränkung hat jedoch keinen Einfluss auf das Ressourcennutzungslimit für den Docker-Container-Dienst. Sie dient lediglich dazu, einen Knoten für die Planung des Containers auszuwählen. In diesem Fall ist ein DoS-Angriff weiterhin möglich. Der Angreifer müsste zwar zuerst einen Docker-Container kompromittieren, könnte danach aber unbegrenzt Ressourcen abziehen.

Wie Sie sehen, kann es eine knifflige Angelegenheit sein, Geschäftslogikfehler zu erkennen und den Code so zu schreiben, dass sie eliminiert werden.

Beseitigung von Geschäftslogikfehlern

Bei Geschäftslogikfehlern ist es entscheidend, sich ihrer Existenz bewusst zu sein. Sie müssen wachsam sein, um sie während der Entwicklung von neuem Code aus Ihrer Umgebung fernzuhalten. Geschäftsregeln und Best Practices sollten klar definiert und in allen Phasen des Anwendungsentwicklungsprozesses, einschließlich Design, Implementierung und Tests, überprüft werden.

Um beispielsweise zu verhindern, dass ein Geschäftslogikfehler einen DoS-Angriff wie im obigen Beispiel ermöglicht, ist es eine bewährte Methode, die Ressourcenmenge zu begrenzen, die jeder von Ihnen erstellte Docker-Container nutzen kann. Insbesondere muss der Abschnitt „limits“ die Anzahl der CPUs und die Speichermenge festlegen, die ein Docker-Container verwenden darf. Ein Beispiel hierfür wäre:

deploy:
 resources:
   limits:
     cpus: "0.5"
     memory: 100M
   reservations:
     cpus: "0.5"
     memory: 50M

Die Verwendung von Code wie im obigen Beispiel als Richtlinie würde einen schwerwiegenden Geschäftslogikfehler aus der Umgebung entfernen und DoS-Angriffe verhindern. Dies würde selbst dann funktionieren, wenn ein Angreifer einen der Docker-Container kompromittiert hätte. In diesem Fall könnte der Angreifer seinen Zugriffspunkt nicht nutzen, um Ressourcen zu erschöpfen.

Threat Modeling hilft dabei, Angriffsvektoren zu definieren und sicherzustellen, dass Geschäftslogik-Regeln zu deren Abwehr eingesetzt werden. Tests auf Basis von Compliance-Vorgaben und bekannten Missbrauchsfällen helfen zudem, Schwachstellen in der Geschäftslogik aufzudecken, die sonst übersehen würden.

Schwachstellen in der Geschäftslogik gehören zu den subtilsten Sicherheitslücken in Anwendungen, sind jedoch nicht weniger gefährlich als bekanntere Risiken. Durch das Verständnis ihrer Entstehung und die Anwendung bewährter Verfahren lassen sie sich bereits während der Entwicklung vermeiden. So verhindern Sie, dass sie in die Produktionsumgebung gelangen und von Angreifern ausgenutzt werden können.

Besuchen Sie die Secure Code Warrior-Blogseiten für weitere Einblicke in diese Schwachstelle und erfahren Sie, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch eine Demo dieser IaC-Challenge auf der Secure Code Warrior-Schulungsplattform ausprobieren, um Ihre Cybersicherheits-Kenntnisse stets auf dem neuesten Stand zu halten.