Graudit støtter flere programmeringsspråk og lar deg integrere kodebasesikkerhetstesting direkte i utviklingsprosessen.
Kilde: (Markus Spiske)
Testing er en viktig del av livssyklusen for programvareutvikling. Det er mange typer testing, hver av dem løser sitt eget problem. I dag vil jeg snakke om å finne sikkerhetsproblemer i kode.
I den moderne virkeligheten innen programvareutvikling er det åpenbart viktig å sikre prosesssikkerhet. På et tidspunkt ble det spesielle begrepet DevSecOps til og med introdusert. Dette begrepet refererer til en rekke prosedyrer som tar sikte på å identifisere og eliminere sårbarheter i en applikasjon. Det finnes spesialiserte åpen kildekode-løsninger for å sjekke sårbarheter i henhold til standarder , som beskriver ulike typer og oppførsel av sårbarheter i kildekoden.
Det finnes ulike tilnærminger til å løse sikkerhetsproblemer, for eksempel Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST), Software Composition Analysis, og så videre.
Statisk applikasjonssikkerhetstesting identifiserer feil i allerede skrevet kode. Denne tilnærmingen krever ikke at applikasjonen kjører, og det er derfor den kalles statisk analyse.
Jeg vil fokusere på statisk kodeanalyse og bruke et enkelt åpen kildekodeverktøy for å demonstrere alt i praksis.
Hvorfor jeg valgte et åpen kildekodeverktøy for statisk kodesikkerhetsanalyse
Det er en rekke grunner til dette: For det første er det gratis fordi du bruker et verktøy utviklet av et fellesskap av likesinnede som ønsker å hjelpe andre utviklere. Hvis du har et lite team eller oppstart, har du en flott mulighet til å spare penger ved å bruke åpen kildekode-programvare for å teste sikkerheten til kodebasen din. For det andre eliminerer det behovet for å ansette et eget DevSecOps-team, noe som reduserer kostnadene ytterligere.
Gode åpen kildekode-verktøy skapes alltid under hensyntagen til økte krav til fleksibilitet. Derfor kan de brukes i nesten alle miljøer, og dekker et bredt spekter av oppgaver. Det er mye lettere for utviklere å koble slike verktøy med systemet de allerede har bygget mens de jobber med prosjektene sine.
Men det kan være tider når du trenger en funksjon som ikke er tilgjengelig i verktøyet du velger. I dette tilfellet har du muligheten til å dele koden og utvikle ditt eget verktøy basert på den med funksjonaliteten du trenger.
Siden utviklingen av åpen kildekode-programvare i de fleste tilfeller er aktivt påvirket av fellesskapet, tas beslutningen om å gjøre endringer ganske raskt og konkret: utviklerne av åpen kildekode-prosjektet er avhengige av tilbakemeldinger og forslag fra brukere, på deres rapporter om funnet feil og andre problemer.
Bruke Graudit for kodesikkerhetsanalyse
Du kan bruke forskjellige åpen kildekode-verktøy for statisk kodeanalyse; det er ikke noe universelt verktøy for alle programmeringsspråk. Utviklerne av noen av dem følger OWASP-anbefalingene og prøver å dekke så mange språk som mulig.
Her skal vi bruke , et enkelt kommandolinjeverktøy som lar oss finne sårbarheter i kodebasen vår. Den støtter forskjellige språk, men fortsatt er settet begrenset. Graudit er utviklet basert på grep-verktøyet, som en gang ble utgitt under GNU-lisensen.
Det finnes lignende verktøy for statisk kodeanalyse - Rough Auditing Tool for Security (RATS), Securitycompass Web Application Analysis Tool (SWAAT), feilsøker og så videre. Men Graudit er veldig fleksibel og har minimale tekniske krav. Du kan imidlertid ha problemer som Graudit ikke kan løse. Da kan du se etter andre alternativer her .
Vi kan integrere dette verktøyet i et spesifikt prosjekt, eller gjøre det tilgjengelig for en valgt bruker, eller bruke det samtidig i alle våre prosjekter. Det er også her Graudits fleksibilitet spiller inn. Så la oss klone repoen først:
$ git clone https://github.com/wireghoul/grauditLa oss nå lage en symbolsk lenke for at Graudit kan bruke den i kommandoformat
$ cd ~/bin && mkdir graudit
$ ln --symbolic ~/graudit/graudit ~/bin/grauditLa oss legge til et alias til .bashrc (eller hvilken som helst konfigurasjonsfil du bruker):
#------ .bashrc ------
alias graudit="~/bin/graudit"Start på nytt:
$ source ~/.bashrc # OR
$ exex $SHELL
La oss sjekke om installasjonen var vellykket:
$ graudit -hHvis du ser noe lignende, er alt i orden.
Jeg skal teste ut et av mine eksisterende prosjekter. Før du kjører verktøyet, må det sendes en database som tilsvarer språket som prosjektet mitt er skrevet på. Databasene ligger i mappen ~/gradit/signatures:
$ graudit -d ~/gradit/signatures/js.dbSå jeg testet to js-filer fra prosjektet mitt, og Graudit viste informasjon om sårbarheter i koden min til konsollen:
Du kan prøve å teste prosjektene dine på samme måte. Du kan se en liste over databaser for forskjellige programmeringsspråk .
Fordeler og ulemper med Graudit
Graudit støtter mange programmeringsspråk. Derfor er den egnet for et bredt spekter av brukere. Den kan konkurrere tilstrekkelig med alle gratis eller betalte analoger. Og det er veldig viktig at det fortsatt gjøres forbedringer i prosjektet, og fellesskapet hjelper ikke bare utviklerne, men også andre brukere som prøver å finne ut av verktøyet.
Dette er et hendig verktøy, men så langt kan det ikke alltid finne nøyaktig hva problemet er med en mistenkelig kodebit. Utviklerne fortsetter å forbedre Graudit.
Men uansett er det nyttig å være oppmerksom på potensielle sikkerhetsproblemer i koden når du bruker verktøy som dette.
Begynner ...
I denne artikkelen så jeg på bare én av mange måter å finne sårbarheter på – statisk applikasjonssikkerhetstesting. Det er enkelt å utføre statisk kodeanalyse, men det er bare begynnelsen. For å lære mer om sikkerheten til kodebasen din, må du integrere andre typer testing i livssyklusen for programvareutvikling.
Om rettighetene til annonsering
og riktig valg av tariffplan vil tillate deg å bli mindre distrahert fra utvikling av ubehagelige problemer - alt vil fungere uten feil og med en veldig høy oppetid!
Kilde: www.habr.com