Over de Log4j -2 kwetsbaarheid en afhankelijkheden

#11・
Tech voor op het web uitgelegd
30

subscribers

14

issues

Subscribe to our newsletter

By subscribing, you agree with Revue’s Terms of Service and Privacy Policy and understand that Tech voor op het web uitgelegd will receive your email address.

Jos van Essen
Jos van Essen
Voor nieuwsbrief #11 (die je nu leest) heb ik een super-actueel onderwerp gekozen waar ongeveer al mijn tech-vrienden het de afgelopen weekend over hadden (+ de winst van Max Verstappen, maar dit terzijde): Log4j -2.
Eerst maar even snel de timeline. Afgelopen vrijdag dook ineens nieuws op dat er een flinke kwetsbaarheid was gevonden in Log4j -2, een Java logging tool. Er worden bijna dagelijks wel kwetsbaarheden gevonden in software, maar deze was nieuw vanwege de omvang. Het bleek namelijk dat een enorme lijst aan producten - en daarmee organisaties - getroffen was.
Het zorgde er voor dat al mijn technische vrienden dus ook aan de slag moesten om hun eigen code te patchen, of de technologie-stack waar ze gebruik van maakten moesten repareren. Reparatie hiervan was overigens niet té complex, maar het negeren van deze kwetsbaarheid kon wel grote implicaties hebben. Kortom: iedereen die ooit iets technisch heeft gedaan moest de afgelopen dagen aan de gang.
Hoe kon het eigenlijk zo mis gaan? Dat heeft alles te maken met dependencies.
Dependencies zijn afhankelijkheden die in je software zitten. Deze afhankelijkheden zorgen er voor dat jouw software software van derden gebruikt om bepaalde handelingen te doen.
Er wordt anno 2021 nauwelijks nog software gebouwd die geen dependencies heeft. Simpel voorbeeld: ik moet ergens in m'n applicatie een grafiek tonen. Dan kan ik dagenlang (of in mijn geval wekenlang) zelf een eigen grafieken-tool bouwen (zonder andere hulp of dependencies) of ik kan in ongeveer 5 minuten deze Chart.Js library (dependency) installeren en gewoon verder met m'n leven.
Bijna iedere moderne technologie (web) stack heeft tegenwoordig een heel arsenaal aan dependencies. NPM is het bedrijf dat dit doet voor het gehele JavaScript ecosysteem. Binnen je JavaScript project heb je een bestandje, genaamd package.json die je in code precies verteld welke externe dependencies geladen moeten worden.

bijvoorbeeld zo
bijvoorbeeld zo
Quill is bijvoorbeeld een supermooie text-editor die je niet zo snel zelf gaat bouwen. Dus voeg ik m toe aan mijn project. Het gekke ^ dakje wordt getoond zodat je automatisch altijd een versie krijgt die gelijk of hoger is dan 1.3.6. Klinkt allemaal reuze-handig toch? Dat is het ook.
De grote caveat hier is dat de maker van bijvoorbeeld Quill ook weer eigen dependencies heeft: logisch: ook hij wil niet het wiel opnieuw uitvinden. Dus gebruikt hij andere packages die - je raad m al - ook weer andere dependencies hebben. Dit leidt tot een nogal complexe dependency tree die je hier gevisualeerd kunt zien.
Veel van deze kleine pakketjes worden ontwikkeld door vrijwilligers, wat er toe leidt dat webcomic XKCD er deze strip van maakte:
Ook bestaan er packages op bijvoorbeeld NPM zoals de infameuze is_odd en is_even die precies doen wat ze beloven: ze geven terug of een getal even- of oneven is. Dit is volstrekste onzin en kan natuurlijk eenvoudig in de code zelf worden gedaan.
Goede teams weten wanneer ze externe packages moeten gebruiken en wanneer ze zelf aan de slag moeten. Slechte teams downloaden en gebruiken heel veel packages, die op langere termijn heel lastig zijn om te onderhouden.
Andere dependency managers zijn bijvoorbeeld voor het Ruby ecosysteem gems en voor PHP Composer.
Op deze manier zie je dus ook dat wanneer er kwetsbaarheden zitten in (kleine delen van) software dat er dus een waterval-effect ontstaat: eigenlijk net als Log4j -2.
Wat kun je hier concreet mee? Je kunt in ieder geval zorgen dat je team dependencies tijdig update en dat hier in je scrum proces ook tijd voor wordt gemaakt. Er is tegenwoordig ook veel software in de versiebeheer- en/of CI/CD kant (allemaal in eerdere nieuwsbrieven besproken ;-) die dit automatisch doet, zoals die van Gitlab.
Did you enjoy this issue? Yes No
Jos van Essen
Jos van Essen

JSON, API's, webtokens, CI deployments, JavaScript, Tag Manager: we horen allemaal regelmatig termen voorbij komen waarvan we niet 100% zeker weten of we het ook daadwerkelijk begrijpt. Deze nieuwsbrief laat een licht schijnen op deze materie: tech voor op het web uitgelegd

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.