コーダーがセキュリティインフラストラクチャをコードシリーズで制覇-信頼できないソースからのコンポーネントを使う
Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrer IaC-Sicherheitsreise zu helfen.
Haben Sie die Herausforderungen gespielt? Wie ist Ihr Ergebnis bis jetzt? Bevor wir loslegen, wollen wir sehen, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:
Haben Sie noch etwas zu tun? Lesen Sie weiter:
Das Verhalten, das eine Schwachstelle hervorruft, 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 hat viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar fertigen Code zu Repositories wie GitHub beizusteuern, damit sie von anderen genutzt werden können, die sich darum bemühen, dass sich ein Programm oder eine App richtig verhält. Die Verwendung von fertigem Code zur Regelung von Programmfunktionen erspart es Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.
Die Verwendung von Codeschnipseln aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein großes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen einer der häufigsten Wege, auf dem sich größere und kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Schwachstellen versehentlich von ihren Erstellern herbeigeführt. Es gab auch schon Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann weitergegeben, in der Hoffnung, Opfer zu umgarnen, die ihn in ihre Anwendungen einbauen.
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, die er entwickelt, konfigurieren. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, macht er eine Google-Suche und findet jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Auch wenn der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn zu einer neuen Anwendung hinzuzufügen. Es kann in der Docker-Umgebung mit zwei Zeilen erfolgen:
RUN cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Jetzt zieht das Docker-Image die Konfigurationsdatei eines Drittanbieters dynamisch ein. Und selbst wenn die Datei zu diesem Zeitpunkt getestet und für in Ordnung befunden wird, bedeutet die Tatsache, dass der Zeiger nun in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit vorhanden ist. 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 freigegebene Konfigurationsdatei der Anwendung sagen, dass sie sich ganz anders verhalten soll als beabsichtigt, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.
Bessere Nutzung gemeinsamer Ressourcen
Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher geschieht. Wenn Sie fremden Code für eine mögliche Verwendung evaluieren, achten Sie darauf, dass Sie Komponenten aus offiziellen Quellen nur über sichere Links beziehen. Und selbst dann sollten Sie niemals eine Verbindung zu einer externen Quelle herstellen, um diesen Code einzuholen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte genehmigter Code in eine sichere Bibliothek eingebracht werden und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also wie folgt aussehen:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf eine lokale Kopie dieser Dateien setzen. Dies verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.
Zusätzlich zur Verwendung einer sicheren Code-Bibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um Komponenten während des gesamten Software-Lebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mit Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Schließlich sollten alle nicht genutzten oder unnötigen Abhängigkeiten und Funktionen entfernt werden, die möglicherweise mit dem externen Code einhergehen.
Wenn Sie diese Schritte befolgen, können Entwickler externe Ressourcen sicherer nutzen, ohne versehentlich Schwachstellen in ihre Anwendungen und ihren Code einzubringen.
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 der IaC-Herausforderungen auf der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu schärfen und auf dem neuesten Stand zu halten.
Dr. Matias Madu ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen.Anschließend trat er in die Dienste von Fortify in den USA ein und erkannte, dass es nicht ausreicht, nur Code-Probleme zu erkennen, ohne Entwicklern dabei zu helfen, sicheren Code zu schreiben. Dies war der Auslöser dafür, dass er begann, Entwickler zu unterstützen, die Sicherheitslast zu verringern und Produkte zu entwickeln, die die Erwartungen der Kunden übertreffen. Wenn er nicht als Mitglied von Team Awesome an seinem Schreibtisch sitzt, hält er gerne Präsentationen auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約
Dr. Matias Madu ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen.Anschließend trat er in die Dienste von Fortify in den USA ein und erkannte, dass es nicht ausreicht, nur Code-Probleme zu erkennen, ohne Entwicklern dabei zu helfen, sicheren Code zu schreiben. Dies war der Auslöser dafür, dass er begann, Entwickler zu unterstützen, die Sicherheitslast zu verringern und Produkte zu entwickeln, die die Erwartungen der Kunden übertreffen. Wenn er nicht als Mitglied von Team Awesome an seinem Schreibtisch sitzt, hält er gerne Präsentationen auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich 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 mehr als 10 Patente angemeldet.Wenn er nicht an seinem Schreibtisch sitzt, unterrichtet Matias Fortgeschrittenenkurse zum Thema Anwendungssicherheit und hält regelmäßig Vorträge auf globalen Konferenzen wie der RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matthias promovierte an der Universität Gent in Informatik und lernte dort Anwendungssicherheit durch Programmverschleierung, um die interne Funktionsweise von Anwendungen zu verbergen.
Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrer IaC-Sicherheitsreise zu helfen.
Haben Sie die Herausforderungen gespielt? Wie ist Ihr Ergebnis bis jetzt? Bevor wir loslegen, wollen wir sehen, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:
Haben Sie noch etwas zu tun? Lesen Sie weiter:
Das Verhalten, das eine Schwachstelle hervorruft, 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 hat viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar fertigen Code zu Repositories wie GitHub beizusteuern, damit sie von anderen genutzt werden können, die sich darum bemühen, dass sich ein Programm oder eine App richtig verhält. Die Verwendung von fertigem Code zur Regelung von Programmfunktionen erspart es Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.
Die Verwendung von Codeschnipseln aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein großes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen einer der häufigsten Wege, auf dem sich größere und kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Schwachstellen versehentlich von ihren Erstellern herbeigeführt. Es gab auch schon Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann weitergegeben, in der Hoffnung, Opfer zu umgarnen, die ihn in ihre Anwendungen einbauen.
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, die er entwickelt, konfigurieren. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, macht er eine Google-Suche und findet jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Auch wenn der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn zu einer neuen Anwendung hinzuzufügen. Es kann in der Docker-Umgebung mit zwei Zeilen erfolgen:
RUN cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Jetzt zieht das Docker-Image die Konfigurationsdatei eines Drittanbieters dynamisch ein. Und selbst wenn die Datei zu diesem Zeitpunkt getestet und für in Ordnung befunden wird, bedeutet die Tatsache, dass der Zeiger nun in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit vorhanden ist. 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 freigegebene Konfigurationsdatei der Anwendung sagen, dass sie sich ganz anders verhalten soll als beabsichtigt, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.
Bessere Nutzung gemeinsamer Ressourcen
Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher geschieht. Wenn Sie fremden Code für eine mögliche Verwendung evaluieren, achten Sie darauf, dass Sie Komponenten aus offiziellen Quellen nur über sichere Links beziehen. Und selbst dann sollten Sie niemals eine Verbindung zu einer externen Quelle herstellen, um diesen Code einzuholen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte genehmigter Code in eine sichere Bibliothek eingebracht werden und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also wie folgt aussehen:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf eine lokale Kopie dieser Dateien setzen. Dies verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.
Zusätzlich zur Verwendung einer sicheren Code-Bibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um Komponenten während des gesamten Software-Lebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mit Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Schließlich sollten alle nicht genutzten oder unnötigen Abhängigkeiten und Funktionen entfernt werden, die möglicherweise mit dem externen Code einhergehen.
Wenn Sie diese Schritte befolgen, können Entwickler externe Ressourcen sicherer nutzen, ohne versehentlich Schwachstellen in ihre Anwendungen und ihren Code einzubringen.
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 der IaC-Herausforderungen auf der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu schärfen 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 ihrer IaC-Sicherheitsreise zu helfen.
Haben Sie die Herausforderungen gespielt? Wie ist Ihr Ergebnis bis jetzt? Bevor wir loslegen, wollen wir sehen, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:
Haben Sie noch etwas zu tun? Lesen Sie weiter:
Das Verhalten, das eine Schwachstelle hervorruft, 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 hat viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar fertigen Code zu Repositories wie GitHub beizusteuern, damit sie von anderen genutzt werden können, die sich darum bemühen, dass sich ein Programm oder eine App richtig verhält. Die Verwendung von fertigem Code zur Regelung von Programmfunktionen erspart es Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.
Die Verwendung von Codeschnipseln aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein großes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen einer der häufigsten Wege, auf dem sich größere und kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Schwachstellen versehentlich von ihren Erstellern herbeigeführt. Es gab auch schon Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann weitergegeben, in der Hoffnung, Opfer zu umgarnen, die ihn in ihre Anwendungen einbauen.
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, die er entwickelt, konfigurieren. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, macht er eine Google-Suche und findet jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Auch wenn der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn zu einer neuen Anwendung hinzuzufügen. Es kann in der Docker-Umgebung mit zwei Zeilen erfolgen:
RUN cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Jetzt zieht das Docker-Image die Konfigurationsdatei eines Drittanbieters dynamisch ein. Und selbst wenn die Datei zu diesem Zeitpunkt getestet und für in Ordnung befunden wird, bedeutet die Tatsache, dass der Zeiger nun in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit vorhanden ist. 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 freigegebene Konfigurationsdatei der Anwendung sagen, dass sie sich ganz anders verhalten soll als beabsichtigt, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.
Bessere Nutzung gemeinsamer Ressourcen
Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher geschieht. Wenn Sie fremden Code für eine mögliche Verwendung evaluieren, achten Sie darauf, dass Sie Komponenten aus offiziellen Quellen nur über sichere Links beziehen. Und selbst dann sollten Sie niemals eine Verbindung zu einer externen Quelle herstellen, um diesen Code einzuholen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte genehmigter Code in eine sichere Bibliothek eingebracht werden und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also wie folgt aussehen:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf eine lokale Kopie dieser Dateien setzen. Dies verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.
Zusätzlich zur Verwendung einer sicheren Code-Bibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um Komponenten während des gesamten Software-Lebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mit Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Schließlich sollten alle nicht genutzten oder unnötigen Abhängigkeiten und Funktionen entfernt werden, die möglicherweise mit dem externen Code einhergehen.
Wenn Sie diese Schritte befolgen, können Entwickler externe Ressourcen sicherer nutzen, ohne versehentlich Schwachstellen in ihre Anwendungen und ihren Code einzubringen.
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 der IaC-Herausforderungen 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 folgenden Link, um die PDF-Datei dieser Ressource herunterzuladen.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
Bericht anzeigenデモを予約
Dr. Matias Madu ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen.Anschließend trat er in die Dienste von Fortify in den USA ein und erkannte, dass es nicht ausreicht, nur Code-Probleme zu erkennen, ohne Entwicklern dabei zu helfen, sicheren Code zu schreiben. Dies war der Auslöser dafür, dass er begann, Entwickler zu unterstützen, die Sicherheitslast zu verringern und Produkte zu entwickeln, die die Erwartungen der Kunden übertreffen. Wenn er nicht als Mitglied von Team Awesome an seinem Schreibtisch sitzt, hält er gerne Präsentationen auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich 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 mehr als 10 Patente angemeldet.Wenn er nicht an seinem Schreibtisch sitzt, unterrichtet Matias Fortgeschrittenenkurse zum Thema Anwendungssicherheit und hält regelmäßig Vorträge auf globalen Konferenzen wie der RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matthias promovierte an der Universität Gent in Informatik und lernte dort Anwendungssicherheit durch Programmverschleierung, um die interne Funktionsweise von Anwendungen zu verbergen.
Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrer IaC-Sicherheitsreise zu helfen.
Haben Sie die Herausforderungen gespielt? Wie ist Ihr Ergebnis bis jetzt? Bevor wir loslegen, wollen wir sehen, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:
Haben Sie noch etwas zu tun? Lesen Sie weiter:
Das Verhalten, das eine Schwachstelle hervorruft, 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 hat viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar fertigen Code zu Repositories wie GitHub beizusteuern, damit sie von anderen genutzt werden können, die sich darum bemühen, dass sich ein Programm oder eine App richtig verhält. Die Verwendung von fertigem Code zur Regelung von Programmfunktionen erspart es Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.
Die Verwendung von Codeschnipseln aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein großes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen einer der häufigsten Wege, auf dem sich größere und kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Schwachstellen versehentlich von ihren Erstellern herbeigeführt. Es gab auch schon Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann weitergegeben, in der Hoffnung, Opfer zu umgarnen, die ihn in ihre Anwendungen einbauen.
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, die er entwickelt, konfigurieren. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, macht er eine Google-Suche und findet jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Auch wenn der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn zu einer neuen Anwendung hinzuzufügen. Es kann in der Docker-Umgebung mit zwei Zeilen erfolgen:
RUN cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Jetzt zieht das Docker-Image die Konfigurationsdatei eines Drittanbieters dynamisch ein. Und selbst wenn die Datei zu diesem Zeitpunkt getestet und für in Ordnung befunden wird, bedeutet die Tatsache, dass der Zeiger nun in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit vorhanden ist. 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 freigegebene Konfigurationsdatei der Anwendung sagen, dass sie sich ganz anders verhalten soll als beabsichtigt, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.
Bessere Nutzung gemeinsamer Ressourcen
Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher geschieht. Wenn Sie fremden Code für eine mögliche Verwendung evaluieren, achten Sie darauf, dass Sie Komponenten aus offiziellen Quellen nur über sichere Links beziehen. Und selbst dann sollten Sie niemals eine Verbindung zu einer externen Quelle herstellen, um diesen Code einzuholen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte genehmigter Code in eine sichere Bibliothek eingebracht werden und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also wie folgt aussehen:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf eine lokale Kopie dieser Dateien setzen. Dies verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.
Zusätzlich zur Verwendung einer sicheren Code-Bibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um Komponenten während des gesamten Software-Lebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mit Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Schließlich sollten alle nicht genutzten oder unnötigen Abhängigkeiten und Funktionen entfernt werden, die möglicherweise mit dem externen Code einhergehen.
Wenn Sie diese Schritte befolgen, können Entwickler externe Ressourcen sicherer nutzen, ohne versehentlich Schwachstellen in ihre Anwendungen und ihren Code einzubringen.
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 der IaC-Herausforderungen auf der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu schärfen und auf dem neuesten Stand zu halten.
目次
Dr. Matias Madu ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen.Anschließend trat er in die Dienste von Fortify in den USA ein und erkannte, dass es nicht ausreicht, nur Code-Probleme zu erkennen, ohne Entwicklern dabei zu helfen, sicheren Code zu schreiben. Dies war der Auslöser dafür, dass er begann, Entwickler zu unterstützen, die Sicherheitslast zu verringern und Produkte zu entwickeln, die die Erwartungen der Kunden übertreffen. Wenn er nicht als Mitglied von Team Awesome an seinem Schreibtisch sitzt, hält er gerne Präsentationen auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約[ダウンロード]Ressourcen für den Einstieg
Themen und Inhalte der Secure-Code-Schulung
Unsere branchenführenden Inhalte werden unter Berücksichtigung der Aufgaben unserer Kunden ständig weiterentwickelt, um mit der sich ständig verändernden Softwareentwicklungsumgebung Schritt zu halten. Sie decken alle Themen von KI bis hin zu XQuery-Injection ab und sind für verschiedene Aufgabenbereiche konzipiert, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätssicherungsfachleuten. Werfen Sie einen Blick auf die Inhalte unseres Content-Katalogs, sortiert nach Themen und Aufgabenbereichen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
「Cybermon 2025 Beat the Boss」 kann nun das ganze Jahr über bei SCW gespielt werden. Führen Sie anspruchsvolle AI/LLM-Sicherheitsherausforderungen ein, um die sichere AI-Entwicklung in großem Maßstab zu stärken.
Erläuterung des Cyber-Resilience-Gesetzes: Bedeutung für die Entwicklung sicherer Software
Erfahren Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams auf Secure-by-Design-Praktiken, Schwachstellenprävention und die Kompetenzentwicklung von Entwicklern vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 ist der erste Teil der zehnteiligen Reihe „Enablers of Success“ und zeigt, wie sichere Programmierung mit geschäftlichen Ergebnissen wie Risikominderung und Geschwindigkeit verknüpft werden kann, um Programme langfristig zu optimieren.
