🥇Hoe je een eenvoudig hulpmiddel gebruikt om kwetsbaarheden in programmatuur te vinden

Graudit ondersteunt meerdere programmeertalen en maakt het mogelijk om beveiligingstests van de codebase rechtstreeks in het ontwikkelingsproces te integreren.

Bron: Unsplash (Markus Spiske)

Testen is een belangrijk onderdeel van de levenscyclus van softwareontwikkeling. Er zijn veel verschillende soorten testen, elk met zijn eigen doel. Vandaag wil ik het hebben over het opsporen van beveiligingsproblemen in code.

Het is duidelijk dat het in de huidige realiteit van softwareontwikkeling belangrijk is om de veiligheid van processen te waarborgen. Er is zelfs een speciale term voor geïntroduceerd: DevSecOps. Deze term verwijst naar een reeks procedures die gericht zijn op het identificeren en verhelpen van kwetsbaarheden in applicaties. Er zijn gespecialiseerde open source-oplossingen voor het controleren van kwetsbaarheden volgens de normen OWASP, die verschillende typen en gedragingen van kwetsbaarheden in de broncode beschrijven.

Er zijn verschillende benaderingen om beveiligingsproblemen op te lossen, zoals statische beveiligingstests (SAST), dynamische beveiligingstests (DAST), interactieve beveiligingstests (IAST), softwarecomponentanalyse (Software Composition Analysis) en meer.

Statische beveiligingstests detecteren fouten in de reeds geschreven code. Deze benadering vereist geen uitvoering van de applicatie, daarom wordt het statische analyse genoemd.

Ik wil me richten op statische code-analyse en gebruik maken van een eenvoudig open source-hulpmiddel om alles in de praktijk te demonstreren.

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

Er zijn verschillende redenen: ten eerste is het gratis, omdat je een hulpmiddel gebruikt dat is ontwikkeld door een gemeenschap van gelijkgestemden die andere ontwikkelaars willen helpen. Als je een klein team of een startup hebt, heb je een uitstekende kans om te besparen door open source-software te gebruiken voor de beveiliging van je codebase. Ten tweede bespaart het je de noodzaak om een apart DevSecOps-team aan te nemen, wat je kosten nog verder verlaagt.

Goede open source-tools zijn altijd ontworpen met verhoogde flexibiliteit in gedachten. Daarom kunnen ze in vrijwel elke omgeving worden gebruikt, voor een breed scala aan taken. Het is voor ontwikkelaars veel makkelijker om dergelijke tools te integreren met het systeem dat ze al hebben opgebouwd tijdens hun projecten.

Er kunnen echter situaties ontstaan waarin u een functie nodig heeft die niet beschikbaar is in de door u gekozen tool. In dat geval heeft u de mogelijkheid om de code te fork'en en op basis daarvan uw eigen tool te ontwikkelen met de gewenste functionaliteit.

Aangezien de ontwikkeling van open source-software in de meeste gevallen sterk door de community wordt beïnvloed, worden beslissingen over wijzigingen snel en doelgericht genomen: ontwikkelaars van het open source-project baseren zich op feedback en suggesties van gebruikers, evenals op hun meldingen van gevonden fouten en andere problemen.

Het gebruik van Graudit voor de beveiligingsanalyse van code

Voor statische code-analyse kunnen verschillende open source-tools worden gebruikt, er bestaat geen Universele tool voor alle programmeertalen. Ontwikkelaars van sommige ervan volgen de richtlijnen van OWASP en proberen zoveel mogelijk talen te dekken.

Hier zullen we gebruikmaken van Graudit, een eenvoudige commandoregelutility die ons in staat stelt kwetsbaarheden in onze codebasis te vinden. Het ondersteunt verschillende talen, maar de set is nog steeds beperkt. Graudit is ontwikkeld op basis van de utility grep, die destijds onder de GNU-licentie is uitgegeven.

Er zijn vergelijkbare tools voor statische code-analyse zoals Rough Auditing Tool for Security (RATS), Securitycompass Web Application Analysis Tool (SWAAT), Flawfinder, enzovoort. Maar Graudit is zeer flexibel en heeft minimale technische vereisten. Het kan echter zo zijn dat u taken tegenkomt die Graudit niet kan oplossen. In dat geval kunt u andere opties overwegen in deze lijst.

We kunnen deze tool integreren in een specifiek project, of beschikbaar stellen voor een gekozen gebruiker, of hem tegelijkertijd in al onze projecten gebruiken. Ook hierin komt de flexibiliteit van Graudit naar voren. Laten we beginnen met het klonen van de repository:

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

Laten we nu een symbolische link voor Graudit aanmaken, zodat we deze in het opdrachtformaat kunnen gebruiken.

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

Laten we een alias toevoegen aan .bashrc (of aan een ander configuratiebestand dat je gebruikt):

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

Herstart:

$ source ~/.bashrc # OF
$ exec $SHELL

Laten we controleren of de installatie succesvol was:

$ graudit -h

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

Ik ga een van mijn bestaande projecten testen. Voordat je het hulpmiddel start, moet je een database doorgeven 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, ik heb twee js-bestanden uit mijn project getest, en Graudit gaf informatie over kwetsbaarheden in mijn code weer in de console:

Je kunt op dezelfde manier je projecten testen. De lijst met databases voor verschillende programmeertalen kan worden bekeken. hier.

Voordelen en nadelen van Graudit

Graudit ondersteunt veel programmeertalen. Daarom is het geschikt voor een breed scala aan gebruikers. Het kan concurreren met zowel gratis als betaalde alternatieven. En het is heel belangrijk dat er nog steeds verbeteringen aan het project worden aangebracht, en de community helpt niet alleen ontwikkelaars, maar ook andere gebruikers die proberen het hulpmiddel te begrijpen.

Het is een handig hulpmiddel, maar het kan nog niet altijd precies aangeven wat het probleem is met een verdachte code-sectie. De ontwikkelaars blijven Graudit verbeteren.

Maar het is in ieder geval nuttig om alert te zijn op potentiële beveiligingsproblemen in de code met behulp van dergelijke hulpmiddelen.

Begin…

In dit artikel heb ik slechts één van de vele manieren besproken om kwetsbaarheden te vinden — statische beveiligingstests van applicaties. Statische code-analyse is eenvoudig uit te voeren, maar dit is pas het begin. Om meer te leren over de beveiliging van je codebase, moet je andere soorten testen integreren in de softwareontwikkelingscyclus.

Adverteervermelding

Betrouwbare VPS en de juiste keuze van het tariefplan zorgt ervoor dat je minder afgeleid wordt van de ontwikkeling door vervelende problemen — alles zal soepel draaien met een zeer hoge uptime!

Bron: habr.com