Hoe u een eenvoudig hulpprogramma kunt gebruiken om kwetsbaarheden in programmacode te vinden

Graudit ondersteunt meerdere programmeertalen en stelt u in staat codebase-beveiligingstests rechtstreeks in het ontwikkelingsproces te integreren.

Bron: Unsplash (Markus Spiske)

Testen is een belangrijk onderdeel van de levenscyclus van softwareontwikkeling. Er zijn veel soorten testen, elk lost zijn eigen probleem op. Vandaag wil ik het hebben over het vinden van beveiligingsproblemen in code.

Het is duidelijk dat het in de moderne realiteit van softwareontwikkeling belangrijk is om procesveiligheid te garanderen. Ooit werd zelfs de speciale term DevSecOps geïntroduceerd. Deze term verwijst naar een reeks procedures gericht op het identificeren en elimineren van kwetsbaarheden in een applicatie. Er zijn gespecialiseerde open source-oplossingen voor het controleren van kwetsbaarheden volgens standaarden OWASP, die de verschillende soorten en gedragingen van kwetsbaarheden in de broncode beschrijven.

Er zijn verschillende benaderingen om beveiligingsproblemen op te lossen, zoals Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), Software Composition Analysis, enzovoort.

Statische applicatiebeveiligingstests identificeren fouten in reeds geschreven code. Deze aanpak vereist niet dat de applicatie wordt uitgevoerd. Daarom wordt dit statische analyse genoemd.

Ik zal me concentreren op statische code-analyse en een eenvoudige open source-tool gebruiken om alles in de praktijk te demonstreren.

Waarom ik heb gekozen voor een open source-tool voor beveiligingsanalyse van statische code

Daar zijn een aantal redenen voor: ten eerste is het gratis omdat je een tool gebruikt die is ontwikkeld door een gemeenschap van gelijkgestemde mensen die andere ontwikkelaars willen helpen. Als u een klein team of een kleine startup heeft, heeft u een geweldige kans om geld te besparen door open source-software te gebruiken om de veiligheid van uw codebase te testen. Ten tweede hoeft u geen apart DevSecOps-team in te huren, waardoor uw kosten verder worden verlaagd.

Goede open source-tools worden altijd gemaakt rekening houdend met de toegenomen eisen aan flexibiliteit. Daarom kunnen ze in vrijwel elke omgeving worden gebruikt en bestrijken ze een breed scala aan taken. Het is voor ontwikkelaars veel gemakkelijker om dergelijke tools te verbinden met het systeem dat ze al hebben gebouwd terwijl ze aan hun projecten werkten.

Maar het kan voorkomen dat u een functie nodig heeft die niet beschikbaar is in de tool die u kiest. In dit geval heb je de mogelijkheid om de code te splitsen en op basis daarvan je eigen tool te ontwikkelen met de functionaliteit die je nodig hebt.

Omdat de ontwikkeling van open source-software in de meeste gevallen actief wordt beïnvloed door de gemeenschap, wordt de beslissing om wijzigingen aan te brengen vrij snel en to the point genomen: de ontwikkelaars van het open source-project vertrouwen op feedback en suggesties van gebruikers, op hun rapporten van gevonden fouten en andere problemen.

Graudit gebruiken voor analyse van codebeveiliging

Voor de analyse van statische code kunt u verschillende open source-tools gebruiken; er is geen universele tool voor alle programmeertalen. De ontwikkelaars van sommigen van hen volgen de OWASP-aanbevelingen en proberen zoveel mogelijk talen te dekken.

Hier zullen we gebruiken Graudit, een eenvoudig opdrachtregelprogramma waarmee we kwetsbaarheden in onze codebase kunnen vinden. Het ondersteunt verschillende talen, maar hun set is nog steeds beperkt. Graudit is ontwikkeld op basis van het hulpprogramma grep, dat ooit werd uitgebracht onder de GNU-licentie.

Er zijn vergelijkbare tools voor de analyse van statische code: Rough Auditing Tool for Security (RATS), Securitycompass Web Application Analysis Tool (SWAAT), foutzoeker enzovoort. Maar Graudit is zeer flexibel en stelt minimale technische eisen. Het kan echter voorkomen dat u problemen ondervindt die Graudit niet kan oplossen. Dan kun je hier kijken voor andere opties in deze lijst.

We kunnen deze tool integreren in een specifiek project, beschikbaar stellen aan een geselecteerde gebruiker, of tegelijkertijd gebruiken in al onze projecten. Dit is ook waar de flexibiliteit van Graudit een rol speelt. Laten we dus eerst de repository klonen:

$ git clone https://github.com/wireghoul/graudit

Laten we nu een symbolische link maken zodat Graudit deze in opdrachtformaat kan gebruiken

$ cd ~/bin && mkdir graudit
$ ln --symbolic ~/graudit/graudit ~/bin/graudit

Laten we een alias toevoegen aan .bashrc (of welk configuratiebestand u ook gebruikt):

#------ .bashrc ------
alias graudit="~/bin/graudit"

Opnieuw opstarten:

$ source ~/.bashrc # OR
$ exex $SHELL

Laten we controleren of de installatie succesvol is geweest:

$ graudit -h

Als je iets soortgelijks ziet, dan is alles in orde.

Ik ga een van mijn bestaande projecten testen. Voordat de tool wordt uitgevoerd, moet deze worden doorgegeven aan een database die overeenkomt met de taal waarin mijn project is geschreven. De databases bevinden zich in de map ~/gradit/signatures:

$ graudit -d ~/gradit/signatures/js.db

Dus testte ik twee js-bestanden van mijn project, en Graudit gaf informatie over kwetsbaarheden in mijn code weer op de console:

U kunt uw projecten op dezelfde manier testen. U kunt een lijst met databases voor verschillende programmeertalen bekijken hier.

Voor- en nadelen van Graudit

Graudit ondersteunt vele programmeertalen. Daarom is het geschikt voor een breed scala aan gebruikers. Het kan adequaat concurreren met alle gratis of betaalde analogen. En het is heel belangrijk dat er nog steeds verbeteringen aan het project worden aangebracht, en de gemeenschap helpt niet alleen de ontwikkelaars, maar ook andere gebruikers die de tool proberen te achterhalen.

Dit is een handig hulpmiddel, maar tot nu toe kan het niet altijd precies vaststellen wat het probleem is met een verdacht stukje code. De ontwikkelaars blijven Graudit verbeteren.

Maar in ieder geval is het nuttig om bij het gebruik van dit soort tools aandacht te besteden aan mogelijke beveiligingsproblemen in de code.

Begin…

In dit artikel heb ik gekeken naar slechts één van de vele manieren om kwetsbaarheden te vinden: het statisch testen van applicatiebeveiliging. Het uitvoeren van statische codeanalyse is eenvoudig, maar dit is nog maar het begin. Om meer te weten te komen over de beveiliging van uw codebase, moet u andere soorten tests integreren in de levenscyclus van uw softwareontwikkeling.

Als advertentie

Betrouwbare VPS en door de juiste keuze van het tariefplan wordt u minder afgeleid van de ontwikkeling door onaangename problemen - alles werkt zonder storingen en met een zeer hoge uptime!

Bron: www.habr.com