Wenn Sie nicht gerade auf einer abgelegenen Insel ohne Internetanschluss leben, haben Sie sicher schon von der Log4j Probleme der in den letzten 10 Tagen so viele Anwendungen und Internetdienste betroffen hat. Die zufällige Entdeckung dieses kritischen Fehlers im Zusammenhang mit Minecraft-Konsolennachrichten (das Eingeben einer Nachricht auf dem Minecraft-Spielclient könnte es jemandem ermöglichen, Code auf einem Minecraft-Server auszuführen) aufgrund der Verwendung einer äußerst beliebten Java-Protokollierungsbibliothek genannt Log4jveranlasste jedes einzelne IT-Unternehmen und jedes Unternehmen, das Softwareanwendungen einsetzt, zu prüfen, ob das Problem die Software des Unternehmens, die gehosteten Dienste, die internen Websites und jedes andere Anwendungsszenario betraf.

Die Liste der betroffenen Softwareanwendungen (es gibt eine hier) ist ziemlich beeindruckend, denn obwohl Java etwas von seinem Hype und Marketingschub eingebüßt hat, ist und bleibt es eine der beliebtesten Sprachen der Welt und die JVM eine der beliebtesten Laufzeitausführungsumgebungen.

RAD Studio Native Code und keine Java-Abhängigkeit

Was bedeutet das nun für Embarcadero im Allgemeinen und RAD Studio im Besonderen? Unmittelbar nicht viel. Software, das in Delphi oder C++Builder erstellt wurde, verwendet oder verlässt sich in keiner Weise auf Java (mit Ausnahme von Android-Anwendungen) und verwendet daher auch nicht Log4j. Im Allgemeinen erstellen Delphi und C++Builder nativ kompilierte Anwendungen, die weniger anfällig für Probleme mit der Ausführungsumgebung sind (ich beziehe mich hier auf Java-, .NET- oder JavaScript-Ausführungsumgebungen). In diesem Fall lag das Problem jedoch nicht in der Ausführungsumgebung, sondern in einer beliebten Bibliothek, und RAD Studio-Entwickler verwenden Zusatzkomponenten und Bibliotheken von Drittanbietern, wie jede andere Entwicklergemeinschaft auch.

Lassen Sie mich noch einmal klarstellen: Ein Webserver oder Webservice, der in Delphi oder C++Builder (oder C++ im Allgemeinen) erstellt wurde, ist von dem Log4j-Problem nicht betroffen. Dasselbe gilt natürlich auch für Webanwendungen, die in ASP.NET, Python oder PHP erstellt wurden. Das Problem ist spezifisch für Software, die in Java geschrieben wurde - und es gibt eine Menge Java-Software, wie oben verlinkt.

Um auf Delphi und C++Builder zurückzukommen: Kompilierter Code hilft bei der Sicherheit, aber er reicht nicht aus. Es ist auch wichtig, dass Sie nur Bibliotheken und Komponenten auswählen, denen Sie voll und ganz vertrauen können (und die zumindest den Quellcode enthalten müssen). Außerdem ist es wichtig, dass ein Entwickler seinen Code mit besonderem Augenmerk auf die Sicherheit schreibt. Wie letzte Woche bereits erwähnt, Kodierung durch Kopieren und Einfügen (auch wenn er nicht direkt für das Log4j-Problem verantwortlich ist) ist ein Codierungsstil, der auf der Kehrseite des Schreibens sicherer Anwendungen steht.

Zurück zu Open Source beitragen

Es gibt noch ein weiteres Problem, das durch die Log4j-Probleme deutlich wurde: Es gibt millionenschwere Projekte, die von großen Unternehmen verwaltet werden, die sich auf Open-Source-Projekte stützen, die nicht finanziert werden und von Entwicklern in ihrer Freizeit (außerhalb ihrer regulären Arbeit) verwaltet werden. Die Idee, dass Sie mit Open Source Kosten sparen können, ohne Zeit, Ressourcen oder Geld in die Projekte zu investieren, die Sie nutzen, wird zu einem großen Problem in der Branche.

Dies gilt auch für das Delphi- und C++Builder-Ökosystem: Embarcadero hat damit begonnen, einige Open-Source-Bibliotheken zu finanzieren und zu spenden, aber wir sollten mehr tun. Wir ermutigen auch alle Geschäftsanwendungen, die Open-Source Delphi-Bibliotheken und -Tools in erheblichem Maße nutzen, einen Beitrag dazu zu leisten - auch durch Sicherheitsbewertungen!

Wie viele Open-Source-Projekte nutzen Sie für Ihre professional-Anwendungen und wann haben Sie das letzte Mal für eines dieser Projekte gespendet?

Sicherheit hat viele Gesichter

Sicherheit ist ein Kontinuum, das mehrere Blickwinkel erfordert, und jeder der folgenden Punkte kann dabei helfen:

  • Nativ kompilierte Anwendungen
  • Keine Abhängigkeit von einer Laufzeit-Ausführungsumgebung
  • Verwendung von geprüften und vertrauenswürdigen Bibliotheken und Komponenten von Drittanbietern
  • Sie verpflichten sich, einen Beitrag zu Open-Source-Projekten zu leisten, die Sie nutzen.
  • Sicherheitsorientierung beim Schreiben von Code (keine Copy-and-Paste-Codierung)
  • Werkzeuge zur Überprüfung des Quellcodes einer Anwendung
  • Sichere Speicherung des Quellcodes (zur Vermeidung von Source Code Injection)
  • Sichere Build-Umgebung (zur Vermeidung von Binärcode-Injektion)
  • Signieren von ausführbaren Anwendungen

Wir hoffen, dass diese Liste und die allgemeine Reaktion auf den Log4j-Vorfall Ihnen und Ihrem Unternehmen dabei helfen kann, Sicherheit neu zu überdenken und die Rolle der Entwickler - die der Eckpfeiler eines jeden sicheren Entwicklungsszenarios sind - aufzuwerten.

Viel Spaß beim Programmieren mit Ihrem Log4j-freien RAD Studio 😉