Tenzij je op een afgelegen eiland zonder internetverbinding woont, heb je zeker gehoord over de Log4j problemen die de afgelopen 10 dagen zoveel applicaties en internetservices heeft getroffen. De toevallige ontdekking van deze kritieke bug in de context van Minecraft consoleberichten (het typen van een bericht in de Minecraft spelclient kon iemand code laten uitvoeren op een Minecraft server) door het gebruik van een extreem populaire Java logbibliotheek genaamd Log4jDit zorgde ervoor dat elk IT-bedrijf en elk bedrijf dat softwareapplicaties gebruikt, controleerde of het probleem invloed had op de software, gehoste services, interne websites en elk ander gebruiksscenario van het bedrijf.

De lijst met getroffen softwaretoepassingen (er is één hierbijvoorbeeld) is behoorlijk indrukwekkend, want ondanks dat Java een deel van de hype en marketingstimulans heeft verloren, is en blijft het een van 's werelds populairste talen en is de JVM een van de populairste runtime-uitvoeromgevingen.

RAD Studio Eigen code en geen Java-afhankelijkheid

Wat betekent dit nu voor Embarcadero in het algemeen en RAD Studio in het bijzonder? Direct, niet veel. Software gebouwd in Delphi of C++Builder gebruikt of vertrouwt op geen enkele manier op Java (met uitzondering van Android-applicaties) en maakt daarom geen gebruik van Log4j. Meer in het algemeen maken Delphi en C++Builder natively gecompileerde applicaties, die minder onderhevig zijn aan problemen met de uitvoeringsomgeving (hier verwijs ik naar Java, .NET of JavaScript uitvoeringsomgevingen). Echter in dit geval was het probleem niet in de uitvoeringsomgeving, maar in een populaire bibliotheek, en RAD Studio ontwikkelaars gebruiken add-on componenten en bibliotheken van derden, net als elke andere ontwikkelaar gemeenschap doet.

Ik zal het nog een keer verduidelijken: Een webserver of webservice gebouwd in Delphi of C++Builder (of C++ in het algemeen) wordt niet beïnvloed door het Log4j-probleem. Hetzelfde geldt natuurlijk voor webapplicaties die zijn gebouwd in ASP.NET, Python of PHP. Het probleem is specifiek voor software geschreven in Java - en er is veel Java-software, zoals hierboven gelinkt.

Om terug te komen op Delphi en C++Builder, het hebben van gecompileerde code helpt bij de beveiliging, maar het is niet voldoende. Het is ook belangrijk om alleen bibliotheken en componenten te kiezen die u volledig kunt vertrouwen (waarbij u minimaal vereist dat de broncode wordt meegeleverd). Bovendien is het ook belangrijk dat een ontwikkelaar code schrijft met een specifieke focus op beveiliging. Zoals vorige week al is gezegd, codering kopiëren en plakken (hoewel niet direct verantwoordelijk voor het Log4j probleem) is een codeerstijl aan de andere kant van het schrijven van veilige applicaties.

Terug naar Open Source

Er is ook een ander belangrijk probleem dat de Log4j-problemen duidelijk hebben gemaakt: er zijn miljoenenprojecten die worden beheerd door grote bedrijven die vertrouwen op open source-projecten zonder financiering, beheerd door ontwikkelaars in hun vrije tijd (buiten hun reguliere baan). Het idee dat je open-source kunt gebruiken om kosten te besparen zonder tijd, middelen of geld terug te geven aan de projecten die je gebruikt, wordt een groot probleem in de industrie.

Dit geldt ook voor de Delphi en C++Builder ecosysteem: Embarcadero is begonnen met het financieren en doneren aan een paar open source bibliotheken, maar we moeten meer doen. We moedigen ook alle zakelijke toepassingen die aanzienlijk gebruik maken van open-source Delphi bibliotheken en tools om terug te dragen aan hen - met inbegrip van door middel van security assessments!

Hoeveel open-source projecten gebruik je voor je professional applicaties en wanneer heb je voor het laatst gedoneerd?

Beveiliging is veelzijdig

Beveiliging is een continuüm dat meerdere invalshoeken vereist en elk van de onderstaande punten kan helpen:

  • Natively gecompileerde toepassingen
  • Geen afhankelijkheid van een runtime-uitvoeringsomgeving
  • Gebruik van gescreende en vertrouwde bibliotheken en componenten van derden
  • Toezeggen om bij te dragen aan open source-projecten die je gebruikt
  • Beveiligingsfocus bij het schrijven van code (geen copy-and-paste codering)
  • Tooling om de broncode van een applicatie te verifiëren
  • Veilige opslag van broncode (om injectie van broncode te voorkomen)
  • Veilige bouwomgeving (om injectie van binaire code te voorkomen)
  • Uitvoerbare applicatie ondertekenen

Hoewel deze lijst niet allesomvattend is en een voorkeur heeft voor gecompileerde code (we denken echt dat dit belangrijk is), hopen we dat deze lijst en de algemene reactie op het Log4j incident u en uw organisatie kan helpen om opnieuw na te denken over beveiliging en meer waarde toe te voegen aan de rol van ontwikkelaars - die de hoeksteen vormen van elk veilig ontwikkelscenario.

Veel plezier met programmeren met je Log4j-vrije RAD Studio 😉