Si të përdorni një mjet të thjeshtë për të gjetur dobësi në kodin e programit

Graudit mbështet shumë gjuhë programimi dhe ju lejon të integroni testimin e sigurisë së bazës së kodit drejtpërdrejt në procesin e zhvillimit.

Burimi: Unsplash (Markus Spiske)

Testimi është një pjesë e rëndësishme e ciklit jetësor të zhvillimit të softuerit. Ka shumë lloje të testimit, secila prej tyre zgjidh problemin e vet. Sot dua të flas për gjetjen e problemeve të sigurisë në kod.

Natyrisht, në realitetet moderne të zhvillimit të softuerit, është e rëndësishme të sigurohet siguria e procesit. Në një kohë, u prezantua edhe termi special DevSecOps. Ky term i referohet një sërë procedurash që synojnë identifikimin dhe eliminimin e dobësive në një aplikacion. Ekzistojnë zgjidhje të specializuara me burim të hapur për kontrollimin e dobësive në përputhje me standardet OWASP, të cilat përshkruajnë llojet e ndryshme dhe sjelljen e dobësive në kodin burimor.

Ekzistojnë qasje të ndryshme për zgjidhjen e problemeve të sigurisë, të tilla si Testimi Statik i Sigurisë së Aplikacioneve (SAST), Testimi Dinamik i Sigurisë së Aplikacioneve (DAST), Testimi ndërveprues i sigurisë së aplikacionit (IAST), Analiza e përbërjes së softuerit, etj.

Testimi statik i sigurisë së aplikacionit identifikon gabimet në kodin e shkruar tashmë. Kjo qasje nuk kërkon që aplikacioni të ekzekutohet, prandaj quhet analizë statike.

Do të përqendrohem në analizën e kodit statik dhe do të përdor një mjet të thjeshtë me burim të hapur për të demonstruar gjithçka në praktikë.

Pse zgjodha një mjet me burim të hapur për analizën e sigurisë së kodit statik

Ka një sërë arsyesh për këtë: së pari, është falas sepse po përdorni një mjet të zhvilluar nga një komunitet njerëzish me të njëjtin mendim që duan të ndihmojnë zhvilluesit e tjerë. Nëse keni një ekip të vogël ose startup, ju keni një mundësi të shkëlqyer për të kursyer para duke përdorur softuer me burim të hapur për të testuar sigurinë e bazës suaj të kodit. Së dyti, eliminon nevojën që ju të punësoni një ekip të veçantë DevSecOps, duke ulur më tej kostot tuaja.

Mjetet e mira me burim të hapur krijohen gjithmonë duke marrë parasysh kërkesat e rritura për fleksibilitet. Prandaj, ato mund të përdoren pothuajse në çdo mjedis, duke mbuluar një gamë të gjerë detyrash. Është shumë më e lehtë për zhvilluesit që të lidhin mjete të tilla me sistemin që ata kanë ndërtuar tashmë gjatë punës në projektet e tyre.

Por mund të ketë raste kur ju nevojitet një veçori që nuk është e disponueshme në mjetin që zgjidhni. Në këtë rast, ju keni mundësinë të forconi kodin e tij dhe të zhvilloni mjetin tuaj bazuar në të me funksionalitetin që ju nevojitet.

Meqenëse në shumicën e rasteve zhvillimi i softuerit me burim të hapur ndikohet në mënyrë aktive nga komuniteti, vendimi për të bërë ndryshime merret mjaft shpejt dhe deri në pikën: zhvilluesit e projektit me burim të hapur mbështeten në komentet dhe sugjerimet nga përdoruesit, në raportet e tyre për gabime të gjetura dhe probleme të tjera.

Përdorimi i Graudit për analizën e sigurisë së kodit

Ju mund të përdorni mjete të ndryshme me burim të hapur për analizën statike të kodit; nuk ka asnjë mjet universal për të gjitha gjuhët e programimit. Zhvilluesit e disa prej tyre ndjekin rekomandimet e OWASP dhe përpiqen të mbulojnë sa më shumë gjuhë të jetë e mundur.

Këtu do të përdorim Graudit, një mjet i thjeshtë i linjës së komandës që do të na lejojë të gjejmë dobësi në bazën tonë të kodeve. Ai mbështet gjuhë të ndryshme, por megjithatë grupi i tyre është i kufizuar. Graudit është zhvilluar në bazë të programit grep utility, i cili dikur u lëshua nën licencën GNU.

Ka mjete të ngjashme për analizën e kodit statik - Rough Auditing Tool for Security (RATS), Securitycompass Web Application Analysis Tool (SWAAT), flawfinder etj. Por Graudit është shumë fleksibël dhe ka kërkesa minimale teknike. Megjithatë, mund të keni probleme që Graudit nuk mund t'i zgjidhë. Atëherë mund të kërkoni opsione të tjera këtu në këtë listë.

Ne mund ta integrojmë këtë mjet në një projekt specifik, ose ta bëjmë të disponueshëm për një përdorues të zgjedhur, ose ta përdorim njëkohësisht në të gjitha projektet tona. Këtu hyn në lojë edhe fleksibiliteti i Graudit. Pra, le të klonojmë repon së pari:

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

Tani le të krijojmë një lidhje simbolike që Graudit ta përdorë atë në formatin e komandës

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

Le të shtojmë një pseudonim në .bashrc (ose çfarëdo skedari konfigurimi që po përdorni):

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

Rinisja:

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

Le të kontrollojmë nëse instalimi ishte i suksesshëm:

$ graudit -h

Nëse shihni diçka të ngjashme, atëherë gjithçka është në rregull.

Unë do të testoj një nga projektet e mia ekzistuese. Përpara ekzekutimit të mjetit, duhet t'i kalojë një bazë të dhënash që korrespondon me gjuhën në të cilën është shkruar projekti im. Bazat e të dhënave janë të vendosura në dosjen ~/gradit/signatures:

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

Pra, testova dy skedarë js nga projekti im dhe Graudit shfaqi informacione në lidhje me dobësitë në kodin tim në tastierë:

Ju mund të provoni të testoni projektet tuaja në të njëjtën mënyrë. Ju mund të shihni një listë të bazave të të dhënave për gjuhë të ndryshme programimi këtu.

Avantazhet dhe disavantazhet e Graudit

Graudit mbështet shumë gjuhë programimi. Prandaj, është i përshtatshëm për një gamë të gjerë përdoruesish. Mund të konkurrojë në mënyrë adekuate me çdo analog falas ose me pagesë. Dhe është shumë e rëndësishme që përmirësimet janë duke u bërë ende në projekt, dhe komuniteti jo vetëm që ndihmon zhvilluesit, por edhe përdoruesit e tjerë që po përpiqen të kuptojnë mjetin.

Ky është një mjet i dobishëm, por deri më tani nuk mund të përcaktojë gjithmonë saktësisht se cili është problemi me një pjesë të dyshimtë të kodit. Zhvilluesit vazhdojnë të përmirësojnë Graudit.

Por në çdo rast, është e dobishme t'i kushtoni vëmendje problemeve të mundshme të sigurisë në kod kur përdorni mjete si ky.

Fillon…

Në këtë artikull, unë shikova vetëm një nga mënyrat e shumta për të gjetur dobësitë - testimi statik i sigurisë së aplikacionit. Kryerja e analizës së kodit statik është e lehtë, por është vetëm fillimi. Për të mësuar më shumë rreth sigurisë së bazës suaj të kodeve, duhet të integroni lloje të tjera testimi në ciklin e jetës tuaj të zhvillimit të softuerit.

Për të Drejtat e Reklamimit

VPS e besueshme dhe zgjedhja e saktë e planit tarifor do t'ju lejojë të shpërqendroheni më pak nga zhvillimi nga problemet e pakëndshme - gjithçka do të funksionojë pa dështime dhe me një kohë shumë të lartë!

Burimi: www.habr.com