Programmierer erobern die Sicherheitsinfrastruktur als Code-Serie — mit Komponenten aus nicht vertrauenswürdigen Quellen
Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrem Weg zur IaC-Sicherheit zu helfen.
Hast du die Herausforderungen gespielt? Was ist dein bisheriges Ergebnis? Bevor wir beginnen, schauen wir uns an, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:
Hast du noch etwas zu tun? Lesen Sie weiter:
Das anfällige Verhalten, auf das wir uns heute konzentrieren werden, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen, eine scheinbar harmlose Praxis, die große Probleme verursacht. Die Verwendung von Open-Source-Code und Ressourcen bietet viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar ihren fertigen Code in Repositorys wie GitHub einzubringen, um von anderen verwendet zu werden, die Schwierigkeiten haben, ein Programm oder eine App richtig funktionieren zu lassen. Die Verwendung von abgeschlossenem Code zur Steuerung von Programmfunktionen erspart Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.
Die Verwendung von Codefragmenten aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein hohes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen eine der häufigsten Arten, mit denen sich sowohl größere als auch kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Sicherheitslücken versehentlich von ihren Urhebern verursacht. Es gab auch Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann geteilt, in der Hoffnung, Opfer zu verführen, die ihn dann in ihre Anwendungen einfügen.
Warum ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen gefährlich?
Nehmen wir an, ein Entwickler hat es eilig und muss eine Anwendung konfigurieren, die er gerade entwickelt. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, führen sie eine Google-Suche durch und finden jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Obwohl der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn einer neuen Anwendung hinzuzufügen. Dies kann in der Docker-Umgebung mit zwei Zeilen erfolgen:
FÜHREN SIE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Jetzt ruft das Docker-Image die Konfigurationsdatei des Drittanbieters dynamisch ab. Und selbst wenn die Datei getestet wurde und zu dem Zeitpunkt für in Ordnung befunden wurde, bedeutet die Tatsache, dass der Zeiger jetzt in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit besteht. Tage, Wochen oder Monate später könnte die Datei vom ursprünglichen Autor oder einem Angreifer, der das Code-Repository kompromittiert hat, geändert werden. Plötzlich kann die gemeinsam genutzte Konfigurationsdatei die Anwendung anweisen, ganz anders als beabsichtigt zu arbeiten, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.
Eine bessere Möglichkeit, gemeinsam genutzte Ressourcen zu nutzen
Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher ausgeführt wird. Achten Sie bei der Bewertung von externem Code auf eine mögliche Verwendung darauf, Komponenten nur über sichere Links aus offiziellen Quellen zu beziehen. Und selbst dann sollten Sie niemals auf eine externe Quelle verlinken, um diesen Code abzurufen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte der genehmigte Code in eine sichere Bibliothek gebracht und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also so aussehen:
KOPIERE src/config/default-ssl.conf /etc/apache2/sites-available/
Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf einer lokalen Kopie dieser Dateien beruhen. Dadurch wird verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.
Zusätzlich zur Verwendung einer sicheren Codebibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um die Komponenten während des gesamten Softwarelebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mithilfe von Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Entfernen Sie abschließend alle ungenutzten oder unnötigen Abhängigkeiten und Funktionen, die mit dem externen Code mitspielen könnten.
Wenn Entwickler diese Schritte befolgen, können sie externe Ressourcen sicherer nutzen, ohne versehentlich Sicherheitslücken in ihren Anwendungen und ihrem Code zu verursachen.
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 der IaC-Herausforderungen auf der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.
Das anfällige Verhalten, auf das wir uns hier konzentrieren werden, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen, eine scheinbar harmlose Praxis, die große Probleme verursacht.
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior 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 buchen
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung in 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 verfügt über mehr als 10 Patente. Wenn er nicht an seinem Schreibtisch ist, war Matias als Ausbilder für fortgeschrittene Schulungen zur Anwendungssicherheit 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 an der Universität Gent in Computertechnik promoviert, wo er Anwendungssicherheit durch Programmverschleierung studierte, um das Innenleben einer Anwendung zu verbergen.
Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrem Weg zur IaC-Sicherheit zu helfen.
Hast du die Herausforderungen gespielt? Was ist dein bisheriges Ergebnis? Bevor wir beginnen, schauen wir uns an, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:
Hast du noch etwas zu tun? Lesen Sie weiter:
Das anfällige Verhalten, auf das wir uns heute konzentrieren werden, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen, eine scheinbar harmlose Praxis, die große Probleme verursacht. Die Verwendung von Open-Source-Code und Ressourcen bietet viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar ihren fertigen Code in Repositorys wie GitHub einzubringen, um von anderen verwendet zu werden, die Schwierigkeiten haben, ein Programm oder eine App richtig funktionieren zu lassen. Die Verwendung von abgeschlossenem Code zur Steuerung von Programmfunktionen erspart Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.
Die Verwendung von Codefragmenten aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein hohes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen eine der häufigsten Arten, mit denen sich sowohl größere als auch kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Sicherheitslücken versehentlich von ihren Urhebern verursacht. Es gab auch Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann geteilt, in der Hoffnung, Opfer zu verführen, die ihn dann in ihre Anwendungen einfügen.
Warum ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen gefährlich?
Nehmen wir an, ein Entwickler hat es eilig und muss eine Anwendung konfigurieren, die er gerade entwickelt. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, führen sie eine Google-Suche durch und finden jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Obwohl der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn einer neuen Anwendung hinzuzufügen. Dies kann in der Docker-Umgebung mit zwei Zeilen erfolgen:
FÜHREN SIE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Jetzt ruft das Docker-Image die Konfigurationsdatei des Drittanbieters dynamisch ab. Und selbst wenn die Datei getestet wurde und zu dem Zeitpunkt für in Ordnung befunden wurde, bedeutet die Tatsache, dass der Zeiger jetzt in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit besteht. Tage, Wochen oder Monate später könnte die Datei vom ursprünglichen Autor oder einem Angreifer, der das Code-Repository kompromittiert hat, geändert werden. Plötzlich kann die gemeinsam genutzte Konfigurationsdatei die Anwendung anweisen, ganz anders als beabsichtigt zu arbeiten, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.
Eine bessere Möglichkeit, gemeinsam genutzte Ressourcen zu nutzen
Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher ausgeführt wird. Achten Sie bei der Bewertung von externem Code auf eine mögliche Verwendung darauf, Komponenten nur über sichere Links aus offiziellen Quellen zu beziehen. Und selbst dann sollten Sie niemals auf eine externe Quelle verlinken, um diesen Code abzurufen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte der genehmigte Code in eine sichere Bibliothek gebracht und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also so aussehen:
KOPIERE src/config/default-ssl.conf /etc/apache2/sites-available/
Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf einer lokalen Kopie dieser Dateien beruhen. Dadurch wird verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.
Zusätzlich zur Verwendung einer sicheren Codebibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um die Komponenten während des gesamten Softwarelebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mithilfe von Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Entfernen Sie abschließend alle ungenutzten oder unnötigen Abhängigkeiten und Funktionen, die mit dem externen Code mitspielen könnten.
Wenn Entwickler diese Schritte befolgen, können sie externe Ressourcen sicherer nutzen, ohne versehentlich Sicherheitslücken in ihren Anwendungen und ihrem Code zu verursachen.
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 der IaC-Herausforderungen auf der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.
Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrem Weg zur IaC-Sicherheit zu helfen.
Hast du die Herausforderungen gespielt? Was ist dein bisheriges Ergebnis? Bevor wir beginnen, schauen wir uns an, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:
Hast du noch etwas zu tun? Lesen Sie weiter:
Das anfällige Verhalten, auf das wir uns heute konzentrieren werden, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen, eine scheinbar harmlose Praxis, die große Probleme verursacht. Die Verwendung von Open-Source-Code und Ressourcen bietet viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar ihren fertigen Code in Repositorys wie GitHub einzubringen, um von anderen verwendet zu werden, die Schwierigkeiten haben, ein Programm oder eine App richtig funktionieren zu lassen. Die Verwendung von abgeschlossenem Code zur Steuerung von Programmfunktionen erspart Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.
Die Verwendung von Codefragmenten aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein hohes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen eine der häufigsten Arten, mit denen sich sowohl größere als auch kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Sicherheitslücken versehentlich von ihren Urhebern verursacht. Es gab auch Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann geteilt, in der Hoffnung, Opfer zu verführen, die ihn dann in ihre Anwendungen einfügen.
Warum ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen gefährlich?
Nehmen wir an, ein Entwickler hat es eilig und muss eine Anwendung konfigurieren, die er gerade entwickelt. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, führen sie eine Google-Suche durch und finden jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Obwohl der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn einer neuen Anwendung hinzuzufügen. Dies kann in der Docker-Umgebung mit zwei Zeilen erfolgen:
FÜHREN SIE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Jetzt ruft das Docker-Image die Konfigurationsdatei des Drittanbieters dynamisch ab. Und selbst wenn die Datei getestet wurde und zu dem Zeitpunkt für in Ordnung befunden wurde, bedeutet die Tatsache, dass der Zeiger jetzt in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit besteht. Tage, Wochen oder Monate später könnte die Datei vom ursprünglichen Autor oder einem Angreifer, der das Code-Repository kompromittiert hat, geändert werden. Plötzlich kann die gemeinsam genutzte Konfigurationsdatei die Anwendung anweisen, ganz anders als beabsichtigt zu arbeiten, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.
Eine bessere Möglichkeit, gemeinsam genutzte Ressourcen zu nutzen
Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher ausgeführt wird. Achten Sie bei der Bewertung von externem Code auf eine mögliche Verwendung darauf, Komponenten nur über sichere Links aus offiziellen Quellen zu beziehen. Und selbst dann sollten Sie niemals auf eine externe Quelle verlinken, um diesen Code abzurufen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte der genehmigte Code in eine sichere Bibliothek gebracht und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also so aussehen:
KOPIERE src/config/default-ssl.conf /etc/apache2/sites-available/
Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf einer lokalen Kopie dieser Dateien beruhen. Dadurch wird verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.
Zusätzlich zur Verwendung einer sicheren Codebibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um die Komponenten während des gesamten Softwarelebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mithilfe von Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Entfernen Sie abschließend alle ungenutzten oder unnötigen Abhängigkeiten und Funktionen, die mit dem externen Code mitspielen könnten.
Wenn Entwickler diese Schritte befolgen, können sie externe Ressourcen sicherer nutzen, ohne versehentlich Sicherheitslücken in ihren Anwendungen und ihrem Code zu verursachen.
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 der IaC-Herausforderungen auf der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.
Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior 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 buchen
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung in 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 verfügt über mehr als 10 Patente. Wenn er nicht an seinem Schreibtisch ist, war Matias als Ausbilder für fortgeschrittene Schulungen zur Anwendungssicherheit 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 an der Universität Gent in Computertechnik promoviert, wo er Anwendungssicherheit durch Programmverschleierung studierte, um das Innenleben einer Anwendung zu verbergen.
Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrem Weg zur IaC-Sicherheit zu helfen.
Hast du die Herausforderungen gespielt? Was ist dein bisheriges Ergebnis? Bevor wir beginnen, schauen wir uns an, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:
Hast du noch etwas zu tun? Lesen Sie weiter:
Das anfällige Verhalten, auf das wir uns heute konzentrieren werden, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen, eine scheinbar harmlose Praxis, die große Probleme verursacht. Die Verwendung von Open-Source-Code und Ressourcen bietet viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar ihren fertigen Code in Repositorys wie GitHub einzubringen, um von anderen verwendet zu werden, die Schwierigkeiten haben, ein Programm oder eine App richtig funktionieren zu lassen. Die Verwendung von abgeschlossenem Code zur Steuerung von Programmfunktionen erspart Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.
Die Verwendung von Codefragmenten aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein hohes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen eine der häufigsten Arten, mit denen sich sowohl größere als auch kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Sicherheitslücken versehentlich von ihren Urhebern verursacht. Es gab auch Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann geteilt, in der Hoffnung, Opfer zu verführen, die ihn dann in ihre Anwendungen einfügen.
Warum ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen gefährlich?
Nehmen wir an, ein Entwickler hat es eilig und muss eine Anwendung konfigurieren, die er gerade entwickelt. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, führen sie eine Google-Suche durch und finden jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Obwohl der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn einer neuen Anwendung hinzuzufügen. Dies kann in der Docker-Umgebung mit zwei Zeilen erfolgen:
FÜHREN SIE cd /etc/apache2/sites-available/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Jetzt ruft das Docker-Image die Konfigurationsdatei des Drittanbieters dynamisch ab. Und selbst wenn die Datei getestet wurde und zu dem Zeitpunkt für in Ordnung befunden wurde, bedeutet die Tatsache, dass der Zeiger jetzt in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit besteht. Tage, Wochen oder Monate später könnte die Datei vom ursprünglichen Autor oder einem Angreifer, der das Code-Repository kompromittiert hat, geändert werden. Plötzlich kann die gemeinsam genutzte Konfigurationsdatei die Anwendung anweisen, ganz anders als beabsichtigt zu arbeiten, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.
Eine bessere Möglichkeit, gemeinsam genutzte Ressourcen zu nutzen
Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher ausgeführt wird. Achten Sie bei der Bewertung von externem Code auf eine mögliche Verwendung darauf, Komponenten nur über sichere Links aus offiziellen Quellen zu beziehen. Und selbst dann sollten Sie niemals auf eine externe Quelle verlinken, um diesen Code abzurufen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte der genehmigte Code in eine sichere Bibliothek gebracht und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also so aussehen:
KOPIERE src/config/default-ssl.conf /etc/apache2/sites-available/
Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf einer lokalen Kopie dieser Dateien beruhen. Dadurch wird verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.
Zusätzlich zur Verwendung einer sicheren Codebibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um die Komponenten während des gesamten Softwarelebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mithilfe von Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Entfernen Sie abschließend alle ungenutzten oder unnötigen Abhängigkeiten und Funktionen, die mit dem externen Code mitspielen könnten.
Wenn Entwickler diese Schritte befolgen, können sie externe Ressourcen sicherer nutzen, ohne versehentlich Sicherheitslücken in ihren Anwendungen und ihrem Code zu verursachen.
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 der IaC-Herausforderungen auf der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.
Inhaltsverzeichnis
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior 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
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
Die Leistungsfähigkeit von OpenText Application Security + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
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.
Ressourcen für den Einstieg
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.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 eröffnet unsere zehnteilige Reihe „Enabler of Success“ und zeigt, wie sichere Codierung mit Geschäftsergebnissen wie Risikominderung und Geschwindigkeit verbunden werden kann, um eine langfristige Programmreife zu erreichen.