🥇Kuidas kasutada lihtsat tööriista haavatavuste leidmiseks tarkvarakoodis

Graudit toetab mitmeid programmeerimiskeeli ja võimaldab integreerida koodibaasi turvatestimise otse arendusprotsessi.

Allikas: Unsplash (Markus Spiske)

Testimine on tarkvaraarenduse elutsükli oluline osa. On olemas palju erinevaid testimisviise, igaühel on oma eesmärk. Täna tahan rääkida koodis turvaprobleemide leidmisest.

On ilmne, et tänapäeva tarkvaraarenduse tingimustes on oluline tagada protsesside turvalisus. Mingil ajal ilmus isegi spetsiaalne mõisted DevSecOps. Selle terminiga mõistetakse rida protseduure, mis on suunatud rakenduse haavatavuste kindlakstegemisele ja kõrvaldamisele. On olemas spetsialiseeritud avatud lähtekoodiga lahendused haavatavuste kontrollimiseks vastavalt standarditele OWASP, mis kirjeldavad erinevaid tüüpe ja käitumist haavatavusi lähtekoodis.

On erinevaid lähenemisviise turvaprobleemide lahendamiseks, näiteks rakenduste staatiline turvatestimine (SAST), dünaamiline turvatestimine (DAST), interaktiivne rakenduste turvatestimine (IAST), tarkvara koostisosade analüüs (Software Composition Analysis) jne.

Staatiline rakenduste turvatestimine avastab vigu juba kirjutatud koodis. See lähenemine ei nõua rakenduse käivitamist, seetõttu nimetatakse seda staatiliseks analüüsiks.

Ma peatun koodi staatilisel analüüsil ja kasutan lihtsat avatud lähtekoodiga tööriista, et demonstreerida kõike praktikas.

Miks ma valisin avatud lähtekoodiga tööriista koodi staatiliseks turvaanalüüsiks

Sellel on mitmeid põhjuseid: esiteks, see on tasuta, kuna kasutate tööriista, mille on välja töötanud sarnaste huvidega kogukond, kes soovib aidata teisi arendajaid. Kui teil on väike meeskond või idufirma, on teil suurepärane võimalus säästa, kasutades avatud lähtekoodiga tarkvara oma koodibaasi turvalisuse kontrollimiseks. Teiseks, see vabastab teid vajadusest palgata eraldi DevSecOps meeskond, mis veelgi vähendab teie kulusid.

Headless open source tööriistad arvestavad alati suurenenud paindlikkuse nõudmistega. Seetõttu saab neid kasutada praktiliselt igas keskkonnas, katab lai valik ülesandeid. Arendajatele on palju lihtsam neid tööriistu siduda süsteemiga, mida nad on juba oma projektide kallal töötades ehitanud.

Aga võivad tekkida olukorrad, kus vajate funktsiooni, mida teie valitud tööriist ei paku. Sellisel juhul on teil võimalus selle koodi forkitada ja arendada selle alusel oma tööriist, millel on vajalikud funktsionaalsused.

Kuna avatud lähtekoodiga tarkvara arendusele avaldab enamasti tugevat mõju kogukond, võetakse muudatuste tegemise otsus piisavalt kiiresti ja asjakohaselt: avatud lähtekoodiga projekti arendajad tuginevad kasutajate tagasisidele ja ettepanekutele, nende sõnumitele leitud vigade ja teiste probleemide kohta.

Graudit'i kasutamine koodi turvaanalüüsiks

Koodi staatiliseks analüüsiks saab kasutada erinevaid avatud lähtekoodiga tööriistu, universaalset tööriista kõigi programmeerimiskeelte jaoks ei eksisteeri. Mõned arendajad järgivad OWASP-i soovitusi ja püüavad katta nii palju keeli kui võimalik.

Siin kasutame Graudit, lihtsat käsurea utiliiti, mis võimaldab meil leida haavatavusi meie koodibaasis. See toetab erinevaid keeli, kuid siiski on nende hulk piiratud. Graudit on välja töötatud grep'i teenusutiliidi põhjal, mis toodi kunagi välja GNU litsentsi all.

On olemas sarnased tööriistad staatiliseks koodi analüüsiks — Rough Auditing Tool for Security (RATS), Securitycompass Web Application Analysis Tool (SWAAT), flawfinder ja nii edasi. Kuid Graudit on väga paindlik ja omab minimaalset tehnilist nõudlust. Siiski võivad tekkida ülesanded, mida Graudit lahendada ei suuda. Siis võite otsida teisi variante siit selles nimekirjas.

Me saame integreerida selle tööriista konkreetse projekti, muuta selle valitud kasutajale kergesti kättesaadavaks või kasutada seda samaaegselt kõigis meie projektides. See on veel üks Graudit'i paindlikkuse näide. Nii et kõigepealt kloonime repositooriumi:

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

Nüüd loome Graudit jaoks sümboolse lingi, et seda käsurea formaadis kasutada.

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

Lisame aliase .bashrc faili (või mõnda teise konfiguratsioonifaili, mida kasutate):

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

Laadime süsteemi uuesti:

$ source ~/.bashrc # VÕI
$ exec $SHELL

Kontrollime, kas installatsioon õnnestus:

$ graudit -h

Kui näete midagi sarnast, siis kõik on hästi.

Ma hakkan testima üht minu olemasolevat projekti. Enne tööriista käivitamist tuleb sellele edastada andmebaas, mis vastab selle programmeerimiskeelele, milles minu projekt on kirjutatud. Andmebaasid asuvad kaustas ~/gradit/signatures:

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

Seega testisin kahte js-faili oma projektist ja Graudit näitas konsoolis teavet minu koodi haavatavuste kohta:

Saate proovida oma projekte selliselt testida. Erinevat tüüpi programmeerimiskeelte andmebaaside nimekirja leiate siin.

Grauditi plussid ja miinused

Graudit toetab mitmeid programmeerimiskeeli. Seetõttu sobib see laiale kasutajaskonnale. See suudab väärika konkurentsiga toime tulla mis tahes tasuta või tasuliste analoogidega. On väga oluline, et projekti parendused jätkuvad ja kogukond aitab mitte ainult arendajaid, vaid ka teisi kasutajaid, kes püüavad tööriista mõista.

See on mugav tööriist, kuid praegu ei suuda see alati täpselt näidata, milles probleem seisneb, mis on seotud kahtlase koodiosas. Arendajad jätkavad Grauditi täiustamist.

Kuid igal juhul on kasulik pöörata tähelepanu potentsiaalsetele turvaprobleemidele koodis, kasutades sarnaseid tööriistu.

Algus…

Selles artiklis käsitlesin vaid ühte paljusid viise haavatavuste otsimiseks — rakenduste staatilist turvatestimist. Koodi staatiline analüüs on lihtne teostada, kuid see on vaid algus. Et rohkem teada saada oma koodibaasi turvalisusest, tuleb integreerida tarkvaraarenduse elutsüklisse teisi testimisviise.