Les codeurs conquièrent l'infrastructure de sécurité en tant que série de codes - Business Logic

Nun, das war's (vorerst). Wir haben das Ende unserer Infrastructure as Code-Serie erreicht. Wir hoffen, Sie hatten Spaß beim Bezwingen von Sicherheitsproblemen in Docker, Ansible, Kubernetes, Terraform und CloudFormation. Bevor wir uns jedoch verabschieden, müssen Sie noch eine weitere Schwachstelle meistern: Fehler in der Geschäftslogik.

Denken Sie, Sie sind jetzt bereit, Ihre Fähigkeiten zu testen? Versuchen Sie die letzte spielerische Herausforderung:

Wenn Ihnen noch ein paar Dinge unklar sind, lesen Sie weiter:

Die Schwachstellen, auf die wir uns heute konzentrieren wollen, sind Schwachstellen in der Geschäftslogik. Diese können auftreten, wenn Programmierer die Regeln der Geschäftslogik nicht ordnungsgemäß implementieren, so dass ihre Anwendungen für verschiedene Arten von Angriffen anfällig sind, falls ein böswilliger Benutzer sie ausnutzen möchte. Je nach dem Zweck und der Funktionalität, die in einer Anwendung implementiert sind, kann ein Fehler in der Geschäftslogik die Ausweitung von Privilegien, die unsachgemäße Nutzung von Ressourcen oder eine Reihe von unbeabsichtigten Geschäftsprozessen ermöglichen.

Im Gegensatz zu vielen anderen Schwachstellen kann die fehlerhafte Implementierung von Geschäftslogikregeln überraschend subtil sein. Sie erfordern besondere Wachsamkeit, um sicherzustellen, dass sie sich nicht in Anwendungen und Code einschleichen.

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

Als Beispiel dafür, wie einfach es sein kann, Fehler in der Geschäftslogik zu verursachen, betrachten Sie das folgende Beispiel aus einer Docker-Umgebung, die mit einer Docker Compose-Datei definiert wurde. Um Container auf die Ausführung von Funktionen vorzubereiten, könnte ein Entwickler eine Standard-Ressourcenrichtlinie verwenden, die in der Docker Compose-Datei definiert ist, wie im folgenden Beispiel:

einsatz:
ressourcen:
limits:
cpus: "0.5"
reservierungen:
cpus: "0.5"

Das sieht zwar oberflächlich betrachtet gut aus, aber diese Ressourcenrichtlinie für Container schränkt die Ressourcennutzung nicht richtig ein. Ein Angreifer könnte den Fehler in der Geschäftslogik ausnutzen, um einen Denial-of-Service-Angriff (DoS) durchzuführen.

Um zu verhindern, dass Benutzer zu viele Ressourcen in Anspruch nehmen, könnte ein Entwickler versuchen, besser zu definieren, was jeder Container unterstützen kann. Der neue Code könnte also eine Platzierungsbeschränkung enthalten:

einsatz:
ressourcen:
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 Fehler in der Geschäftslogik beheben. Die neue Platzierungsbeschränkung wirkt sich jedoch nicht auf das Limit der Ressourcennutzung für den Docker-Containerdienst aus. Sie wird nur verwendet, um einen Knoten für die Planung des Containers auszuwählen. In diesem Fall ist ein DoS-Angriff immer noch möglich. Der Angreifer müsste zuerst einen Docker-Container kompromittieren, könnte dann aber unbegrenzt Ressourcen verbrauchen.

Wie Sie sehen können, kann das Nachdenken über Fehler in der Geschäftslogik und das Programmieren, um diese zu beseitigen, ein kniffliges Unterfangen sein.

Eliminieren von Fehlern in der Geschäftslogik

Bei Fehlern in der Geschäftslogik kommt es darauf an, zu wissen, dass sie existieren. Sie müssen wachsam sein, um sie aus Ihrer Umgebung herauszuhalten, während neuer Code geschrieben wird. Geschäftsregeln und Best Practices sollten in allen Phasen des Anwendungsentwicklungsprozesses, einschließlich Entwurf, Implementierung und Test, klar definiert und überprüft werden.

Um z. B. zu verhindern, dass ein Fehler in der Geschäftslogik einen DoS-Angriff wie im obigen Beispiel ermöglicht, besteht eine bewährte Methode darin, die Menge der Ressourcen zu begrenzen, die jeder von Ihnen erstellte Docker-Container verwenden kann. Insbesondere muss im Abschnitt "Limits" die Anzahl der CPUs und die Menge des Arbeitsspeichers angegeben werden, die ein Docker-Container verwenden kann. Ein Beispiel wäre:

einsatz:
ressourcen:
limits:
cpus: "0.5"
speicher: 100M
reservierungen:
cpus: "0.5"
memory: 50M

Die Verwendung von Code wie dem obigen Beispiel als Richtlinie würde einen wichtigen Fehler in der Geschäftslogik aus der Umgebung entfernen und DoS-Angriffe verhindern. Dies würde selbst dann funktionieren, wenn ein Angreifer einen der Docker-Container kompromittieren würde. In diesem Fall wäre der Angreifer immer noch nicht in der Lage, sein Standbein zu nutzen, um Ressourcen zu verbrauchen.

Die Bedrohungsmodellierung kann hilfreich sein, indem sie definiert, wie verschiedene Angriffe ablaufen und sicherstellt, dass Geschäftslogikregeln verwendet werden, um sie zu verhindern und einzuschränken. Das Testen auf Basis von Compliance-Regeln und bekannten Missbrauchsfällen könnte ebenfalls hilfreich sein, um Fehler in der Geschäftslogik zu erkennen, die durch die Maschen schlüpfen.

Geschäftslogikfehler gehören zu den subtilsten Schwachstellen, die sich in Anwendungen einschleichen können, sind aber nicht weniger gefährlich als andere, bekanntere Risiken. Wenn Sie wissen, wie sie auftreten können, und Best Practices anwenden, können Sie sie während der Anwendungsentwicklung aus Ihrer Umgebung heraushalten und sicherstellen, dass sie nie in eine Produktionsumgebung gelangen, wo sie von Angreifern missbraucht werden können, die sehr genau wissen, wie man sie ausnutzt.

Schauen Sie sich die Secure Code Warrior Blog-Seiten, um weitere Einblicke in diese Schwachstelle zu erhalten und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo dieser IaC-Herausforderung auf der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu schärfen und auf dem neuesten Stand zu halten.