Hoe om 'n eenvoudige hulpmiddel te gebruik om kwesbaarhede in programkode te vind

Graudit ondersteun verskeie programmeertale en laat jou toe om kodebasissekuriteitstoetsing direk in die ontwikkelingsproses te integreer.

Bron: Unsplash (Markus Spiske)

Toetsing is 'n belangrike deel van die lewensiklus van sagteware-ontwikkeling. Daar is baie tipes toetse, elkeen los sy eie probleem op. Vandag wil ek praat oor die vind van sekuriteitsprobleme in kode.

Uiteraard is dit in die moderne realiteit van sagteware-ontwikkeling belangrik om prosessekuriteit te verseker. Op 'n tyd is die spesiale term DevSecOps selfs bekendgestel. Hierdie term verwys na 'n reeks prosedures wat daarop gemik is om kwesbaarhede in 'n toepassing te identifiseer en uit te skakel. Daar is gespesialiseerde oopbronoplossings vir die kontrolering van kwesbaarhede in ooreenstemming met standaarde OWASP, wat die verskillende tipes en gedrag van kwesbaarhede in bronkode beskryf.

Daar is verskillende benaderings om sekuriteitsprobleme op te los, soos Statiese Toepassingsekuriteitstoetsing (SAST), Dinamiese Toepassingsekuriteitstoetsing (DAST), Interaktiewe Toepassingsekuriteitstoetsing (IAST), Sagtewaresamestellingsanalise, ensovoorts.

Statiese toepassingsekuriteitstoetsing identifiseer foute in reeds geskrewe kode. Hierdie benadering vereis nie dat die toepassing loop nie, en daarom word dit statiese analise genoem.

Ek sal fokus op statiese kode-analise en 'n eenvoudige oopbron-instrument gebruik om alles in die praktyk te demonstreer.

Hoekom ek 'n oopbron-instrument vir statiese kode-sekuriteitsanalise gekies het

Daar is 'n aantal redes hiervoor: eerstens, dit is gratis omdat jy 'n instrument gebruik wat ontwikkel is deur 'n gemeenskap van eendersdenkende mense wat ander ontwikkelaars wil help. As jy 'n klein span of begin het, het jy 'n wonderlike geleentheid om geld te spaar deur oopbronsagteware te gebruik om die sekuriteit van jou kodebasis te toets. Tweedens elimineer dit die behoefte vir jou om 'n aparte DevSecOps-span te huur, wat jou koste verder verminder.

Goeie oopbronhulpmiddels word altyd geskep met inagneming van verhoogde vereistes vir buigsaamheid. Daarom kan hulle in byna enige omgewing gebruik word, wat 'n wye reeks take dek. Dit is baie makliker vir ontwikkelaars om sulke instrumente te koppel aan die stelsel wat hulle reeds gebou het terwyl hulle aan hul projekte gewerk het.

Maar daar kan tye wees wanneer jy 'n kenmerk nodig het wat nie beskikbaar is in die instrument wat jy kies nie. In hierdie geval het jy die geleentheid om sy kode te vurk en jou eie instrument te ontwikkel wat daarop gebaseer is met die funksionaliteit wat jy nodig het.

Aangesien die ontwikkeling van oopbronsagteware in die meeste gevalle aktief deur die gemeenskap beïnvloed word, word die besluit om veranderinge aan te bring redelik vinnig en op die punt gemaak: die ontwikkelaars van die oopbronprojek maak staat op terugvoer en voorstelle van gebruikers, op hul verslae van foute gevind en ander probleme.

Gebruik Graudit vir kodesekuriteitsanalise

Jy kan verskeie oopbronnutsmiddels vir statiese kode-analise gebruik; daar is geen universele hulpmiddel vir alle programmeertale nie. Die ontwikkelaars van sommige van hulle volg OWASP-aanbevelings en probeer om soveel tale as moontlik te dek.

Hier sal ons gebruik Graudit, 'n eenvoudige opdragreëlhulpmiddel wat ons sal toelaat om kwesbaarhede in ons kodebasis te vind. Dit ondersteun verskillende tale, maar hul stel is steeds beperk. Graudit is ontwikkel op grond van die grep-nutsprogram, wat eens onder die GNU-lisensie vrygestel is.

Daar is soortgelyke instrumente vir statiese kode-analise - Rough Auditing Tool for Security (RATS), Securitycompass Web Application Analysis Tool (SWAAT), flawfinder en so aan. Maar Graudit is baie buigsaam en het minimale tegniese vereistes. Jy kan egter probleme hê wat Graudit nie kan oplos nie. Dan kan jy hier ander opsies soek op hierdie lys.

Ons kan hierdie hulpmiddel in 'n spesifieke projek integreer, of dit beskikbaar stel aan 'n geselekteerde gebruiker, of dit gelyktydig in al ons projekte gebruik. Dit is ook waar Graudit se buigsaamheid ter sprake kom. Laat ons dus eers die repo kloon:

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

Kom ons skep nou 'n simboliese skakel vir Graudit om dit in opdragformaat te gebruik

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

Kom ons voeg 'n alias by .bashrc (of watter konfigurasielêer jy ook al gebruik):

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

Herlaai:

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

Kom ons kyk of die installasie suksesvol was:

$ graudit -h

As jy iets soortgelyks sien, dan is alles in orde.

Ek sal een van my bestaande projekte toets. Voordat u die instrument gebruik, moet 'n databasis geslaag word wat ooreenstem met die taal waarin my projek geskryf is. Die databasisse is geleë in die ~/gradit/signatures-lêergids:

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

So, ek het twee js-lêers van my projek getoets, en Graudit het inligting oor kwesbaarhede in my kode aan die konsole vertoon:

Jy kan probeer om jou projekte op dieselfde manier te toets. Jy kan 'n lys van databasisse vir verskillende programmeertale sien hier.

Voor- en nadele van Graudit

Graudit ondersteun baie programmeertale. Daarom is dit geskik vir 'n wye verskeidenheid gebruikers. Dit kan voldoende meeding met enige gratis of betaalde analoë. En dit is baie belangrik dat verbeterings steeds aan die projek aangebring word, en die gemeenskap help nie net die ontwikkelaars nie, maar ook ander gebruikers wat die instrument probeer uitpluis.

Dit is 'n handige hulpmiddel, maar tot dusver kan dit nie altyd presies vasstel wat die probleem met 'n verdagte stuk kode is nie. Die ontwikkelaars gaan voort om Graudit te verbeter.

Maar in elk geval is dit nuttig om aandag te gee aan potensiële sekuriteitsprobleme in die kode wanneer u gereedskap soos hierdie gebruik.

Begin ...

In hierdie artikel het ek net na een van baie maniere gekyk om kwesbaarhede te vind - statiese toepassingsekuriteitstoetsing. Dit is maklik om statiese kode-analise uit te voer, maar dit is net die begin. Om meer te wete te kom oor die sekuriteit van jou kodebasis, moet jy ander tipes toetse in jou sagteware-ontwikkelingslewensiklus integreer.

Oor die regte van reklame

Betroubare VPS en die korrekte keuse van tariefplan sal jou toelaat om minder van ontwikkeling afgelei te word deur onaangename probleme - alles sal werk sonder mislukkings en met 'n baie hoë uptyd!

Bron: will.com