Coders Conquer Security Infrastructure as Code Series - Geschäftslogik
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.


Diese Schwachstelle kann auftreten, wenn Programmierer die Regeln der Geschäftslogik nicht ordnungsgemäß implementieren, wodurch ihre Anwendungen anfällig für verschiedene Arten von Angriffen werden, sollte ein böswilliger Benutzer sie ausnutzen wollen.
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.


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.

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.

Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
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.
Inhaltsübersicht
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
KI-Codier-Assistenten: Ein Leitfaden zur sicherheitsgerechten Navigation für die nächste Generation von Entwicklern
Große Sprachmodelle bieten unwiderstehliche Geschwindigkeits- und Produktivitätsvorteile, aber sie bringen auch unbestreitbare Risiken für das Unternehmen mit sich. Herkömmliche Sicherheitsleitplanken reichen nicht aus, um die Flut zu kontrollieren. Entwickler benötigen präzise, geprüfte Sicherheitskenntnisse, um Sicherheitslücken bereits zu Beginn des Softwareentwicklungszyklus zu erkennen und zu verhindern.
Sicher durch Design: Definition von Best Practices, Befähigung von Entwicklern und Benchmarking von präventiven Sicherheitsergebnissen
In diesem Forschungspapier werden die Mitbegründer von Secure Code Warrior , Pieter Danhieux und Dr. Matias Madou, Ph.D., zusammen mit den Experten Chris Inglis, ehemaliger US National Cyber Director (jetzt strategischer Berater der Paladin Capital Group), und Devin Lynch, Senior Director, Paladin Global Institute, die wichtigsten Erkenntnisse aus mehr als zwanzig ausführlichen Interviews mit Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, ein VP of Application Security und Software-Sicherheitsexperten, offenlegen.
Ressourcen für den Einstieg
10.000+ Lernaktivitäten für sicheren Code: Ein Jahrzehnt des Risikomanagements für Entwickler
Wir feiern mehr als 10.000 Aktivitäten zum Erlernen von sicherem Code und ein Jahrzehnt, in dem wir Entwicklern geholfen haben, Risiken zu reduzieren, die Codequalität zu verbessern und die KI-gestützte Entwicklung selbstbewusst anzugehen.
Maßstäbe setzen: SCW veröffentlicht kostenlose Sicherheitsregeln für KI-Codierung auf GitHub
KI-gestützte Entwicklung ist nicht mehr nur Zukunftsmusik – sie ist bereits da und verändert die Art und Weise, wie Software geschrieben wird, rasant. Tools wie GitHub Copilot, Cline, Roo, Cursor, Aider und Windsurf machen Entwickler zu ihren eigenen Co-Piloten, ermöglichen schnellere Iterationen und beschleunigen alles vom Prototyping bis hin zu großen Refactoring-Projekten.
Schließen Sie den Kreis zu Schwachstellen mit Secure Code Warrior + HackerOne
Secure Code Warrior freut sich, unsere neue Integration mit HackerOne, einem führenden Anbieter von offensiven Sicherheitslösungen, bekannt zu geben. Gemeinsam bauen wir ein leistungsstarkes, integriertes Ökosystem auf. HackerOne zeigt auf, wo Schwachstellen in realen Umgebungen tatsächlich auftreten, und deckt das "Was" und "Wo" von Sicherheitsproblemen auf.