Artikelen the IT innovators

Package vulnerabilities

Uiteraard is het van belang dat je eigen code in je project geen vulnerabilities bevat. Een wel bekend voorbeeld van een vulnerability is Cross-site scripting (XSS). Vaak bevat jouw project echter meer code uit dependencies dan eigen code. Het is dan ook belangrijk om ervoor te zorgen dat ook de dependencies geen vulnerabilities hebben.

Ook in indirecte dependencies kunnen vulnerabilities zitten. Dit zijn de dependencies van jouw directe dependencies, waarvan je je vaak niet eens bewust bent dat je deze binnen haalt. Als een (indirecte) dependency van jouw project een vulnerability bevat, betekent dit namelijk dat jouw project vaak ook vatbaar is voor deze vulnerability!

DevDependencies zijn vaak nodig tijdens development en/of tijdens het builden op de build server. Deze dependencies worden vaak niet meegedeployed naar (productie) servers. Hierdoor kan het zijn dat een vulnerability in een DevDependency in jouw situatie geen probleem is. Dit betekent niet dat je deze zomaar mag negeren, kijk hier wel kritisch naar. Deze packages draaien namelijk lokaal of op de buildserver en onder bepaalde credentials. Dit stelt ze wel in staat om (ongewenste) acties op systemen uit te voeren en is dus wel degelijk een risico.

 

Audit

Npm bevat sinds versie 6 een audit tool.

npm audit scant de dependencies van het project en controleert de directe en indirecte dependencies op "known" vulnerablities. Het resultaat is een geclassificeerde lijst met bekende vulnerabilities. Deze scan wordt ook uitgevoerd als npm install gebruikt wordt om een package te installeren.

Hierdoor is goed te zien of nieuw geïnstalleerde packages bekende vulnerabilities bevatten.

Met npm audit fix probeert npm de gevonden vulnerabilities op te lossen door packages te upgraden naar nieuwere versies. Dit doet hij alleen als het op een veilige manier kan. Dit houdt in dat hij rekening houdt met compatible versions (dus geen major upgrades). Npm update de package naar de nieuwste compatible versie.

 

Nieuwe vulnerabilities in bestaande packages

Zorgen dat je geen vulnerabilities hebt is natuurlijk makkelijker gezegd dan gedaan. Naast alle bekende vulnerabilities worden er nog steeds nieuwe vulnerabilities gevonden. Deze kunnen van ernst verschillen. Bij een groot risico zal direct actie ondernomen moeten worden.

Vaak wordt er alleen tijdens het developen druk gemaakt om vulnerabilities, maar nadat het project gereleased is niet of nauwelijks meer naar omgekeken. Zo kan het voorkomen dat je project al jaren in productie draait met een vulnerability die ontdekt is na livegang.

Het is dus belangrijk om op de hoogte te blijven van deze vulnerablities.

Om dit risico te adresseren kun je bijvoorbeeld regelmatig handmatig een audit uitvoeren of dit periodiek inregelen op de buildserver.

 

Blijf up to date

Als er een vulnerability in een dependency gevonden wordt, dan wordt er vaak een nieuwe patch versie uitgebracht waarin dit probleem opgelost wordt. Als dit een patch versie is, kan dit vaak makkelijk opgelost worden door een npm audit fix toe te passen of handmatig naar deze versie te upgraden. Echter werkt dit alleen als het gaat om patches. Als de fix in een hogere major versie zit dan kan er vaak niet zomaar geupgrade worden. In major versies worden breaking changes doorgevoerd. Er is dus een grote kans dat er bij een major upgrade code aangepast moet worden. Zorg daarom dat je regelmatig je dependencies upgrade naar de laatste versie. Hierdoor verklein je de kans dat je veel aanpassingen in je code moet doorvoeren als je een upgrade met spoed moet doorvoeren vanwege vulnerabilities.

 

Buildservers

Het Open Web Application Security Project (OWASP) heeft een tool Dependency Check beschikbaar gemaakt voor het valideren van de security van een project. Dit kan als buildstep aan het buildproces toegevoegd worden. Doe dit voor zowel de development branch als de productiebranch en zorg ervoor dat de productiebranch periodiek getriggered wordt. Bij het vinden van nieuwe vulnerabilities zal de build falen en hierdoor worden nieuwe vulnerabilities inzichtelijk.

 

Deploy geen development files naar productie

Node_modules

Het meedeployen van packages die niet op productie gebruikt worden is een risico. Zo worden devDependencies vaak niet op productie gebruikt en hoeven dus ook niet gedeployed te worden. Sowieso is het meedeployen van node_modules niet wenselijk. Node_modules bevatten veel packages en files die niets te zoeken hebben op productie. Via een module bundler als webpack kan gemakkelijk de gebruikte bestanden van de modules gebundeld worden in een aparte file waardoor de gehele node_modules niet mee gedeployed hoeft te worden.

Package.json & package-lock.json

Een hacker kan extra kennis vergaren als hij bijvoorbeeld de package.json of package-lock.json in handen krijgt. Hij/Zij kan dan zien welke packages er geïnstalleerd en gebruikt worden wat hij in zijn voordeel kan gebruiken. Een package.json voegt verder weinig toe op productie, dus zorg dat deze niet meegedeployed wordt. Schoon daarnaast je package.json ook regelmatig op. Als je een package niet meer gebruikt, haal deze dan ook uit je package.json. Dit houdt het naast veilig ook overzichtelijker.

 

Security is een team effort

Een applicatie secure krijgen en houden kost effort en kan niet door developers alleen gedaan worden, dit is een team effort. Het is een ongoing process dat altijd aandacht verdient. Ook na livegang. Het is dan ook belangrijk dat iedereen aan boord is en dit de juiste prioriteit geeft.

Zo moet de product owner begrijpen dat secure worden en blijven een constante investering is. Dit is niet alleen een investering, maar levert ook wat op. Als gegevens van gebruikers op straat belanden is het immers vaak vrij snel gedaan met een bedrijf. De product owner moet in staat zijn om de stakeholders te kunnen overtuigen dat hierin geïnvesteerd moet worden.

Ook operations heeft een belangrijke rol in security. Een applicatie die secure is, maar uitgerold wordt op een server waar alles open staat heeft nog weinig nut. Servers optimaal voor de applicatie inregelen kunnen zij echter niet alleen, zij hebben input nodig van developers wat er qua rechten en security passend is voor de applicatie.

Security kan alleen goed gedaan worden als het prioriteit krijgt over de hele linie heen. Het is dus belangrijk dat security bespreekbaar is en overal doorgevoerd wordt. Ik adviseer je daarom ervoor te zorgen dat er aandacht voor komt als dit er nog niet is!

 

Overige dependencies

Npm zorgt niet als enige voor dependencies, denk bijvoorbeeld ook aan NuGet. NuGet heeft geen audit tool. Dit betekent niet dat dependencies vanuit NuGet geen vulnerabilities kennen. Het is alleen nog niet zo inzichtelijk gemaakt als in npm. Maar ook in het framework en middleware kunnen vulnerabilities zitten. Ook deze verdienen dezelfde aandacht.

 

Afsluiting

In dit artikel heb ik geprobeerd om je de informatie te geven zodat je meer grip kunt krijgen op het managen van de security bij het gebruik van npm packages. Ik hoop dat je ermee aan de slag kunt gaan.

Veel plezier in het gebruik van opensource software en Stay Secure!

Vincent is Senior Developer bij Blue Coded.
Meer informatie over bovenstaande onderwerp? Neem contact op met Wouter Olde Weghuis om te horen hoe wij ook jouw applicaties secure kunnen houden. Bel 079 - 330 1600

terug