
Programmierer erobern die Sicherheitsinfrastruktur als Codeserie — Business Logic
Nun, das ist es (vorerst). Wir haben das Ende unserer Infrastructure as Code-Serie erreicht. Wir hoffen, Sie hatten Spaß daran, Sicherheitsprobleme in Docker, Ansible, Kubernetes, Terraform und CloudFormation zu überwinden. Bevor wir uns jedoch abmelden, haben wir noch eine weitere Sicherheitslücke, die Sie beherrschen müssen: Bugs in der Geschäftslogik.
Denken Sie, Sie sind jetzt bereit, Ihre Fähigkeiten zu testen? Probiere die letzte spielerische Herausforderung aus:
Wenn Sie sich in einigen Dingen immer noch nicht sicher sind, lesen Sie weiter:
Die Sicherheitslücken, auf die wir uns heute konzentrieren wollen, sind Geschäftslogik Mängel. Diese können auftreten, wenn Programmierer die Regeln der Geschäftslogik nicht ordnungsgemäß implementieren, wodurch ihre Anwendungen anfällig für verschiedene Arten von Angriffen werden könnten, falls ein böswilliger Benutzer sie ausnutzt. Je nach Zweck und Funktionalität, die in jeder Anwendung implementiert ist, kann ein Fehler in der Geschäftslogik dazu führen, dass Rechte erweitert werden, Ressourcen nicht ordnungsgemäß genutzt werden oder eine beliebige Anzahl unbeabsichtigter Geschäftsprozesse ausgeführt wird.
Im Gegensatz zu vielen Sicherheitslücken kann die falsche 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 induzieren, betrachten Sie das folgende Beispiel aus einer Docker-Umgebung, die mit einer Docker Compose-Datei definiert ist. 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:
bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Reservierungen:
CPUs: „0,5"
Oberflächlich betrachtet sieht das gut aus, aber diese Ressourcenrichtlinie für Container schränkt den Ressourcenverbrauch nicht richtig ein. Ein Angreifer könnte den Fehler in der Geschäftslogik ausnutzen, um einen Denial-of-Service (DoS) -Angriff zu implementieren.
Um zu versuchen, Benutzer daran zu hindern, zu viele Ressourcen zu beanspruchen, könnte ein Entwickler versuchen, besser zu definieren, was jeder Container unterstützen kann. Der neue Code könnte also eine Platzierungsbeschränkung enthalten:
bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Reservierungen:
CPUs: „0,5"
Platzierung:
Einschränkungen:
- „node.labels.limit_cpu == 100 M“
- „node.labels.limit_memory == 0,5"
Auf den ersten Blick sieht das so aus, als würde es das lösen Geschäftslogik Fehler. Die neue Platzierungsbeschränkung wirkt sich jedoch nicht auf das Limit für die Ressourcennutzung für den Docker-Containerdienst aus. Es 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, wäre danach aber in der Lage, Ressourcen unbegrenzt abzubauen.
Wie Sie sehen, kann es ein kniffliges Unterfangen sein, über Fehler in der Geschäftslogik nachzudenken und zu programmieren, um sie zu beheben.
Beseitigung von Fehlern in der Geschäftslogik
Bei Fehlern in der Geschäftslogik liegt der Schlüssel darin, zu wissen, dass sie existieren. Sie müssen darauf achten, sie von Ihrer Umgebung fernzuhalten, während neuer Code geschrieben wird. Geschäftsregeln und bewährte Verfahren sollten in allen Phasen des Anwendungsentwicklungsprozesses, einschließlich Design, Implementierung und Test, klar definiert und überprüft werden.
Um beispielsweise zu verhindern, dass ein Fehler in der Geschäftslogik einen DoS-Angriff wie im obigen Beispiel ermöglicht, empfiehlt es sich, die Menge an Ressourcen zu begrenzen, die jeder von Ihnen erstellte Docker-Container verwenden kann. Insbesondere müssen im Abschnitt „Limits“ die Anzahl der CPUs und die Menge an Speicher angegeben werden, die ein Docker-Container verwenden kann. Ein Beispiel wäre:
bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Speicher: 100M
Reservierungen:
CPUs: „0,5"
Speicher: 50M
Die Verwendung von Code wie dem obigen Beispiel als Richtlinie würde einen großen Fehler in der Geschäftslogik aus der Umgebung entfernen und DoS-Angriffe verhindern. Dies würde auch dann funktionieren, wenn ein Angreifer einen der Docker-Container kompromittiert hätte. In diesem Fall wäre der Angreifer immer noch nicht in der Lage, seinen Halt zu nutzen, um Ressourcen zu erschöpfen.
Bedrohungsmodellierung kann hilfreich sein, indem sie definiert, wie verschiedene Angriffe stattfinden, und sicherstellt, dass Geschäftslogikregeln verwendet werden, um sie zu verhindern und einzuschränken. Tests auf der Grundlage von Compliance-Regeln und bekannten Missbrauchsfällen könnten ebenfalls hilfreich sein, um Fehler in der Geschäftslogik zu erkennen, die durch das Raster gleiten.
Fehler in der Geschäftslogik gehören zu den subtilsten Sicherheitslücken, die sich in Anwendungen einschleichen können, aber nicht weniger gefährlich sind als andere, bekanntere Risiken. Wenn Sie wissen, wie sie auftreten können, und bewährte Methoden anwenden, können Sie sie während der Anwendungsentwicklung von Ihrer Umgebung fernhalten. So wird sichergestellt, dass sie niemals in eine Produktionsumgebung gelangen, in der sie von Angreifern missbraucht werden können, die mit ihrer Ausnutzung bestens vertraut sind.
Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo Nehmen Sie an dieser IaC-Herausforderung auf der Secure Code Warrior-Schulungsplattform teil, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.


Diese Sicherheitsanfälligkeit kann auftreten, wenn Programmierer die Regeln der Geschäftslogik nicht ordnungsgemäß implementieren, wodurch ihre Anwendungen anfällig für verschiedene Arten von Angriffen werden könnten, falls ein böswilliger Benutzer sie ausnutzt.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.

Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenMatias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.


Nun, das ist es (vorerst). Wir haben das Ende unserer Infrastructure as Code-Serie erreicht. Wir hoffen, Sie hatten Spaß daran, Sicherheitsprobleme in Docker, Ansible, Kubernetes, Terraform und CloudFormation zu überwinden. Bevor wir uns jedoch abmelden, haben wir noch eine weitere Sicherheitslücke, die Sie beherrschen müssen: Bugs in der Geschäftslogik.
Denken Sie, Sie sind jetzt bereit, Ihre Fähigkeiten zu testen? Probiere die letzte spielerische Herausforderung aus:
Wenn Sie sich in einigen Dingen immer noch nicht sicher sind, lesen Sie weiter:
Die Sicherheitslücken, auf die wir uns heute konzentrieren wollen, sind Geschäftslogik Mängel. Diese können auftreten, wenn Programmierer die Regeln der Geschäftslogik nicht ordnungsgemäß implementieren, wodurch ihre Anwendungen anfällig für verschiedene Arten von Angriffen werden könnten, falls ein böswilliger Benutzer sie ausnutzt. Je nach Zweck und Funktionalität, die in jeder Anwendung implementiert ist, kann ein Fehler in der Geschäftslogik dazu führen, dass Rechte erweitert werden, Ressourcen nicht ordnungsgemäß genutzt werden oder eine beliebige Anzahl unbeabsichtigter Geschäftsprozesse ausgeführt wird.
Im Gegensatz zu vielen Sicherheitslücken kann die falsche 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 induzieren, betrachten Sie das folgende Beispiel aus einer Docker-Umgebung, die mit einer Docker Compose-Datei definiert ist. 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:
bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Reservierungen:
CPUs: „0,5"
Oberflächlich betrachtet sieht das gut aus, aber diese Ressourcenrichtlinie für Container schränkt den Ressourcenverbrauch nicht richtig ein. Ein Angreifer könnte den Fehler in der Geschäftslogik ausnutzen, um einen Denial-of-Service (DoS) -Angriff zu implementieren.
Um zu versuchen, Benutzer daran zu hindern, zu viele Ressourcen zu beanspruchen, könnte ein Entwickler versuchen, besser zu definieren, was jeder Container unterstützen kann. Der neue Code könnte also eine Platzierungsbeschränkung enthalten:
bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Reservierungen:
CPUs: „0,5"
Platzierung:
Einschränkungen:
- „node.labels.limit_cpu == 100 M“
- „node.labels.limit_memory == 0,5"
Auf den ersten Blick sieht das so aus, als würde es das lösen Geschäftslogik Fehler. Die neue Platzierungsbeschränkung wirkt sich jedoch nicht auf das Limit für die Ressourcennutzung für den Docker-Containerdienst aus. Es 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, wäre danach aber in der Lage, Ressourcen unbegrenzt abzubauen.
Wie Sie sehen, kann es ein kniffliges Unterfangen sein, über Fehler in der Geschäftslogik nachzudenken und zu programmieren, um sie zu beheben.
Beseitigung von Fehlern in der Geschäftslogik
Bei Fehlern in der Geschäftslogik liegt der Schlüssel darin, zu wissen, dass sie existieren. Sie müssen darauf achten, sie von Ihrer Umgebung fernzuhalten, während neuer Code geschrieben wird. Geschäftsregeln und bewährte Verfahren sollten in allen Phasen des Anwendungsentwicklungsprozesses, einschließlich Design, Implementierung und Test, klar definiert und überprüft werden.
Um beispielsweise zu verhindern, dass ein Fehler in der Geschäftslogik einen DoS-Angriff wie im obigen Beispiel ermöglicht, empfiehlt es sich, die Menge an Ressourcen zu begrenzen, die jeder von Ihnen erstellte Docker-Container verwenden kann. Insbesondere müssen im Abschnitt „Limits“ die Anzahl der CPUs und die Menge an Speicher angegeben werden, die ein Docker-Container verwenden kann. Ein Beispiel wäre:
bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Speicher: 100M
Reservierungen:
CPUs: „0,5"
Speicher: 50M
Die Verwendung von Code wie dem obigen Beispiel als Richtlinie würde einen großen Fehler in der Geschäftslogik aus der Umgebung entfernen und DoS-Angriffe verhindern. Dies würde auch dann funktionieren, wenn ein Angreifer einen der Docker-Container kompromittiert hätte. In diesem Fall wäre der Angreifer immer noch nicht in der Lage, seinen Halt zu nutzen, um Ressourcen zu erschöpfen.
Bedrohungsmodellierung kann hilfreich sein, indem sie definiert, wie verschiedene Angriffe stattfinden, und sicherstellt, dass Geschäftslogikregeln verwendet werden, um sie zu verhindern und einzuschränken. Tests auf der Grundlage von Compliance-Regeln und bekannten Missbrauchsfällen könnten ebenfalls hilfreich sein, um Fehler in der Geschäftslogik zu erkennen, die durch das Raster gleiten.
Fehler in der Geschäftslogik gehören zu den subtilsten Sicherheitslücken, die sich in Anwendungen einschleichen können, aber nicht weniger gefährlich sind als andere, bekanntere Risiken. Wenn Sie wissen, wie sie auftreten können, und bewährte Methoden anwenden, können Sie sie während der Anwendungsentwicklung von Ihrer Umgebung fernhalten. So wird sichergestellt, dass sie niemals in eine Produktionsumgebung gelangen, in der sie von Angreifern missbraucht werden können, die mit ihrer Ausnutzung bestens vertraut sind.
Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo Nehmen Sie an dieser IaC-Herausforderung auf der Secure Code Warrior-Schulungsplattform teil, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.

Nun, das ist es (vorerst). Wir haben das Ende unserer Infrastructure as Code-Serie erreicht. Wir hoffen, Sie hatten Spaß daran, Sicherheitsprobleme in Docker, Ansible, Kubernetes, Terraform und CloudFormation zu überwinden. Bevor wir uns jedoch abmelden, haben wir noch eine weitere Sicherheitslücke, die Sie beherrschen müssen: Bugs in der Geschäftslogik.
Denken Sie, Sie sind jetzt bereit, Ihre Fähigkeiten zu testen? Probiere die letzte spielerische Herausforderung aus:
Wenn Sie sich in einigen Dingen immer noch nicht sicher sind, lesen Sie weiter:
Die Sicherheitslücken, auf die wir uns heute konzentrieren wollen, sind Geschäftslogik Mängel. Diese können auftreten, wenn Programmierer die Regeln der Geschäftslogik nicht ordnungsgemäß implementieren, wodurch ihre Anwendungen anfällig für verschiedene Arten von Angriffen werden könnten, falls ein böswilliger Benutzer sie ausnutzt. Je nach Zweck und Funktionalität, die in jeder Anwendung implementiert ist, kann ein Fehler in der Geschäftslogik dazu führen, dass Rechte erweitert werden, Ressourcen nicht ordnungsgemäß genutzt werden oder eine beliebige Anzahl unbeabsichtigter Geschäftsprozesse ausgeführt wird.
Im Gegensatz zu vielen Sicherheitslücken kann die falsche 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 induzieren, betrachten Sie das folgende Beispiel aus einer Docker-Umgebung, die mit einer Docker Compose-Datei definiert ist. 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:
bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Reservierungen:
CPUs: „0,5"
Oberflächlich betrachtet sieht das gut aus, aber diese Ressourcenrichtlinie für Container schränkt den Ressourcenverbrauch nicht richtig ein. Ein Angreifer könnte den Fehler in der Geschäftslogik ausnutzen, um einen Denial-of-Service (DoS) -Angriff zu implementieren.
Um zu versuchen, Benutzer daran zu hindern, zu viele Ressourcen zu beanspruchen, könnte ein Entwickler versuchen, besser zu definieren, was jeder Container unterstützen kann. Der neue Code könnte also eine Platzierungsbeschränkung enthalten:
bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Reservierungen:
CPUs: „0,5"
Platzierung:
Einschränkungen:
- „node.labels.limit_cpu == 100 M“
- „node.labels.limit_memory == 0,5"
Auf den ersten Blick sieht das so aus, als würde es das lösen Geschäftslogik Fehler. Die neue Platzierungsbeschränkung wirkt sich jedoch nicht auf das Limit für die Ressourcennutzung für den Docker-Containerdienst aus. Es 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, wäre danach aber in der Lage, Ressourcen unbegrenzt abzubauen.
Wie Sie sehen, kann es ein kniffliges Unterfangen sein, über Fehler in der Geschäftslogik nachzudenken und zu programmieren, um sie zu beheben.
Beseitigung von Fehlern in der Geschäftslogik
Bei Fehlern in der Geschäftslogik liegt der Schlüssel darin, zu wissen, dass sie existieren. Sie müssen darauf achten, sie von Ihrer Umgebung fernzuhalten, während neuer Code geschrieben wird. Geschäftsregeln und bewährte Verfahren sollten in allen Phasen des Anwendungsentwicklungsprozesses, einschließlich Design, Implementierung und Test, klar definiert und überprüft werden.
Um beispielsweise zu verhindern, dass ein Fehler in der Geschäftslogik einen DoS-Angriff wie im obigen Beispiel ermöglicht, empfiehlt es sich, die Menge an Ressourcen zu begrenzen, die jeder von Ihnen erstellte Docker-Container verwenden kann. Insbesondere müssen im Abschnitt „Limits“ die Anzahl der CPUs und die Menge an Speicher angegeben werden, die ein Docker-Container verwenden kann. Ein Beispiel wäre:
bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Speicher: 100M
Reservierungen:
CPUs: „0,5"
Speicher: 50M
Die Verwendung von Code wie dem obigen Beispiel als Richtlinie würde einen großen Fehler in der Geschäftslogik aus der Umgebung entfernen und DoS-Angriffe verhindern. Dies würde auch dann funktionieren, wenn ein Angreifer einen der Docker-Container kompromittiert hätte. In diesem Fall wäre der Angreifer immer noch nicht in der Lage, seinen Halt zu nutzen, um Ressourcen zu erschöpfen.
Bedrohungsmodellierung kann hilfreich sein, indem sie definiert, wie verschiedene Angriffe stattfinden, und sicherstellt, dass Geschäftslogikregeln verwendet werden, um sie zu verhindern und einzuschränken. Tests auf der Grundlage von Compliance-Regeln und bekannten Missbrauchsfällen könnten ebenfalls hilfreich sein, um Fehler in der Geschäftslogik zu erkennen, die durch das Raster gleiten.
Fehler in der Geschäftslogik gehören zu den subtilsten Sicherheitslücken, die sich in Anwendungen einschleichen können, aber nicht weniger gefährlich sind als andere, bekanntere Risiken. Wenn Sie wissen, wie sie auftreten können, und bewährte Methoden anwenden, können Sie sie während der Anwendungsentwicklung von Ihrer Umgebung fernhalten. So wird sichergestellt, dass sie niemals in eine Produktionsumgebung gelangen, in der sie von Angreifern missbraucht werden können, die mit ihrer Ausnutzung bestens vertraut sind.
Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo Nehmen Sie an dieser IaC-Herausforderung auf der Secure Code Warrior-Schulungsplattform teil, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.

Klicken Sie auf den Link unten und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine Demo buchenMatias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
Nun, das ist es (vorerst). Wir haben das Ende unserer Infrastructure as Code-Serie erreicht. Wir hoffen, Sie hatten Spaß daran, Sicherheitsprobleme in Docker, Ansible, Kubernetes, Terraform und CloudFormation zu überwinden. Bevor wir uns jedoch abmelden, haben wir noch eine weitere Sicherheitslücke, die Sie beherrschen müssen: Bugs in der Geschäftslogik.
Denken Sie, Sie sind jetzt bereit, Ihre Fähigkeiten zu testen? Probiere die letzte spielerische Herausforderung aus:
Wenn Sie sich in einigen Dingen immer noch nicht sicher sind, lesen Sie weiter:
Die Sicherheitslücken, auf die wir uns heute konzentrieren wollen, sind Geschäftslogik Mängel. Diese können auftreten, wenn Programmierer die Regeln der Geschäftslogik nicht ordnungsgemäß implementieren, wodurch ihre Anwendungen anfällig für verschiedene Arten von Angriffen werden könnten, falls ein böswilliger Benutzer sie ausnutzt. Je nach Zweck und Funktionalität, die in jeder Anwendung implementiert ist, kann ein Fehler in der Geschäftslogik dazu führen, dass Rechte erweitert werden, Ressourcen nicht ordnungsgemäß genutzt werden oder eine beliebige Anzahl unbeabsichtigter Geschäftsprozesse ausgeführt wird.
Im Gegensatz zu vielen Sicherheitslücken kann die falsche 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 induzieren, betrachten Sie das folgende Beispiel aus einer Docker-Umgebung, die mit einer Docker Compose-Datei definiert ist. 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:
bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Reservierungen:
CPUs: „0,5"
Oberflächlich betrachtet sieht das gut aus, aber diese Ressourcenrichtlinie für Container schränkt den Ressourcenverbrauch nicht richtig ein. Ein Angreifer könnte den Fehler in der Geschäftslogik ausnutzen, um einen Denial-of-Service (DoS) -Angriff zu implementieren.
Um zu versuchen, Benutzer daran zu hindern, zu viele Ressourcen zu beanspruchen, könnte ein Entwickler versuchen, besser zu definieren, was jeder Container unterstützen kann. Der neue Code könnte also eine Platzierungsbeschränkung enthalten:
bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Reservierungen:
CPUs: „0,5"
Platzierung:
Einschränkungen:
- „node.labels.limit_cpu == 100 M“
- „node.labels.limit_memory == 0,5"
Auf den ersten Blick sieht das so aus, als würde es das lösen Geschäftslogik Fehler. Die neue Platzierungsbeschränkung wirkt sich jedoch nicht auf das Limit für die Ressourcennutzung für den Docker-Containerdienst aus. Es 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, wäre danach aber in der Lage, Ressourcen unbegrenzt abzubauen.
Wie Sie sehen, kann es ein kniffliges Unterfangen sein, über Fehler in der Geschäftslogik nachzudenken und zu programmieren, um sie zu beheben.
Beseitigung von Fehlern in der Geschäftslogik
Bei Fehlern in der Geschäftslogik liegt der Schlüssel darin, zu wissen, dass sie existieren. Sie müssen darauf achten, sie von Ihrer Umgebung fernzuhalten, während neuer Code geschrieben wird. Geschäftsregeln und bewährte Verfahren sollten in allen Phasen des Anwendungsentwicklungsprozesses, einschließlich Design, Implementierung und Test, klar definiert und überprüft werden.
Um beispielsweise zu verhindern, dass ein Fehler in der Geschäftslogik einen DoS-Angriff wie im obigen Beispiel ermöglicht, empfiehlt es sich, die Menge an Ressourcen zu begrenzen, die jeder von Ihnen erstellte Docker-Container verwenden kann. Insbesondere müssen im Abschnitt „Limits“ die Anzahl der CPUs und die Menge an Speicher angegeben werden, die ein Docker-Container verwenden kann. Ein Beispiel wäre:
bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Speicher: 100M
Reservierungen:
CPUs: „0,5"
Speicher: 50M
Die Verwendung von Code wie dem obigen Beispiel als Richtlinie würde einen großen Fehler in der Geschäftslogik aus der Umgebung entfernen und DoS-Angriffe verhindern. Dies würde auch dann funktionieren, wenn ein Angreifer einen der Docker-Container kompromittiert hätte. In diesem Fall wäre der Angreifer immer noch nicht in der Lage, seinen Halt zu nutzen, um Ressourcen zu erschöpfen.
Bedrohungsmodellierung kann hilfreich sein, indem sie definiert, wie verschiedene Angriffe stattfinden, und sicherstellt, dass Geschäftslogikregeln verwendet werden, um sie zu verhindern und einzuschränken. Tests auf der Grundlage von Compliance-Regeln und bekannten Missbrauchsfällen könnten ebenfalls hilfreich sein, um Fehler in der Geschäftslogik zu erkennen, die durch das Raster gleiten.
Fehler in der Geschäftslogik gehören zu den subtilsten Sicherheitslücken, die sich in Anwendungen einschleichen können, aber nicht weniger gefährlich sind als andere, bekanntere Risiken. Wenn Sie wissen, wie sie auftreten können, und bewährte Methoden anwenden, können Sie sie während der Anwendungsentwicklung von Ihrer Umgebung fernhalten. So wird sichergestellt, dass sie niemals in eine Produktionsumgebung gelangen, in der sie von Angreifern missbraucht werden können, die mit ihrer Ausnutzung bestens vertraut sind.
Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo Nehmen Sie an dieser IaC-Herausforderung auf der Secure Code Warrior-Schulungsplattform teil, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.
Inhaltsverzeichniss
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.

Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Securecode-Schulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um der sich ständig ändernden Softwareentwicklungslandschaft unter Berücksichtigung Ihrer Rolle gerecht zu werden. Themen, die alles von KI bis XQuery Injection abdecken und für eine Vielzahl von Rollen angeboten werden, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Einblick in das Angebot unseres Inhaltskatalogs nach Themen und Rollen.
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressourcen für den Einstieg
Cybermon is back: Beat the Boss KI-Missionen jetzt auf Abruf verfügbar
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzt fortschrittliche KI/LLM-Sicherheitsanforderungen ein, um die sichere KI-Entwicklung in einem großen Maßstab zu stärken.
Cyber-Resilienz-Gesetz erklärt: Was das für die Entwicklung von Secure by Design-Software bedeutet
Erfahren Sie, was der EU Cyber Resilience Act (CRA) verlangt, für wen er gilt und wie sich Entwicklungsteams mit sicheren Methoden, der Vorbeugung von Sicherheitslücken und dem Aufbau von Fähigkeiten für Entwickler darauf vorbereiten können.




%20(1).avif)
.avif)
