Als Entwickler jonglieren wir ständig mit Funktionen, Korrekturen und Fristen. Dennoch wurde überraschenderweise ein lauerndes Problem übersehen: die fortgesetzte Verwendung anfälliger Log4j- und Spring Framework-Versionen in vielen Projekten. Trotz der öffentlich bekannt gewordenen Schwachstellen in Log4Shell und Spring4Shell laufen immer noch erschreckend viele Anwendungen auf diesen tickenden Zeitbomben. Dies ist nicht nur ein kleines Versehen – es ist ein großes Risiko. Im Herzen sind wir Baumeister, aber ein Teil des Bauens besteht darin, sicherzustellen, dass unsere Bauwerke sicher sind.
Als Entwickler achten wir ständig darauf, neue Funktionen herauszubringen und bestehende Projekte und Funktionen zu pflegen. Es ist ein Balanceakt, der unsere Zeit und die volle kognitive Bandbreite beansprucht. Den Überblick über die Abhängigkeiten jedes Projekts zu behalten und gleichzeitig sicherzustellen, dass sie auf dem neuesten Stand sind, kann sich wie ein harter Kampf anfühlen, insbesondere wenn der Druck groß ist, neue Funktionalitäten bereitzustellen. Inmitten dieses Jonglierakts können kritische Schwachstellen wie Log4Shell und Spring4Shell manchmal durchs Raster fallen, nicht aus Fahrlässigkeit, sondern aufgrund der schieren Menge an Aufgaben, die wir täglich bewältigen. Es ist jedoch wichtig zu erkennen, dass die Sicherheit spannender Anwendungen heutzutage entscheidende Aspekte der Softwareentwicklung sind.
Erinnern Sie sich an Log4Shell? Diese schlimme Sicherheitslücke in Apache Log4j, die 2021 entdeckt wurde und es Angreifern ermöglichen könnte, Code auf Ihrem Server auszuführen, indem sie eine spezielle Zeichenfolge protokollieren? Ein Angreifer könnte eine JNDI-Suche mit dem LDAP-Protokoll verwenden, um eine vorkompilierte Klassendatei einzuschleusen und Schadcode auszuführen. Auch in neueren Java-Versionen kann diese Schwachstelle zu Schäden durch Deserialisierungsangriffe führen. Die Angriffskomplexität dieser kritischen Schwachstelle wird als sehr gering eingeschätzt, wodurch die Bedrohung noch höher als üblich ist. Eine vollständige Aufschlüsselung des Problems finden Sie in unserem Blogbeitrag.
Heutzutage haben viele Unternehmen immer noch eine veraltete, anfällige Version der Log4j-Bibliothek in einem ihrer Projekte. Von allen Snyk-Kunden, die ihren Produktionscode auf Schwachstellen scannen, haben21 %immer noch Projekte, die für Log4Shell anfällig sind. Das bedeutet, dass über60.000Projekte immer noch dem Risiko ausgesetzt sind, durch eine vor über zwei Jahren entdeckte und behobene Schwachstelle beeinträchtigt zu werden. Das ist riesig! Angesichts der Tatsache, dass diese Unternehmen bereits Sicherheitstools verwenden und die auftretenden Sicherheitsprobleme aktiv entschärfen, wird die tatsächliche Anzahl anfälliger Log4j-Versionen in freier Wildbahn viel höher sein. Allein dieser Gedanke ist nicht nur beängstigend, sondern auch sehr beunruhigend.
Ein weiteres berüchtigtes Beispiel war Spring4Shell, das im März 2022 veröffentlicht wurde. Die Schwachstelle in Spring-Beans könnte auch zur Ausführung böswilligen Remotecodes führen. Obwohl die Angriffskomplexität gering war und es Exploits für bestimmte Fälle gab, waren die Auswirkungen geringer als bei Log4Shell. Weitere Informationen finden Sie im entsprechenden Blogbeitrag.
Durch die Erweiterung dieser Schwachstelle auf Glassfish mit einem neuen Exploit im April 2022 hat das Snyk-Team bewiesen, dass diese Schwachstelle sehr bedeutsam ist und in vielen weiteren Fällen außerhalb des ersten Exploits für Tomcat missbraucht werden könnte.
Ähnlich wie Log4Shell haben wir festgestellt, dass Spring4Shell in freier Wildbahn immer noch anwendbar ist. Ungefähr35 %unserer Kunden haben immer noch die Schwachstelle in einem ihrer Projekte. Obwohl das Risiko eines Spring4Shell-Verstoßes nicht so groß war wie das von Log4Shell, demonstrierte das Snyk-Team eine Reihe potenzieller Exploits, indem es einen Exploit-Proof-of-Concept (POC) für Glassfish identifizierte und entwickelte. Dies beweist, dass scheinbar geringere Gefahren dennoch zu erheblichen Sicherheitslücken führen können. Die Tatsache, dass noch kein Exploit veröffentlicht wurde, bedeutet nicht, dass eine Anwendung nicht durch eine Schwachstelle angegriffen werden kann!
Darüber hinaus zeigt sich, dass viele Spring-Anwendungen auf ältere, veraltete Framework-Versionen angewiesen sind und die Aktualisierung und Wartung bestehender Anwendungen als unwichtig erachtet wird. Tief im Inneren wissen wir jedoch, dass dies eine tickende Zeitbombe ist, die jede Minute explodieren kann.
Lassen Sie es uns einfach und auf den Punkt bringen. Wir alle kennen dieses Gefühl des Stolzes, wenn unser Code endlich ohne Probleme läuft, und das Letzte, was wir tun wollen, ist, noch einmal damit herumzuspielen, insbesondere bei etwas so Dummem wie der Aktualisierung von Bibliotheken. Aber hier ist die Sache: Diese Log4Shell- und Spring4Shell-Schwachstellen werden sich nicht von selbst beheben. Und ehrlich gesagt sind es nicht nur kleine Fehler, die wir ignorieren können. Sie sind klaffende Löcher in den Wänden unserer Anwendung. Wenn Sie in Ihrer Landschaft immer noch Schwachstellen wie Log4Shell oder Spring4Shell haben, sind Sie unnötigerweise anfällig für Angriffe mit hohem Schweregrad!
Snyk kann Ihnen dabei helfen, indem es Sicherheitslücken in Anwendungen erkennt und behebt. Es lässt sich auf verschiedene Weise in Entwicklungsworkflows integrieren, beispielsweise über Git-Repositorys, die Befehlszeilenschnittstelle (CLI) oder vorhandene CI-Pipelines (Continuous Integration), sodass Entwickler Sicherheitsrisiken frühzeitig im Entwicklungszyklus erkennen können, bevor sie zu größeren Problemen werden. Die Registrierung ist kostenlos und ermöglicht den sofortigen Zugriff auf die Funktionen. Der wahre Wert liegt jedoch darin, wie die entdeckten Schwachstellen verwaltet und nach der Identifizierung behoben werden.
Hier müssen wir Verantwortung übernehmen. Es geht nicht nur darum, einen schnellen Patch zu finden oder zu hoffen, dass ein einfaches Update den Zweck erfüllt. Manchmal müssen wir uns die Mühe machen, eine anfällige Bibliothek zu entfernen oder zu ersetzen. Ja, es könnte uns etwas entschleunigen und es ist nicht der aufregendste Teil unseres Jobs, aber es ist entscheidend. Es geht darum sicherzustellen, dass unser Code solide ist, nicht nur für heute, sondern auf lange Sicht.
Warten wir also nicht darauf, dass jemand anderes diese Probleme behebt. Mit den richtigen Werkzeugen können wir diese Schwachstellen frühzeitig erkennen, aber wir müssen diejenigen sein, die Maßnahmen ergreifen. Es liegt an uns, unsere Abwehrmaßnahmen zu verstärken, diese Schwachstellen zu schließen und unsere Anwendungen sicher und zuverlässig zu halten. Kommen wir zur Sache, nicht nur als Programmierer, sondern als die Leute, die zu ihrer Arbeit stehen und dafür sorgen, dass sie so sicher wie möglich ist.
Das obige ist der detaillierte Inhalt vonDie anhaltende Bedrohung: Warum große Schwachstellen wie Logell und Springell weiterhin von Bedeutung sind. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
