Metóda kontroly statického kódu. Analýza staršieho kódu, keď sa zdrojový kód stratí: robiť alebo nerobiť? Kombinácia postupnosti akcií rôznych typov analýz vo vývojovom prostredí

Úvod

Štandardné funkcie softvérových produktov a rôznych riadiacich systémov sú pre väčšinu zákazníkov nedostatočné. Systémy na správu webových stránok (napríklad WordPress, Joomla alebo Bitrix), účtovné programy, systémy správy zákazníkov (CRM), podnikové a výrobné (napríklad 1C a SAP) poskytujú dostatok príležitostí na rozšírenie funkčnosti a prispôsobenie sa potrebám konkrétnych zákazníkov. Takéto príležitosti sa implementujú pomocou modulov tretích strán, vyrobených na mieru alebo prispôsobením existujúcich. Tieto moduly sú programový kód napísaný v jednom zo vstavaných programovacích jazykov, ktorý interaguje so systémom a implementuje funkcie požadované zákazníkmi.

Nie všetky organizácie si uvedomujú, že na mieru vyrobený vložiteľný kód alebo webová stránka môžu obsahovať vážne zraniteľné miesta, ktorých zneužitie útočníkom môže viesť k úniku dôverných informácií, a karty programu sú špeciálne časti kódu určené na vykonávanie akejkoľvek operácie s tajnými príkazmi. známy vývojárovi kódu. Okrem toho môže vlastný kód obsahovať chyby, ktoré môžu zničiť alebo poškodiť databázy alebo narušiť dobre zavedené obchodné procesy.

Spoločnosti, ktoré sú oboznámené s vyššie popísanými rizikami, sa snažia do prijímania hotových modulov zapojiť audítorov a špecialistov na analýzu zdrojového kódu programu, aby odborníci určili bezpečnosť vyvíjaného riešenia a ubezpečili sa, že neobsahuje zraniteľné miesta, chyby, alebo programové karty. Ale tento spôsob ovládania má množstvo nevýhod. Po prvé, táto služba vážne zvyšuje rozpočet na vývoj; po druhé, audit a analýza trvá dlho - od týždňa do niekoľkých mesiacov; a po tretie, tento prístup nezaručuje úplnú absenciu problémov s analyzovaným kódom - existuje možnosť ľudskej chyby a detekcie predtým neznámych vektorov útoku po prijatí kódu a spustení prevádzky.

Existuje bezpečná metodika vývoja, ktorá zabezpečuje integráciu procesov auditu a kontroly kódu vo fáze tvorby softvérového produktu - SDL (Security Development Lifecycle, bezpečný vývojový životný cyklus). Túto metodiku však môže použiť iba vývojár softvéru, ak hovoríme o zákazníkoch, potom SDL nie je pre nich použiteľný, pretože proces zahŕňa reštrukturalizáciu algoritmov generovania kódu a po prijatí je príliš neskoro na jeho použitie. Okrem toho mnohé zmeny ovplyvňujú malú časť existujúceho kódu, v takom prípade sa SDL tiež nedá použiť.

Na vyriešenie problému auditovania zdrojového kódu a zabezpečenie ochrany pred zneužitím zraniteľností vo vstavaných kódoch a webových aplikáciách existujú analyzátory zdrojového kódu.

Klasifikácia analyzátorov zdrojového kódu

Analyzátory zdrojového kódu sú triedou softvérových produktov určených na zisťovanie a predchádzanie zneužitiu softvérových chýb v zdrojových kódoch. Všetky produkty zamerané na analýzu zdrojového kódu možno podmienečne rozdeliť do troch typov:

• Do prvej skupiny patria analyzátory kódu webových aplikácií a nástroje na predchádzanie zneužitiu zraniteľností webových stránok.
• Druhou skupinou sú zabudovateľné analyzátory kódu, ktoré umožňujú odhaliť problémové oblasti v zdrojovom kóde modulov určených na rozšírenie funkcionality podnikových a produkčných systémov. Tieto moduly zahŕňajú programy pre produktovú radu 1C, rozšírenia CRM systémov, podnikové riadiace systémy a systémy SAP.
• Posledná skupina je určená na analýzu zdrojového kódu v rôznych programovacích jazykoch, ktoré nesúvisia s obchodnými aplikáciami a webovými aplikáciami. Takéto analyzátory sú určené pre zákazníkov a vývojárov softvéru. Najmä táto skupina analyzátorov sa používa na použitie metodiky bezpečného vývoja softvéru. Analyzátory statického kódu nachádzajú problémy a potenciálne zraniteľné miesta v zdrojových kódoch a poskytujú odporúčania na ich odstránenie.

Je potrebné poznamenať, že väčšina analyzátorov je zmiešaného typu a vykonáva funkcie analýzy širokej škály softvérových produktov - webových aplikácií, vstavaného kódu a konvenčného softvéru. V tomto prehľade sa však kladie dôraz na používanie analyzátorov vývojovými zákazníkmi, takže väčšia pozornosť sa venuje webovým aplikáciám a analyzátorom vstavaného kódu.

Analyzátory môžu obsahovať rôzne analytické mechanizmy, ale najbežnejšia a najuniverzálnejšia je statická analýza zdrojového kódu - SAST (Static Application Security Testing), existujú aj dynamické analytické metódy - DAST (Dynamic Application Security Testing), ktoré kontrolujú kód počas jeho vykonávania, a rôzne hybridné možnosti, ktoré kombinujú rôzne typy analýz. Dynamická analýza je samostatná overovacia metóda, ktorá môže rozšíriť možnosti statickej analýzy alebo sa dá použiť samostatne v prípadoch, keď nie je dostupný prístup k zdrojovým kódom. V tomto prehľade sa berú do úvahy iba statické analyzátory.

Vstavané analyzátory kódu a analyzátory webových aplikácií sa líšia v súbore charakteristík. Zahŕňa nielen kvalitu analýzy a zoznam podporovaných softvérových produktov a programovacích jazykov, ale aj ďalšie mechanizmy: schopnosť automaticky opravovať chyby, dostupnosť funkcií na zabránenie zneužitia chýb bez zmeny kódu, schopnosť aktualizovať vstavaná databáza zraniteľností a programových chýb, dostupnosť certifikátov zhody a schopnosť splniť požiadavky rôznych regulátorov.

Ako fungujú analyzátory zdrojového kódu

Všeobecné princípy fungovania sú podobné pre všetky triedy analyzátorov: analyzátory zdrojového kódu webových aplikácií aj analyzátory vložiteľného kódu. Rozdiel medzi týmito typmi produktov je iba v schopnosti určiť vlastnosti vykonávania kódu a interakcie s vonkajším svetom, čo sa odráža v databázach zraniteľnosti analyzátora. Väčšina analyzátorov na trhu vykonáva funkcie oboch tried, pričom rovnako dobre kontroluje kód vložený do podnikových aplikácií a kód webovej aplikácie.

Vstupnými údajmi pre analyzátor zdrojového kódu je pole zdrojových kódov programu a jeho závislostí (načítateľné moduly, použitý softvér tretích strán atď.). Výsledkom práce je, že všetky analyzátory vydávajú správu o zistených zraniteľnostiach a programových chybách, niektoré analyzátory navyše poskytujú funkcie na automatickú opravu chýb.

Je potrebné poznamenať, že automatická oprava chýb nefunguje vždy správne, preto je táto funkcionalita určená len pre vývojárov webových aplikácií a embedded modulov, zákazník produktu by sa mal spoľahnúť iba na záverečnú správu analyzátora a získané údaje použiť na rozhodnúť o prijatí a implementácii vyvinutého kódu alebo o jeho zaslaní na revíziu.

Obrázok 1. Algoritmus analyzátora zdrojového kódu

Pri vyhodnocovaní zdrojového kódu používajú analyzátory rôzne databázy obsahujúce popisy zraniteľností a programových chýb:

• Vlastná databáza zraniteľností a programátorských chýb – každý vývojár analyzátorov zdrojového kódu má svoje analytické a výskumné oddelenia, ktoré pripravujú špecializované databázy na analýzu zdrojových kódov programov. Kvalita vlastnej databázy je jedným z kľúčových kritérií, ktoré ovplyvňujú celkovú kvalitu produktu. Okrem toho musí byť vaša vlastná databáza dynamická a neustále aktualizovaná – nové vektory útokov a zneužívanie slabých miest, ako aj zmeny v programovacích jazykoch a metódach vývoja vyžadujú, aby vývojári analyzátorov neustále aktualizovali databázu, aby sa udržali kontroly vysokej kvality. V porovnávacích testoch najčastejšie strácajú produkty so statickým neaktualizovateľným základom.
• Národné databázy programových chýb – existuje množstvo národných databáz zraniteľností, ktoré zostavujú a spravujú regulačné orgány v rôznych krajinách. Napríklad v Spojených štátoch amerických sa používa základňa CWE – Common Weakness Enumeration, ktorú spravuje organizácia MITER, ktorú okrem iného podporuje aj ministerstvo obrany USA. Rusko zatiaľ podobnú databázu nemá, ale FSTEC Ruska plánuje v budúcnosti doplniť svoje databázy zraniteľností a hrozieb o databázu programovacích chýb. Analyzátory zraniteľností implementujú podporu pre databázu CWE tak, že ju vložia do vlastnej databázy zraniteľností alebo ju použijú ako samostatný overovací mechanizmus.
• Štandardné požiadavky a odporúčania pre bezpečné programovanie – existuje ako množstvo vládnych a priemyselných štandardov, ktoré popisujú požiadavky na bezpečný vývoj aplikácií, tak aj množstvo odporúčaní a „best practices“ od svetových odborníkov v oblasti vývoja a ochrany softvéru . Tieto dokumenty priamo nepopisujú chyby programovania, na rozdiel od CWE, ale obsahujú zoznam metód, ktoré je možné skonvertovať na použitie v statickom analyzátore zdrojového kódu.

Kvalita analýzy, počet falošne pozitívnych výsledkov a vynechaných chýb priamo závisia od toho, aké bázy sa v analyzátore používajú. Analýza súladu s požiadavkami regulátorov navyše umožňuje uľahčiť a zjednodušiť postup externého auditu infraštruktúry a informačného systému v prípade, že sú požiadavky povinné. Napríklad požiadavky PCI DSS sú povinné pre webové aplikácie a vložený kód, ktorý pracuje s informáciami o platbe bankovou kartou, pričom sa vykonáva externý audit dodržiavania PCI DSS vrátane analýzy používaných softvérových produktov.

svetový trh

Na svetovom trhu existuje veľa rôznych analyzátorov – od známych predajcov v oblasti bezpečnosti, ako aj od špecializovaných hráčov, ktorí sa zaoberajú iba touto triedou produktov. Analytické centrum Gartner klasifikuje a vyhodnocuje analyzátory zdrojového kódu už viac ako päť rokov, kým do roku 2011 Gartner vyčlenil statické analyzátory, o ktorých sa hovorí v tomto článku, samostatne a neskôr ich spojil do vyššej triedy – nástrojov na testovanie bezpečnosti aplikácií (Application Security Testing). .).

V Gartner Magic Quadrant v roku 2015 sú HP, Veracode a IBM lídrami na trhu v testovaní bezpečnosti. Veracode je zároveň jedinou z popredných spoločností, ktorá nemá analyzátor ako softvérový produkt a funkčnosť je poskytovaná len ako služba v cloude Veracode. Zvyšok popredných spoločností ponúka buď výlučne produkty, ktoré vykonávajú kontroly na počítačoch používateľov, alebo možnosť vybrať si medzi produktom a cloudovou službou. HP a IBM zostávajú lídrami na svetovom trhu za posledných päť rokov, prehľad ich produktov je uvedený nižšie. Najbližšie k popredným priečkam má produkt Checkmarx, ktorý sa špecializuje len na túto triedu produktov, preto je tiež zaradený do recenzie.

Obrázok 2. Magický kvadrant analytikovGartner podľa hráčov na trhu analýzy zabezpečenia aplikácií v auguste 2015

Podľa správy analytika ReportsnReports predstavovala veľkosť trhu analyzátorov zdrojového kódu v USA v roku 2014 2,5 miliardy USD, do roku 2019 sa predpokladá zdvojnásobenie rastu na 5 miliárd USD s ročným rastom 14,9 %. Viac ako 50 % organizácií, ktoré sa zúčastnili prieskumu pre túto správu, plánuje prideliť a zvýšiť rozpočty na analýzu zdrojového kódu v rámci vlastného vývoja a iba 3 % sa vyjadrili negatívne o používaní týchto produktov.

Veľký počet produktov v oblasti challengers potvrdzuje obľúbenosť tejto triedy produktov a rýchly rozvoj odvetvia. Za posledných päť rokov sa celkový počet výrobcov v tomto kvadrante takmer strojnásobil a v porovnaní so správou z roku 2014 pribudli tri produkty.

ruský trh

Ruský trh analyzátorov zdrojového kódu je pomerne mladý - prvé verejné produkty sa začali objavovať na trhu pred menej ako piatimi rokmi. Zároveň sa trh formoval z dvoch smerov - na jednej strane spoločnosti vyvíjajúce produkty na testovanie na identifikáciu nedeklarovaných spôsobilostí v laboratóriách FSTEC, FSB a Ministerstva obrany Ruskej federácie; na druhej strane sa spoločnosti zaoberajúce sa rôznymi oblasťami bezpečnosti rozhodli pridať do svojho portfólia novú triedu produktov.

Najvýznamnejšími hráčmi na novom trhu sú Positive Technologies, InfoWatch a Solar Security. Positive Technologies sa už dlho špecializuje na vyhľadávanie a analýzu slabých miest; do ich portfólia patrí produkt MaxPatrol, jeden z lídrov na domácom trhu v oblasti externej bezpečnostnej kontroly, a preto niet divu, že sa spoločnosť rozhodla pre internú analýzu a vývoj vlastného analyzátora zdrojového kódu. InfoWatch sa vyvinul ako vývojár systémov DLP a nakoniec sa zmenil na skupinu spoločností hľadajúcich nové medzery na trhu. Appercut sa pripojil k InfoWatch v roku 2012 a pridal do portfólia InfoWatch nástroj na analýzu zdrojového kódu. Investície a skúsenosti spoločnosti InfoWatch umožnili rýchlo vyvinúť produkt na vysokú úroveň. Solar Security oficiálne predstavil svoj produkt Solar inCode až koncom októbra 2015, no už v čase vydania mali štyri oficiálne implementácie v Rusku.

Spoločnosti, ktoré už desaťročia vyvíjajú analyzátory zdrojového kódu na certifikačné testovanie, sa vo všeobecnosti neponáhľajú s ponukou analyzátorov pre podnikanie, takže naša recenzia uvádza iba jeden takýto produkt – od spoločnosti Echelon. Snáď sa mu v budúcnosti podarí vytlačiť ďalších hráčov na trhu, predovšetkým vďaka veľkým teoretickým a praktickým skúsenostiam vývojárov tohto produktu v oblasti hľadania zraniteľností a nedeklarovaných vlastností.

Ďalším okrajovým hráčom na ruskom trhu je spoločnosť Digital Security, poradenská spoločnosť v oblasti informačnej bezpečnosti. Po rozsiahlych skúsenostiach s auditom a implementáciou ERP systémov našla neobsadené miesto a pustila sa do vývoja produktu na analýzu bezpečnosti ERP systémov, ktorý okrem iných funkcií obsahuje aj mechanizmy na analýzu zdrojových kódov pre vstavané programy.

Stručný prehľad analyzátorov

Prvý nástroj na analýzu zdrojového kódu v našej recenzii je produktom spoločnosti Fortify, ktorú vlastní spoločnosť Hewlett-Packard od roku 2010. Rad HP Fortify zahŕňa rôzne produkty na analýzu programových kódov: existuje aj služba Fortify On-Demand SaaS, ktorá zahŕňa nahrávanie zdrojového kódu do cloudu HP, a plnohodnotná aplikácia HP Fortify Static Code Analyzer nainštalovaná v infraštruktúre zákazníka.

HP Fortify Static Code Analyzer podporuje širokú škálu programovacích jazykov a platforiem, vrátane webových aplikácií napísaných v PHP, Python, Java/JSP, ASP.Net a JavaScript a vnoriteľného kódu v ABAP (SAP), Action Script a VBScript.

Obrázok 3. Rozhranie analyzátora statického kódu HP Fortify

Medzi funkciami produktu stojí za to zdôrazniť prítomnosť podpory integrácie s rôznymi systémami riadenia vývoja a sledovania chýb v nástroji HP Fortify Static Code Analyzer. Ak vývojár kódu poskytne zákazníkovi prístup k priamemu hláseniu chýb do Bugzilla, HP Quality Center alebo Microsoft TFS, analyzátor môže automaticky generovať hlásenia o chybách v týchto systémoch bez potreby manuálnych krokov.

Fungovanie produktu je založené na vlastných znalostných bázach HP Fortify, vytvorených prispôsobením bázy CWE. Produkt implementuje analýzu, aby spĺňal požiadavky odporúčaní DISA STIG, FISMA, PCI DSS a OWASP.

Medzi nedostatky HP Fortify Static Code Analyzer je potrebné poznamenať nedostatočnú lokalizáciu produktu pre ruský trh - rozhranie a správy sú v angličtine, nedostatok materiálov a dokumentácie k produktu v ruštine, analýza vstavaných kód pre 1C a iné domáce produkty na podnikovej úrovni nie je podporovaný.

Výhody analyzátora statického kódu HP Fortify:

• známa značka, vysoko kvalitné riešenie;
• veľký zoznam analyzovaných programovacích jazykov a podporovaných vývojových prostredí;
• schopnosť integrovať sa so systémami riadenia vývoja a inými produktmi HP Fortify;
• podpora medzinárodných noriem, odporúčaní a „osvedčených postupov“.

Checkmarx CxSAST je nástroj americko-izraelskej spoločnosti Checkmarx, ktorá sa špecializuje na vývoj analyzátorov zdrojového kódu. Tento produkt je určený predovšetkým na analýzu bežného softvéru, no vďaka podpore programovacích jazykov PHP, Python, JavaScript, Perl a Ruby je skvelý na analýzu webových aplikácií. Checkmarx CxSAST je univerzálny analyzátor, ktorý nemá výraznú špecifickosť, a preto je vhodný na použitie v ktorejkoľvek fáze životného cyklu softvérového produktu – od vývoja až po aplikáciu.

Obrázok 4. Rozhranie Checkmarx CxSAST

Checkmarx CxSAST implementuje podporu pre chybovú bázu kódu programu CWE, sú podporované kontroly súladu OWASP a SANS 25, PCI DSS, HIPAA, MISRA, FISMA a BSIMM. Všetky problémy zistené Checkmarx CxSAST sú kategorizované podľa závažnosti, od menej závažných až po kritické. Jednou z vlastností produktu je prítomnosť funkcií na vizualizáciu kódu s konštrukciou vývojových diagramov vykonávacích trás a odporúčania na nápravu problémov s prepojením na grafický diagram.

Medzi nevýhody produktu patrí nedostatočná podpora analýzy kódu zabudovaného do podnikových aplikácií, chýbajúca lokalizácia a náročnosť používania produktu pre zákazníkov programového kódu, keďže riešenie je určené predovšetkým pre vývojárov a je úzko integrované s vývojovými prostrediami. .

Výhody Checkmarx CxSAST:

• veľké množstvo podporovaných programovacích jazykov;
• vysoká rýchlosť produktu, schopnosť skenovať iba nominálne časti kódu;
• schopnosť vizualizovať grafy vykonávania analyzovaného kódu;
• vizuálne správy a graficky navrhnuté metriky zdrojového kódu.

Ďalším produktom od známeho dodávateľa je analyzátor zdrojového kódu IBM Security AppScan. Rad AppScan obsahuje mnoho produktov súvisiacich s bezpečným vývojom softvéru, ale iné produkty nebudú vhodné na používanie programového kódu zákazníkmi, pretože majú veľa nepotrebných funkcií. IBM Security AppScan Source, podobne ako Checkmarx CxSAST, je primárne určený pre vývojárske organizácie, pričom podporuje ešte menej jazykov pre vývoj webových aplikácií – iba PHP, Perl a JavaScript. Programovacie jazyky pre kód vložený do obchodných aplikácií nie sú podporované.

Obrázok 5. Zdrojové rozhranie IBM Security AppScan

IBM Security AppScan Source je úzko integrovaný s vývojovou platformou IBM Rational, takže produkt sa najčastejšie používa vo fáze vývoja a testovania softvérových produktov a nie je vhodný na prijatie alebo overenie vlastnej aplikácie.

Funkciou IBM Security AppScan Source je, že podporuje analýzu programu pre IBM Worklight, platformu pre mobilné podnikové aplikácie. Zoznam podporovaných štandardov a požiadaviek je riedky - odporúčania PCI DSS a DISA a OWASP, databáza zraniteľností porovnáva nájdené problémy s CWE.

Neboli identifikované žiadne konkrétne výhody tohto riešenia pre vývojových zákazníkov.

AppChecker od domácej spoločnosti CJSC NPO Echelon je riešením, ktoré sa objavilo na trhu pomerne nedávno. Prvá verzia produktu bola vydaná len pred rokom, ale mali by sa vziať do úvahy skúsenosti spoločnosti Echelon s analýzou kódu. "NPO Echelon" je testovacie laboratórium FSTEC, FSB a Ministerstva obrany Ruskej federácie a má rozsiahle skúsenosti v oblasti statickej a dynamickej analýzy zdrojových kódov programov.

Obrázok 6. Rozhranie "Echelon" AppChecker

AppChecker je navrhnutý tak, aby analyzoval množstvo softvéru a webových aplikácií napísaných v jazykoch PHP, Java a C/C++. Plne podporuje klasifikáciu zraniteľnosti CWE a zohľadňuje odporúčania OWASP, CERT a NISP. Produkt je možné použiť na vykonanie auditu zhody s požiadavkami PCI DSS a štandardom Bank of Russia IBBS-2.6-2014.

Nevýhody produktu sú spôsobené ranou fázou vývoja riešenia - nie je dostatočná podpora pre populárne jazyky vývoja webu a schopnosť analyzovať vložený kód.

výhody:

• možnosť vykonania auditu podľa domácich požiadaviek a PCI DSS;
• berúc do úvahy vplyv funkcií programovacích jazykov vďaka flexibilnej konfigurácii analyzovaných projektov;
• nízke náklady.

PT Application Inspector je produktom ruského vývojára Positive Technologies, ktorý sa vyznačuje prístupom k riešeniu problému analýzy zdrojového kódu. PT Application Inspector je primárne zameraný na nájdenie zraniteľností v kóde a nie na identifikáciu bežných softvérových chýb.

Na rozdiel od všetkých ostatných produktov v tejto recenzii má PT Application Inspector nielen schopnosť generovať správu a demonštrovať zraniteľnosti, ale aj schopnosť automaticky vytvárať exploity pre určité kategórie a typy zraniteľností – malé spustiteľné moduly, ktoré využívajú nájdené zraniteľnosti. Pomocou vytvorených exploitov je možné v praxi kontrolovať nebezpečnosť nájdených zraniteľností, ako aj kontrolovať vývojára kontrolou fungovania exploitu po deklarovanom uzavretí zraniteľnosti.

Obrázok 7. Rozhranie PT Application Inspector

PT Application Inspector podporuje vývojové jazyky webových aplikácií (PHP, JavaScript) aj vstavaný kód pre podnikové aplikácie - SAP ABAP, SAP Java, Oracle EBS Java, Oracle EBS PL/SQL. Produkt PT Application Inspector tiež podporuje vizualizáciu ciest vykonávania programu.

PT Application Inspector je komplexné riešenie pre vývojárov aj zákazníkov prevádzkujúcich vlastné webové aplikácie a zásuvné moduly pre podnikové aplikácie. Databáza zraniteľností a chýb v programovom kóde obsahuje vlastný vývoj Positive Technologies, databázu CWE a WASC (Web Consortium Vulnerability Database, analóg CWE pre webové aplikácie).

Používanie PT Application Inspector vám umožňuje splniť požiadavky PCI DSS, STO BR IBBS, ako aj Príkaz 17 FSTEC a požiadavku na absenciu nedeklarovaných schopností (relevantné pre certifikáciu kódu).

výhody:

• podpora pre analýzu webových aplikácií a veľký súbor vývojových systémov pre obchodné aplikácie;
• domáci, lokalizovaný produkt;
• široká škála podporovaných štátnych noriem;
• pomocou databázy zraniteľností webových aplikácií WASC a klasifikátora CWE;
• schopnosť vizualizovať kód programu a vyhľadávať záložky programu.

InfoWatch Appercut vyvinula ruská spoločnosť InfoWatch. Hlavným rozdielom medzi týmto produktom a všetkými ostatnými v tejto kolekcii je jeho špecializácia na poskytovanie služby zákazníkom podnikových aplikácií.

InfoWatch Appercut podporuje takmer všetky programovacie jazyky, ktoré vytvárajú webové aplikácie (JavaScript, Python, PHP, Ruby) a zásuvné moduly pre obchodné ponuky - 1C, ABAP, X++ (ERP Microsoft Axapta), Java, Lotus Script. InfoWatch Appercut má schopnosť prispôsobiť sa špecifikám konkrétnej aplikácie a jedinečnosti obchodných procesov každej spoločnosti.

Obrázok 8. Rozhranie InfoWatch Appercut

InfoWatch Appercut podporuje mnohé požiadavky na efektívne a bezpečné programovanie, vrátane všeobecných požiadaviek PCI DSS a HIPPA, odporúčaní CERT a OWAST a „best practices“, ako aj odporúčaní výrobcov platforiem podnikových procesov – 1C, SAP, Oracle, Microsoft.

výhody:

• domáci, lokalizovaný produkt certifikovaný FSTEC Ruska;
• jediný produkt, ktorý podporuje všetky populárne obchodné platformy v Rusku, vrátane 1C, SAP, Oracle EBS, IBM Collaboration Solutions (Lotus) a Microsoft Axapta;
• rýchly skener, ktorý vykonáva kontroly v priebehu niekoľkých sekúnd a je schopný kontrolovať iba upravený kód a úryvky kódu.

Digital Security ERPScan je špecializovaný produkt na analýzu a monitorovanie bezpečnosti podnikových systémov postavený na produktoch SAP, prvá verzia bola vydaná v roku 2010. Okrem modulu konfigurácie, zraniteľnosti a kontroly prístupu (SOD) obsahuje ERPScan modul hodnotenia bezpečnosti zdrojového kódu, ktorý implementuje funkcie vyhľadávania záložiek, kritických volaní, zraniteľností a programovacích chýb v kóde v programovacích jazykoch ABAP a Java. Produkt zároveň zohľadňuje špecifiká platformy SAP, koreluje zistené zraniteľnosti v kóde s konfiguračnými nastaveniami a prístupovými právami a vykonáva analýzu lepšie ako nešpecializované produkty, ktoré pracujú s rovnakými programovacími jazykmi.

Obrázok 9 Rozhranie digitálneho zabezpečenia ERPScan

Medzi ďalšie funkcie ERPScan patrí schopnosť automaticky generovať záplaty pre zistené zraniteľnosti, ako aj generovať podpisy pre možné útoky a nahrávať tieto podpisy do systémov detekcie a prevencie narušenia (v spolupráci so spoločnosťou CISCO). Okrem toho systém obsahuje mechanizmy na vyhodnocovanie výkonu vloženého kódu, ktorý je pre podnikové aplikácie kritický, pretože pomalá prevádzka ďalších modulov môže vážne ovplyvniť obchodné procesy v organizácii. Systém tiež podporuje analýzu v súlade so špecifickými odporúčaniami pre analýzu kódu podnikových aplikácií, ako sú EAS-SEC a BIZEC, ako aj všeobecnými odporúčaniami PCI DSS a OWASP.

výhody:

• hlboká špecializácia na jednu platformu podnikových aplikácií s koreláciou analýzy s konfiguračnými nastaveniami a prístupovými právami;
• testy výkonnosti vloženého kódu;
• automatické vytváranie opráv nájdených zraniteľností a virtuálnych záplat;
• hľadať zraniteľnosti zero-day.

Solar inCode je nástroj na analýzu statického kódu určený na zisťovanie slabých miest zabezpečenia informácií a nedeklarovaných funkcií v zdrojovom kóde softvéru. Hlavným rozlišovacím znakom produktu je schopnosť obnoviť zdrojový kód aplikácií z pracovného súboru pomocou technológie dekompilácie (reverzné inžinierstvo).

Solar inCode umožňuje analyzovať zdrojový kód napísaný v programovacích jazykoch Java, Scala, Java pre Android, PHP a Objective C. Na rozdiel od väčšiny konkurentov zoznam podporovaných programovacích jazykov obsahuje vývojové nástroje pre mobilné platformy Android a iOS.

Obrázok 10 Rozhranie

V prípadoch, keď zdrojový kód nie je dostupný, Solar inCode umožňuje analýzu hotových aplikácií, táto funkcionalita podporuje webové aplikácie a mobilné aplikácie. Najmä pri mobilných aplikáciách stačí do skenera skopírovať odkaz na aplikáciu z Google Play alebo Apple Store, aplikácia sa automaticky stiahne, dekompiluje a skontroluje.

Používanie Solar inCode vám umožňuje splniť požiadavky PCI DSS, STO BR IBBS, ako aj príkaz 17 FSTEC a požiadavku na absenciu nedeklarovaných schopností (relevantné pre certifikáciu kódu).

výhody:

• Podpora analýzy aplikácií pre mobilné zariadenia so systémom Android a iOS;
• podporuje analýzu webových aplikácií a mobilných aplikácií bez použitia zdrojového kódu programov;
• poskytuje výsledky analýzy vo forme konkrétnych odporúčaní na odstránenie slabých miest;
• generuje podrobné odporúčania pre nastavenie ochranných nástrojov: SIEM, WAF, FW, NGFW;
• ľahko integrovateľné do bezpečného procesu vývoja softvéru podporou práce s úložiskami zdrojového kódu.

závery

Prítomnosť softvérových chýb, zraniteľností a záložiek v softvéri vyvinutom na mieru, či už ide o webové aplikácie alebo zásuvné moduly pre podnikové aplikácie, predstavuje vážne riziko pre bezpečnosť podnikových údajov. Použitie analyzátorov zdrojového kódu môže výrazne znížiť tieto riziká a kontrolovať kvalitu práce vykonávanej vývojármi kódu bez toho, aby museli míňať ďalší čas a peniaze na služby odborníkov a externých audítorov. Zároveň používanie analyzátorov zdrojového kódu najčastejšie nevyžaduje špeciálne školenie, prideľovanie jednotlivých zamestnancov a neprináša ďalšie nepríjemnosti, ak sa produkt používa iba na akceptáciu a vývojár vykonáva opravu chýb. To všetko robí tento nástroj povinným pri používaní vlastného vývoja.

Pri výbere analyzátora zdrojového kódu treba vychádzať z funkčnosti produktov a kvality ich práce. V prvom rade by ste mali venovať pozornosť schopnosti produktu vykonávať kontroly programovacích jazykov, v ktorých sú implementované kontrolované zdrojové kódy. Ďalším kritériom pri výbere produktu by mala byť kvalita testu, ktorá môže byť určená kompetenciou vývojárskej spoločnosti a počas predvádzacej prevádzky produktu. Ďalším faktorom pre výber produktu môže byť možnosť auditu zhody s požiadavkami národných a medzinárodných noriem, ak si ich implementácia vyžaduje pre podnikové obchodné procesy.

V tejto recenzii je jednoznačným lídrom medzi zahraničnými produktmi z hľadiska podpory programovacieho jazyka a kvality skenovania riešenie HP Fortify Static Code Analyzer. Checkmarx CxSAST je tiež dobrý produkt, ale dokáže analyzovať iba bežné aplikácie a webové aplikácie, v produkte nie je podpora zásuvných modulov pre obchodné aplikácie. Riešenie IBM Security AppScan Source vyzerá v porovnaní s konkurenciou bledo a nelíši sa ani funkčnosťou, ani kvalitou kontrol. Tento produkt však nie je určený pre firemných používateľov a je určený na použitie vo vývojárskych spoločnostiach, kde môže vykazovať vyššiu efektivitu ako konkurencia.

Medzi ruskými produktmi je ťažké vyčleniť jasného lídra, trh predstavujú tri hlavné produkty - InfoWatch Appercut, PT Application Inspector a Solar inCode. Zároveň sa tieto produkty výrazne líšia technológiou a sú určené pre rôzne cieľové skupiny – prvý z nich podporuje viacero platforiem podnikových aplikácií a vyznačuje sa vysokou rýchlosťou vďaka vyhľadávaniu zraniteľností výlučne pomocou metód statickej analýzy. Druhý kombinuje statickú a dynamickú analýzu, ako aj ich kombináciu, čo spolu so skvalitnením skenovania vedie k predĺženiu času na kontrolu zdrojového kódu. Tretia je zameraná na riešenie problémov podnikových používateľov a špecialistov na informačnú bezpečnosť a tiež vám umožňuje kontrolovať aplikácie bez prístupu k zdrojovému kódu.

„Echelónový“ AppChecker ešte nie je porovnateľný s konkurenciou a má malý súbor funkcií, ale vzhľadom na ranú fázu vývoja produktu je celkom možné, že v blízkej budúcnosti môže získať najvyššie priečky v hodnotení zdrojového kódu. analyzátory.

Digital Security ERPScan je vynikajúci produkt na riešenie vysoko špecializovaných úloh analýzy podnikových aplikácií pre platformu SAP. Spoločnosť Digital Security, zameraná len na tento trh, vyvinula produkt, ktorý je jedinečný svojou funkcionalitou, ktorý nielen analyzuje zdrojový kód, ale zohľadňuje aj všetky špecifiká platformy SAP, špecifické konfiguračné nastavenia a prístupové práva pre podnikové aplikácie, a má tiež schopnosť automaticky vytvárať opravy objavených zraniteľností.

anotácia

Statická analýza je spôsob, ako skontrolovať správnosť zdrojového kódu programu. Proces statickej analýzy pozostáva z troch krokov. Najprv sa analyzovaný kód rozdelí na lexémy - konštanty, identifikátory atď. Túto operáciu vykoná lexer. Tokeny sa potom odovzdajú analyzátoru, ktorý na základe týchto tokenov vytvorí strom kódu. Nakoniec sa vykoná statický rozbor zostrojeného stromu. Tento prehľadný článok popisuje tri metódy statickej analýzy: analýzu prechodu stromom kódu, analýzu toku údajov a analýzu toku údajov s výberom cesty.

Úvod

Testovanie je dôležitou súčasťou procesu vývoja aplikácie. Existuje mnoho rôznych typov testovania, vrátane dvoch typov súvisiacich s programovým kódom: statická analýza a dynamická analýza.

Dynamická analýza sa vykonáva na spustiteľnom kóde skompilovaného programu. V tomto prípade sa kontroluje iba správanie špecifické pre používateľa, t.j. iba kód, ktorý sa vykoná počas testu. Dynamický analyzátor dokáže nájsť úniky pamäte, merať výkon programu, získať zásobník hovorov atď.

Statická analýza vám umožňuje skontrolovať zdrojový kód programu pred jeho spustením. Najmä každý kompilátor vykonáva pri kompilácii statickú analýzu. Vo veľkých projektoch v reálnom svete je však často potrebné skontrolovať celý kód, či je v súlade s niektorými dodatočnými požiadavkami. Tieto požiadavky môžu byť veľmi rôznorodé, od pravidiel pomenovania premenných až po prenosnosť (napríklad kód musí bežať bezpečne na platformách x86 a x64). Najbežnejšie požiadavky sú:

• Spoľahlivosť – menej chýb v testovanom programe.
• Udržateľnosť – zrozumiteľnejší kód, ktorý sa ľahko mení a vylepšuje.
• Prenosnosť – flexibilita testovaného programu pri spustení na rôznych platformách.
• Čitateľnosť – skrátenie času potrebného na pochopenie kódu.

Požiadavky možno rozdeliť na pravidlá a usmernenia. Pravidlá sú na rozdiel od odporúčaní záväzné. Pravidlá a odporúčania sú analogické s chybami a upozorneniami vydávanými analyzátormi kódu zabudovanými do štandardných kompilátorov.

Pravidlá a pokyny zase tvoria štandard kódovania. Tento štandard definuje, ako by mal programátor písať programový kód. Normy kódovania používajú organizácie na vývoj softvéru.

Statický analyzátor nájde riadky zdrojového kódu, ktoré sa nezdajú byť v súlade s akceptovaným štandardom kódovania a zobrazí diagnostické správy, aby vývojár mohol pochopiť príčinu problému. Proces statickej analýzy je podobný kompilácii s tým rozdielom, že sa negeneruje ani objekt, ani spustiteľný kód. Tento prehľad poskytuje podrobný popis procesu statickej analýzy.

Proces analýzy

Proces statickej analýzy pozostáva z dvoch hlavných krokov: vytvorenie stromu kódu (nazývaného aj ) a analýza tohto stromu.

Aby mohol analyzátor analyzovať zdrojový kód, musí tomuto kódu najskôr „porozumieť“, t.j. analyzujte ho podľa zloženia a vytvorte štruktúru, ktorá popisuje analyzovaný kód vo vhodnej forme. Tento formulár sa nazýva strom kódu. Ak chcete skontrolovať, či kód zodpovedá štandardu kódovania, musíte vytvoriť takýto strom.

Vo všeobecnom prípade je strom vytvorený iba pre analyzovaný fragment kódu (napríklad pre konkrétnu funkciu). Na vytvorenie stromu sa najskôr spracuje kód a potom .

Lexer je zodpovedný za rozdelenie vstupných údajov do jednotlivých tokenov, ako aj za určenie typu týchto tokenov a ich postupné odovzdanie do syntaktického analyzátora. Lexer číta zdrojový kód riadok po riadku a potom rozdeľuje výsledné riadky na vyhradené slová, identifikátory a konštanty nazývané tokeny. Po prijatí tokenu lexer určí jeho typ.

Zvážte príkladný algoritmus na určenie typu lexémy.

Ak je prvým znakom tokenu číslica, token sa považuje za číslo, ak je tento znak znamienkom mínus, potom je to záporné číslo. Ak je token číslo, môže to byť celé číslo alebo zlomkové číslo. Ak číslo obsahuje písmeno E, ktoré definuje exponenciálny zápis, alebo desatinnú čiarku, číslo sa považuje za zlomok, inak je to celé číslo. Upozorňujeme, že to môže spôsobiť lexikálnu chybu – ak analyzovaný zdrojový kód obsahuje token „4xyz“, lexer to bude považovať za celé číslo 4. Toto vygeneruje chybu syntaxe, ktorú môže syntaktický analyzátor zistiť. Takéto chyby však dokáže odhaliť aj lexer.

Ak token nie je číslo, môže to byť reťazec. Reťazcové konštanty možno rozpoznať pomocou jednoduchých úvodzoviek, dvojitých úvodzoviek alebo iného znaku v závislosti od syntaxe analyzovaného jazyka.

Nakoniec, ak token nie je reťazec, musí to byť identifikátor, vyhradené slovo alebo vyhradený znak. Ak lexéma nezapadá do týchto kategórií, dochádza k lexikálnej chybe. Lexer túto chybu sám nespracuje - iba povie analyzátoru, že bol nájdený token neznámeho typu. Analyzátor túto chybu zvládne.

Analyzátor rozumie gramatike jazyka. Je zodpovedný za detekciu syntaktických chýb a za konverziu programu, ktorý takéto chyby nemá, do dátových štruktúr nazývaných kódové stromy. Tieto štruktúry sa následne privedú do statického analyzátora a spracujú sa ním.

Kým lexer rozumie len syntaxi jazyka, syntaktický analyzátor rozumie aj kontextu. Napríklad deklarujme funkciu v jazyku C:

Int Func()(návrat 0;)

Lexer spracuje tento reťazec a analyzuje ho na tokeny, ako je uvedené v tabuľke 1:

Tabuľka 1 - Tokeny reťazca "int Func()(return 0);".

Reťazec bude rozpoznaný ako 8 platných tokenov a tieto tokeny budú odovzdané syntaktickému analyzátoru.

Tento syntaktický analyzátor sa pozrie na kontext a zistí, že daná množina tokenov je deklarácia funkcie, ktorá nemá žiadne parametre, vracia celé číslo a toto číslo je vždy 0.

Analyzátor to zistí, keď vytvorí strom kódu z tokenov poskytnutých lexerom a analyzuje tento strom. Ak sa tokeny a z nich vytvorený strom považujú za správne, tento strom sa použije v statickej analýze. V opačnom prípade analyzátor vydá chybové hlásenie.

Proces vytvárania stromu kódu sa však neobmedzuje len na jednoduché reprezentovanie lexém ako stromu. Pozrime sa na tento proces podrobnejšie.

Strom kódov

Strom kódu predstavuje podstatu vstupných údajov vo forme stromu, vynechávajúc nepodstatné syntaktické detaily. Takéto stromy sa líšia od konkrétnych syntaktických stromov v tom, že nemajú uzly, ktoré predstavujú interpunkčné znamienka, ako je bodkočiarka, ktorá končí riadok, alebo čiarka, ktorá sa vkladá medzi argumenty funkcie.

Analyzátory používané na vytváranie kódových stromov môžu byť napísané ručne alebo môžu byť generované generátormi syntaktických analyzátorov. Stromy kódov sa zvyčajne vytvárajú zdola nahor.

Pri vývoji stromových uzlov je zvyčajne prvá vec, ktorú musíte urobiť, určiť úroveň modularity. Inými slovami, určuje sa, či všetky jazykové konštrukcie budú reprezentované vrcholmi rovnakého typu, odlíšenými hodnotami. Ako príklad zvážte reprezentáciu binárnych aritmetických operácií. Jednou z možností je použiť rovnaké vrcholy pre všetky binárne operácie, pričom jedným z atribútov bude typ operácie, napríklad „+“. Ďalšou možnosťou je použiť rôzne typy vrcholov pre rôzne operácie. V objektovo orientovanom jazyku to môžu byť triedy ako AddBinary, SubstractBinary, MultipleBinary atď., ktoré dedia z abstraktnej základnej triedy Binary.

Ako príklad uvažujme dva výrazy: 1 + 2 * 3 + 4 * 5 a 1 + 2 * (3 + 4) * 5 (pozri obrázok 1).

Ako vidno z obrázku, pôvodnú formu výrazu možno obnoviť prechádzaním stromu zľava doprava.

Po vygenerovaní a kontrole stromu kódu môže statický analyzátor určiť, či sa zdrojový kód riadi pravidlami a usmerneniami špecifikovanými v štandarde kódovania.

Metódy statickej analýzy

Existuje mnoho rôznych metód, najmä analýza pomocou , analýza toku údajov, analýza toku údajov s výberom cesty atď. Špecifické implementácie týchto metód sa v rôznych syntaktických analyzátoroch líšia. Statické analyzátory pre rôzne programovacie jazyky však môžu používať rovnaký základný kód (infraštruktúru). Tieto rámce obsahujú sadu základných algoritmov, ktoré možno použiť v rôznych analyzátoroch kódu, bez ohľadu na konkrétne úlohy a analyzovaný jazyk. Súbor podporovaných metód a konkrétna implementácia týchto metód bude opäť závisieť od konkrétnej infraštruktúry. Rámec môže napríklad umožniť jednoduché vytvorenie syntaktického analyzátora, ktorý používa prechod stromom kódu, ale nemusí podporovať analýzu toku údajov.

Hoci všetky tri metódy statickej analýzy uvedené vyššie používajú kódový strom vytvorený syntaktickým analyzátorom, tieto metódy sa líšia svojimi úlohami a algoritmami.

Analýza prechodu cez strom, ako už názov napovedá, sa vykonáva prechodom cez strom kódu a vykonaním kontroly, aby sa zistilo, či kód zodpovedá akceptovanému štandardu kódovania, špecifikovanému ako súbor pravidiel a pokynov. Toto je typ analýzy, ktorú robia kompilátory.

Analýza toku údajov môže byť opísaná ako proces zhromažďovania informácií o použití, definícii a závislostiach údajov v analyzovanom programe. Analýza toku údajov využíva graf toku príkazov vygenerovaný zo stromu kódu. Tento graf predstavuje všetky možné cesty pre spustenie daného programu: vrcholy predstavujú „priame“ fragmenty kódu bez akýchkoľvek prechodov a hrany predstavujú možné prenosy kontroly medzi týmito fragmentmi. Keďže sa analýza vykonáva bez spustenia testovaného programu, nie je možné presne určiť výsledok jej vykonania. Inými slovami, nedá sa presne zistiť, na ktorú cestu sa kontrola presunie. Algoritmy analýzy toku údajov preto aproximujú možné správanie, napríklad zohľadnením oboch vetiev príkazu if-then-else alebo vykonaním tela cyklu while s určitou presnosťou. Vždy existuje obmedzenie presnosti, pretože rovnice toku údajov sú napísané pre nejakú množinu premenných a počet týchto premenných musí byť obmedzený, pretože uvažujeme iba o programoch s konečnou množinou príkazov. Preto vždy existuje nejaký horný limit počtu neznámych, ktorý určuje hranicu presnosti. Z pohľadu grafu toku inštrukcií statická analýza považuje za platné všetky možné cesty na vykonanie programu. Kvôli tomuto predpokladu môže analýza toku údajov poskytnúť len približné riešenia pre obmedzený súbor problémov.

Algoritmus analýzy toku údajov opísaný vyššie nerozlišuje medzi cestami, pretože všetky možné cesty, bez ohľadu na to, či sú skutočné alebo nie, či sa budú vykonávať často alebo zriedkavo, stále vedú k riešeniu. V praxi sa však naplní len malá časť potenciálnych ciest. Navyše, najčastejšie vykonávaný kód má tendenciu byť ešte menšou podmnožinou všetkých možných ciest. Je logické skrátiť analyzovaný graf toku príkazov a tým znížiť množstvo výpočtov analýzou len podmnožiny možných ciest. Analýza výberu cesty sa vykonáva na redukovanom grafe toku pokynov, ktorý neobsahuje žiadne nemožné cesty a cesty, ktoré neobsahujú "nebezpečný" kód. Kritériá výberu ciest sú v rôznych analyzátoroch rôzne. Analyzátor môže napríklad brať do úvahy iba cesty obsahujúce deklarácie dynamického poľa, pričom takéto deklarácie považuje za „nebezpečné“ podľa nastavení analyzátora.

Záver

Počet metód statickej analýzy a samotných analyzátorov z roka na rok rastie, čo znamená, že záujem o analyzátory statického kódu rastie. Dôvodom záujmu je skutočnosť, že vyvíjaný softvér je čoraz zložitejší, a preto je nemožné kontrolovať kód manuálne.

V tomto článku bol uvedený stručný popis procesu statickej analýzy a rôznych metód na vykonanie takejto analýzy.

Bibliografický zoznam

• Dirk Giesen Filozofia a praktická implementácia nástrojov statického analyzátora. - Elektronické údaje. -Dirk Giesen, policajt. 1998.
• Základy kompilátora Jamesa Alana Farrella. - Elektronické údaje. -James Alan Farrell, policajt z roku 1995. -Režim prístupu: http://www.cs.man.ac.uk/~pjj/farrell/compmain.html
• Joel Jones Idiomy implementácie abstraktných syntaxových stromov. -Zborník z 10. konferencie o vzorových jazykoch programov 2003, policajt 2003.
• Ciera Nicole Christopher Hodnotiace rámce statickej analýzy .- Ciera Nicole, policajt. 2006.
• Leon Moonen Všeobecná architektúra pre analýzu toku údajov na podporu reverzného inžinierstva. - Zborník z 2. medzinárodného workshopu o teórii a praxi algebraických špecifikácií, spol. 1997.

Pomocou statickej analýzy môžete nájsť mnoho rôznych defektov a slabín v zdrojovom kóde ešte predtým, ako je kód pripravený na spustenie. Na druhej strane, runtime analýza alebo runtime analýza prebieha na spustenom softvéri a zisťuje problémy, keď nastanú, zvyčajne pomocou sofistikovaných nástrojov. Niekto by mohol namietať, že jedna forma analýzy predchádza druhej, ale vývojári môžu kombinovať obe metódy, aby urýchlili vývojové a testovacie procesy, ako aj zlepšili kvalitu dodávaného produktu.

Tento článok sa najskôr zaoberá metódou statickej analýzy. Môže sa použiť na predchádzanie problémom skôr, ako preniknú do hlavného kódu, a zabezpečiť, aby nový kód vyhovoval štandardu. Pomocou rôznych analytických techník, ako je abstraktný syntaktický strom (AST) a analýza cesty kódu, môžu nástroje statickej analýzy odhaliť skryté zraniteľnosti, logické chyby, implementačné chyby a ďalšie problémy. To sa môže stať tak vo fáze vývoja na každej pracovnej stanici, ako aj počas montáže systému. Článok potom skúma metódu dynamickej analýzy, ktorú možno použiť vo fázach vývoja modulov a systémovej integrácie na identifikáciu problémov, ktoré statická analýza nevynechala. Dynamická analýza odhaľuje nielen chyby súvisiace s ukazovateľmi a iné nesprávnosti, ale je tiež možné optimalizovať využitie cyklov CPU, RAM, flash pamäte a iných zdrojov.

Článok tiež pojednáva o možnostiach kombinovania statickej a dynamickej analýzy, ktorá pomôže zabrániť regresii do skorších štádií vývoja, keď produkt dozrieva. Tento prístup založený na dvoch metódach pomáha vyhnúť sa väčšine problémov na začiatku vývoja, keď je najjednoduchšie a najlacnejšie opraviť.

Spojenie toho najlepšieho z oboch svetov

Nástroje na statickú analýzu nájdu chyby na začiatku projektu, zvyčajne ešte pred vytvorením spustiteľného súboru. Táto skorá detekcia je užitočná najmä pre veľké projekty vstavaných systémov, kde vývojári nemôžu používať nástroje dynamickej analýzy, kým softvér nie je dostatočne dokončený na to, aby mohol bežať na cieľovom systéme.

Vo fáze statickej analýzy sa detegujú a popisujú oblasti zdrojového kódu so slabými miestami, vrátane skrytých zraniteľností, logických chýb, implementačných chýb, nesprávnosti paralelných operácií, zriedkavo sa vyskytujúcich okrajových podmienok a mnohých ďalších problémov. Napríklad nástroje statickej analýzy Klocwork Insight vykonávajú hĺbkovú analýzu zdrojového kódu na syntaktickej a sémantickej úrovni. Tieto nástroje tiež vykonávajú sofistikovanú inter-procedurálnu analýzu riadenia a dátových tokov a využívajú pokročilé techniky návnady, vyhodnocujú hodnoty, ktoré premenné nadobudnú, a modelujú potenciálne správanie programu za behu.

Vývojári môžu použiť nástroje statickej analýzy kedykoľvek počas vývojovej fázy, aj keď boli napísané iba fragmenty projektu. Čím je však kód úplnejší, tým lepšie. Pomocou statickej analýzy je možné zobraziť všetky potenciálne cesty vykonávania kódu – to sa pri bežnom testovaní stáva zriedka, pokiaľ projekt nevyžaduje 100% pokrytie kódu. Statická analýza môže napríklad odhaliť chyby programovania spojené s okrajovými podmienkami alebo chyby dráhy, ktoré neboli testované v čase návrhu.

Keďže statická analýza sa pokúša predpovedať správanie programu na základe modelu zdrojového kódu, niekedy sa nájde „chyba“, ktorá v skutočnosti neexistuje – ide o takzvaný „falošne pozitívny“ (falošne pozitívny). Mnoho moderných nástrojov na statickú analýzu implementuje vylepšené techniky na predchádzanie tomuto problému a na vykonávanie mimoriadne presnej analýzy.

Statická analýza: argumenty "pre"

Statická analýza: Argumenty proti

Používa sa na začiatku životného cyklu softvéru, predtým, ako je kód pripravený na spustenie a pred začiatkom testovania. Je možné analyzovať existujúce kódové základne, ktoré už boli testované. Nástroje je možné integrovať do vývojového prostredia ako súčasť komponentu používaného v „nočných zostavách“ a ako súčasť sady nástrojov vývojárskeho pracovného stola. Nízke náklady: nie je potrebné vytvárať testovacie programy alebo stub; vývojári môžu vykonávať svoje vlastné analýzy.

Môžu sa objaviť softvérové ​​chyby a zraniteľné miesta, ktoré nemusia nevyhnutne viesť k zlyhaniu programu alebo ovplyvňovať správanie programu počas jeho skutočného vykonávania. Nenulová pravdepodobnosť „falošne pozitívneho výsledku“.

stôl 1- Argumenty „za“ a „proti“ statickej analýze.

Nástroje dynamickej analýzy zisťujú chyby programovania v kóde, ktorý sa vykonáva. Zároveň má vývojár možnosť sledovať či diagnostikovať správanie aplikácie počas jej vykonávania, v ideálnom prípade priamo v cieľovom prostredí.

V mnohých prípadoch nástroj dynamickej analýzy upraví zdrojový alebo binárny kód aplikácie na inštaláciu pascí alebo hákov na inštrumentálne merania. Tieto háčiky možno použiť na zisťovanie chýb programu za behu, analýzu využitia pamäte, pokrytia kódom a kontrolu ďalších podmienok. Nástroje dynamickej analýzy dokážu generovať presné informácie o stave zásobníka, čo umožňuje debuggerom nájsť príčinu chyby. Preto, keď nástroje dynamickej analýzy nájdu chybu, s najväčšou pravdepodobnosťou ide o skutočnú chybu, ktorú môže programátor rýchlo identifikovať a opraviť. Je potrebné poznamenať, že na vytvorenie chybovej situácie v čase spustenia musia existovať presne nevyhnutné podmienky, za ktorých dôjde k chybe programu. V súlade s tým musia vývojári vytvoriť nejaký testovací prípad na implementáciu konkrétneho scenára.

Dynamická analýza: argumenty „pre“

Dynamická analýza: Argumenty proti

Zriedkavo sa vyskytujú „falošné pozitíva“ – vysoká produktivita pri hľadaní chýb Na sledovanie príčiny chyby možno vygenerovať úplný zásobník a sledovanie za behu. Chyby sa zachytávajú v kontexte spusteného systému, a to ako v reálnom svete, tak aj v režime simulácie.

Dochádza k zásahu do správania systému v reálnom čase; miera zásahu závisí od počtu použitých vložiek nástroja. Nie vždy to spôsobuje problémy, ale pri práci s časovo kritickým kódom je potrebné na to pamätať. Úplnosť analýzy chýb závisí od stupňa pokrytia kódom. Musí sa teda prejsť kódová cesta obsahujúca chybu a v testovacom prípade musia byť vytvorené potrebné podmienky na vytvorenie chybovej situácie.

tabuľka 2- Argumenty „za“ a „proti“ dynamickej analýze.

Včasná detekcia chýb na zníženie nákladov na vývoj

Čím skôr sa softvérová chyba odhalí, tým rýchlejšie a lacnejšie ju možno opraviť. Preto nástroje statickej a dynamickej analýzy majú skutočnú hodnotu pri hľadaní chýb na začiatku životného cyklu softvéru. Rôzne štúdie priemyselných produktov ukazujú, že oprava problému vo fáze testovania systému (na potvrdenie kvality jeho práce, QA) alebo po dodaní systému je o niekoľko rádov drahšia ako oprava rovnakých problémov na štádiu vývoja softvéru. Mnoho organizácií má svoje vlastné odhady nákladov na opravu defektov. Na obr. Obrázok 1 poskytuje údaje o diskutovanom probléme, prevzaté z často citovanej knihy od Capersa Jonesa. "Meranie aplikovaného softvéru".

Ryža. jeden- Ako projekt napreduje, náklady na opravu softvérových chýb sa môžu exponenciálne zvyšovať. Nástroje statickej a dynamickej analýzy pomáhajú predchádzať týmto nákladom tým, že zisťujú chyby na začiatku životného cyklu softvéru.

Statická analýza

Statická analýza je v praxi vývoja softvéru takmer tak dlho, ako existuje samotný vývoj softvéru. Vo svojej pôvodnej podobe sa analýza zredukovala na sledovanie dodržiavania štandardov štýlu programovania (lint). Vývojári ho používali priamo na svojom pracovisku. Pokiaľ ide o zisťovanie chýb, rané nástroje statickej analýzy sa zamerali na to, čo bolo na povrchu: štýl programovania a bežné syntaktické chyby. Napríklad aj tie najjednoduchšie nástroje na statickú analýzu dokážu zistiť chybu, ako je táto:

int foo(int x, int* ptr) ( if(x & 1); ( *ptr = x; return; ) ... )

Tu vedie chybné použitie bodkočiarky navyše k potenciálne katastrofálnym výsledkom: ukazovateľ vstupného parametra funkcie je predefinovaný za neočakávaných podmienok. Ukazovateľ je vždy predefinovaný, bez ohľadu na kontrolovanú podmienku.

Skoré analytické nástroje sa zameriavali hlavne na syntaktické chyby. Takže aj keď sa dali nájsť vážne chyby, väčšina zistených problémov bola relatívne triviálna. Okrem toho bol pre nástroje poskytnutý dostatočne malý kontext kódu, aby bolo možné očakávať presné výsledky. Bolo to preto, že práca bola vykonaná počas typického vývojového cyklu kompilácie/prepojenia a to, čo vývojár robil, bol len malý kúsok kódu vo veľkom softvérovom systéme. Takýto nedostatok viedol k tomu, že analytické nástroje boli založené na odhadoch a hypotézach týkajúcich sa toho, čo by sa mohlo stať mimo vývojárskeho „sandboxu“. A to zase viedlo k vytvoreniu zvýšeného objemu správ s „falošnými poplachmi“.

Nasledujúce generácie nástrojov na statickú analýzu riešili tieto nedostatky a rozšírili ich dosah za hranice syntaktickej a sémantickej analýzy. V nových nástrojoch bola postavená rozšírená reprezentácia alebo model generovaného kódu (niečo podobné ako vo fáze kompilácie) a následne boli modelované všetky možné spôsoby vykonávania kódu v súlade s modelom. Ďalej boli na tieto cesty mapované logické toky so súčasnou kontrolou toho, ako a kde sa vytvárajú, používajú a ničia dátové objekty. V procese analýzy programových modulov je možné prepojiť procedúry analýzy interprocedurálneho riadenia a dátového toku. Minimalizuje tiež „falošné pozitíva“ pomocou nových prístupov na odrezanie falošných ciest, vyhodnotenie hodnôt, ktoré môžu premenné nadobudnúť, a modelovanie potenciálneho správania pri behu v reálnom čase. Na generovanie údajov tejto úrovne v nástrojoch statickej analýzy je potrebné analyzovať celú kódovú základňu projektu, vykonať integrálne rozloženie systému a nielen pracovať s výsledkami získanými v „sandboxe“ na pracovnej ploche vývojára.

Na vykonanie týchto sofistikovaných foriem analýzy sa nástroje statickej analýzy zaoberajú dvoma hlavnými typmi kontroly kódu:

• Kontrola abstraktného stromu syntaxe- na kontrolu základnej syntaxe a štruktúry kódu.
• Analýza cesty kódu- vykonať úplnejšiu analýzu, ktorá závisí od pochopenia stavu objektov programových údajov v konkrétnom bode cesty vykonávania kódu.

Abstraktné syntaktické stromy

Abstraktný strom syntaxe je jednoducho reprezentácia stromovej štruktúry zdrojového kódu, ako môže byť vygenerovaná v krokoch pred kompilátorom. Strom obsahuje podrobnú dekompozíciu štruktúry kódu jedna k jednej, čo umožňuje nástrojom vykonávať jednoduché vyhľadávanie bodov anomálnej syntaxe.

Je veľmi jednoduché vytvoriť kontrolu, ktorá kontroluje štandardy týkajúce sa konvencií pomenovania a obmedzení volania funkcií, ako je kontrola nebezpečných knižníc. Účelom vykonávania kontrol AST je zvyčajne vyvodiť nejaký druh záveru zo samotného kódu bez použitia znalosti toho, ako sa kód správa počas vykonávania.

Mnohé nástroje ponúkajú kontroly založené na AST pre rôzne jazyky, vrátane nástrojov s otvoreným zdrojovým kódom, ako je PMD pre Java. Niektoré nástroje používajú gramatiku X-path alebo gramatiku odvodenú od X-path na definovanie podmienok, ktoré sú zaujímavé pre riadenie programov. Ďalšie nástroje poskytujú pokročilé mechanizmy umožňujúce používateľom vytvárať si vlastné kontroléry založené na AST. Tento typ kontroly je relatívne jednoduchý na vykonanie a mnohé organizácie vytvárajú nové kontrolné programy tohto typu na overenie súladu s normami podnikového kódovania alebo osvedčenými postupmi odporúčanými v odvetví.

Analýza cesty kódu

Pozrime sa na zložitejší príklad. Teraz namiesto hľadania prípadov porušenia štýlu programovania chceme skontrolovať, či pokus o dereferenciu ukazovateľa bude fungovať správne alebo či zlyhá:

If(x & 1) ptr = NULL; *ptr = 1;

Povrchné preskúmanie fragmentu vedie k jasnému záveru, že premenná ptr môže byť NULL, ak je premenná x nepárna, a táto podmienka, keď je dereferencovaná, nevyhnutne povedie k nulovej stránke. Pri vytváraní testovacieho programu na základe AST je však nájdenie takejto programovej chyby veľmi problematické. Zvážte strom AST (zjednodušený kvôli prehľadnosti), ktorý by sa vygeneroval pre vyššie uvedený útržok kódu:

Blok príkazu If-príkaz Kontrolný-Výraz Binárny-operátor & x 1 True-Branch Výraz-príkaz Priradenie-operátor = ptr 0 Výraz-príkaz Priradenie-operátor = Dereference-ukazovateľ - ptr 1 V takýchto prípadoch nie je potrebné žiadne vyhľadávanie v strome ani jednoduchý výpis uzly nedokážu v primerane zovšeobecnenej forme zistiť pokus (aspoň niekedy neplatný) dereferencovať ukazovateľ ptr. Preto nástroj na analýzu nemôže jednoducho prehľadávať model syntaxe. Je tiež potrebné analyzovať životný cyklus dátových objektov tak, ako sa objavujú a používajú v rámci riadiacej logiky počas vykonávania.

Analýza cesty kódu sleduje objekty v rámci ciest vykonávania, takže validátori môžu určiť, či sa údaje používajú presne a správne. Použitie analýzy cesty kódu rozširuje okruh otázok, ktoré je možné zodpovedať v priebehu statickej analýzy. Namiesto jednoduchej analýzy správnosti kódu programu sa analýza cesty kódu pokúša určiť „zámery“ kódu a skontrolovať, či je kód napísaný v súlade s týmito zámermi. To môže poskytnúť odpovede na nasledujúce otázky:

• Bol novovytvorený objekt uvoľnený predtým, ako boli všetky odkazy naň odstránené z rozsahu?
• Bol skontrolovaný povolený rozsah hodnôt pre nejaký dátový objekt pred odovzdaním objektu funkcii OS?
• Kontroloval sa reťazec znakov na prítomnosť špeciálnych znakov pred odoslaním reťazca ako dotazu SQL?
• Spôsobí operácia kopírovania pretečenie vyrovnávacej pamäte?
• Je bezpečné volať túto funkciu v tejto chvíli?

Analýzou ciest vykonávania kódu týmto spôsobom, dopredu od spustenia udalosti k cieľovému skriptu a späť od spustenia udalosti po inicializáciu požadovaných údajov, bude nástroj schopný odpovedať na položené otázky a vydať chybové hlásenie v prípade, že cieľový skript alebo sa inicializácie vykonajú alebo nevykonajú podľa očakávania.

Implementácia takejto schopnosti je nevyhnutná na vykonávanie pokročilej analýzy zdrojového kódu. Preto by vývojári mali hľadať nástroje, ktoré využívajú pokročilú analýzu cesty kódu na zisťovanie únikov pamäte, chybných dereferencií ukazovateľov, nebezpečných alebo chybných prenosov údajov, narušenia súbežnosti a mnohých ďalších problematických stavov.

Postupnosť akcií pri vykonávaní statickej analýzy

Statická analýza dokáže odhaliť problémy v dvoch kľúčových bodoch procesu vývoja: počas písania programu na pracovisku a vo fáze prepojenia systému. Ako už bolo spomenuté, súčasná generácia nástrojov funguje najmä vo fáze prepojenia systému, kedy je možné analyzovať tok kódu celého systému, čo vedie k veľmi presným diagnostickým výsledkom.

Klocwork Insight, jedinečný svojho druhu, vám umožňuje analyzovať kód vytvorený na pracovisku konkrétneho vývojára, pričom sa vyhnete problémom spojeným s nepresnou diagnostikou, ktorá je pre nástroje tohto druhu zvyčajne charakteristická. Klocwork poskytuje Connected Desktop Analysis, ktorý analyzuje kód vývojára s pochopením všetkých systémových závislostí. Výsledkom je lokálna analýza, ktorá je rovnako presná a výkonná ako centralizovaná systémová analýza, ale to všetko ešte pred úplným zostavením kódu.

Z hľadiska sekvenovania analýzy táto schopnosť umožňuje vývojárovi vykonávať presnú a vysokokvalitnú statickú analýzu veľmi skoro v životnom cykle vývoja. Nástroj Klockwork Insight hlási akékoľvek problémy do integrovaného prostredia vývojára (IDE) alebo príkazového riadku, keď vývojár píše kód a pravidelne kompiluje/prepája. K vydaniu takýchto správ a správ dochádza pred vykonaním dynamickej analýzy a predtým, ako všetci vývojári spoja svoje kódy.

Ryža. 2- Postupnosť vykonávania statickej analýzy.

Technológia dynamickej analýzy

Na detekciu programových chýb v nástrojoch dynamickej analýzy sa malé fragmenty kódu často vkladajú buď priamo do zdrojového kódu programu (vloženie do zdrojového kódu) alebo do spustiteľného kódu (vloženie do objektového kódu). V takýchto segmentoch kódu sa vykoná „sanitárna kontrola“ stavu programu a vydá sa chybové hlásenie, ak sa zistí, že niečo je nesprávne alebo nefunkčné. V takýchto nástrojoch môžu byť zahrnuté ďalšie funkcie, ako je sledovanie alokácie pamäte a jej využitia v priebehu času.

Technológia dynamickej analýzy zahŕňa:

• Umiestnenie vložiek do zdrojového kódu v štádiu predspracovania– do zdrojového kódu aplikácie sa pred kompiláciou vloží špeciálny fragment kódu, aby sa zistili chyby. Tento prístup nevyžaduje podrobné znalosti runtime prostredia, a preto je táto metóda populárna medzi nástrojmi na testovanie a analýzu vstavaných systémov. Príkladom takéhoto nástroja je produkt IBM Rational Test RealTime.
• Umiestňovanie vložiek do objektového kódu– pre takýto nástroj dynamickej analýzy musíte mať dostatočné znalosti o prostredí runtime, aby ste mohli vkladať kód priamo do spustiteľných súborov a knižníc. Pri tomto prístupe nepotrebujete pristupovať k zdrojovému kódu programu ani znova prepájať aplikáciu. Príkladom takéhoto nástroja je IBM Rational Purify.
• Vkladanie kódu v čase kompilácie– vývojár používa špeciálne kľúče (možnosti) kompilátora na začlenenie do zdrojového kódu. Využíva sa schopnosť kompilátora odhaliť chyby. Napríklad kompilátor GNU C/C++ 4.x používa technológiu Mudflap na detekciu problémov s operáciami ukazovateľov.
• Špecializované runtime knižnice– na odhalenie chýb v odovzdávaných parametroch používa vývojár ladiace verzie systémových knižníc. Funkcie ako strcpy() sú neslávne známe kvôli možnosti nulových alebo chybných ukazovateľov za behu. Pri použití ladiacich verzií knižníc sa takéto „zlé“ parametre zisťujú. Táto technológia nevyžaduje opätovné prepojenie aplikácie a ovplyvňuje výkon v menšej miere ako plné využitie insertov v zdrojovom/objektovom kóde. Táto technológia sa používa v nástroji analýzy RAM v QNX® Momentics® IDE.

V tomto článku sa pozrieme na technológie používané vo vývojárskych nástrojoch QNX Momentics s osobitným zameraním na GCC Mudflap a špecializované runtime knižnice.

GNU C/C++ Mudflap: injekcia v čase kompilácie do zdrojového kódu

Nástroj Mudflap, prítomný vo verzii 4.x kompilátora GNU C/C++ (GCC), používa vkladanie do zdrojového kódu v čase kompilácie. Zároveň sa počas vykonávania kontrolujú štruktúry, ktoré potenciálne nesú možnosť chýb. Mudflap sa zameriava na operácie ukazovateľov, pretože sú zdrojom mnohých chýb pri spustení programov napísaných v C a C++.

So zahrnutím Mudflap má kompilátor GCC ďalší priechod, keď vkladá overovací kód pre operácie ukazovateľa. Vložený kód zvyčajne vykonáva overenie hodnôt odovzdaných ukazovateľov. Nesprávne hodnoty ukazovateľa spôsobia, že GCC vyšle správy do štandardného chybového výstupného zariadenia konzoly (stderr). Mudflap's pointer checker nekontroluje len ukazovatele na nulu: jeho databáza ukladá adresy pamäte pre skutočné objekty a vlastnosti objektov, ako je umiestnenie v zdrojovom kóde, dátum/čas, spätné sledovanie zásobníka, keď je pamäť alokovaná a uvoľnená. Takáto databáza vám umožňuje rýchlo získať potrebné údaje pri analýze operácií prístupu do pamäte v zdrojovom kóde programu.

Funkcie knižnice ako strcpy() nekontrolujú odovzdané parametre. Takéto funkcie netestuje ani Mudflap. V Mudflap je však možné vytvoriť obal symbolov pre staticky prepojené knižnice alebo vložku pre dynamické knižnice. Touto technológiou sa medzi aplikáciou a knižnicou vytvorí ďalšia vrstva, ktorá umožňuje validovať parametre a vydať správu o prejave odchýlok. Nástroj Mudflap používa heuristický algoritmus založený na znalosti hraníc pamäte používanej aplikáciou (hromada, zásobník, kód a dátové segmenty atď.) na určenie, či sú hodnoty vrátených ukazovateľov platné.

Pomocou možností príkazového riadka kompilátora GCC môže vývojár povoliť funkcie Mudflap na vkladanie fragmentov kódu a kontrolu správania, ako je napríklad správa porušení (medzí, hodnôt), vykonávanie dodatočných kontrol a nastavení, umožnenie heuristiky a autodiagnostiky. Napríklad prepínač -fmudflap nastavuje predvolenú konfiguráciu Mudflap. Správy kompilátora o porušeniach zistených Mudflap sú výstupom na výstupnú konzolu (stderr) alebo na príkazový riadok. Podrobný výstup poskytuje informácie o porušení a príslušných premenných a funkciách, ako aj o umiestnení kódu. Tieto informácie možno automaticky importovať do IDE, kde sa vykreslia a sledujú zásobník. Pomocou týchto údajov môže vývojár rýchlo prejsť na príslušné miesto v zdrojovom kóde programu.

Na obr. Obrázok 3 zobrazuje príklad toho, ako sa chyba prezentuje v IDE, spolu so zodpovedajúcimi informáciami o spätnom sledovaní. Backtrace funguje ako prepojenie na zdrojový kód, čo umožňuje vývojárovi rýchlo diagnostikovať príčinu problému.

Použitie Mudflap môže predĺžiť čas prepojenia a môže znížiť výkon v čase spustenia. Údaje uvedené v článku “Mudflap: Kontrola použitia ukazovateľa pre C/C++” naznačujú, že ak je Mudflap povolený, čas prepojenia sa zvýši 3 až 5-krát a program začne bežať pomalšie o faktor 1,25 až 5. Je to jasné že vývojári časovo kritických aplikácií by mali túto funkciu používať opatrne. Napriek tomu je Mudflap výkonný nástroj na identifikáciu chybových a potenciálne fatálnych konštrukcií kódu. QNX plánuje použiť nástroj Mudflap v budúcich verziách svojich nástrojov dynamickej analýzy.

Ryža. 3- Použitie informácií o spätnom sledovaní zobrazených v QNX Momentics IDE na nájdenie zdrojového kódu, ktorý spôsobil chybu.

Ladenie verzií runtime knižníc

Spolu s použitím špeciálnych ladiacich vložiek v runtime knižniciach, ktoré vedú k značným dodatočným nákladom na pamäť a čas vo fázach prepojenia a runtime, môžu vývojári použiť predinštrumentované runtime knižnice. V takýchto knižniciach sa okolo volaní funkcií pridáva nejaký kód, ktorého účelom je skontrolovať platnosť vstupných parametrov. Zoberme si napríklad starého priateľa, funkciu kopírovania reťazca:

strcpy(a,b);

Vyžaduje dva parametre, pričom oba sú ukazovateľmi na typ char: jeden pre pôvodný reťazec ( b) a ďalšie pre výsledný reťazec ( a). Napriek tejto jednoduchosti môže byť táto funkcia zdrojom mnohých chýb:

• ak hodnota ukazovateľa a je nula alebo je neplatná, potom kopírovanie do tohto cieľa bude mať za následok chybu odmietnutia prístupu do pamäte;
• ak hodnota ukazovateľa b je nula alebo je neplatná, potom čítanie informácií z tejto adresy bude mať za následok chybu odmietnutia prístupu do pamäte;
• ak na konci riadku b ak chýba ukončovací znak "0", do cieľového reťazca sa skopíruje viac znakov, ako sa očakávalo;
• ak je veľkosť reťazca b viac ako je pamäť pridelená pre reťazec a, potom sa na zadanú adresu zapíše viac bajtov, ako sa očakáva (typický scenár pretečenia vyrovnávacej pamäte).

Ladiaca verzia knižnice kontroluje hodnoty parametrov ‘ a' a ' b'. Kontroluje sa aj dĺžka reťazcov, aby sa zabezpečila ich kompatibilita. Ak sa nájde neplatný parameter, vydá sa príslušné hlásenie alarmu. V prostredí QNX Momentics sa tieto chybové hlásenia importujú z cieľového systému a zobrazia sa na obrazovke. Prostredie QNX Momentics tiež využíva technológiu sledovania alokácie pamäte a rozdelenia, ktorá umožňuje hĺbkovú analýzu využitia pamäte RAM.

Ladiaca verzia knižnice bude fungovať s akoukoľvek aplikáciou, ktorá využíva jej funkcie; nemusíte v kóde robiť žiadne ďalšie zmeny. Okrem toho môže vývojár pridať knižnicu počas spúšťania aplikácie. Knižnica potom nahradí zodpovedajúce časti úplnej štandardnej knižnice, čím sa eliminuje potreba používať ladiacu verziu úplnej knižnice. V QNX Momentics IDE môže vývojár pridať takúto knižnicu pri spustení programu ako súčasť bežnej interaktívnej relácie ladenia. Na obr. Obrázok 4 ukazuje príklad toho, ako QNX Momentics zisťuje a hlási chyby pamäte.

Ladiace verzie knižníc poskytujú osvedčenú „neagresívnu“ metódu zisťovania chýb pri volaní funkcií knižnice. Táto technika je ideálna pre analýzu RAM a ďalšie analytické metódy, ktoré závisia od spárovaných párov volaní, ako sú malloc() a free(). Inými slovami, táto technológia dokáže detegovať iba chyby pri spustení kódu s volaniami knižnice. Nedeteguje veľa typických chýb, ako sú napríklad odchýlky inline ukazovateľa alebo nesprávna aritmetika ukazovateľa. Pri ladení sa zvyčajne monitoruje iba podmnožina systémových volaní. Viac sa o tom dozviete v článku.

Ryža. 4- Analýza RAM sa vykonáva umiestnením pascí do oblasti volaní API súvisiacich s prístupom do pamäte.

Postupnosť akcií v dynamickej analýze

Stručne povedané, dynamická analýza zahŕňa zachytenie udalostí porušenia alebo iných významných udalostí vo vstavanom cieľovom systéme, import týchto informácií do vývojového prostredia a následné použitie vizualizačných nástrojov na rýchlu identifikáciu chybných častí kódu.

Ako je znázornené na obr. 5, dynamická analýza umožňuje nielen odhaliť chyby, ale tiež pomáha upozorniť vývojára na podrobnosti o spotrebe pamäte, cyklov CPU, miesta na disku a ďalších zdrojoch. Proces analýzy pozostáva z niekoľkých krokov a dobrý nástroj dynamickej analýzy poskytuje silnú podporu pre každý krok:

1. Pozorovanie- V prvom rade zachytáva runtime chyby, deteguje úniky pamäte a zobrazuje všetky výsledky v IDE.
2. Úprava- potom má vývojár možnosť vysledovať každú chybu späť k problematickému zdrojovému riadku. Pri dobrej integrácii do IDE sa každá chyba zobrazí na obrazovke. Vývojár jednoducho musí kliknúť na riadok chyby a fragment zdrojového kódu sa otvorí s riadkom, ktorý preruší prácu. V mnohých prípadoch môže vývojár rýchlo vyriešiť problém pomocou dostupného sledovania zásobníka a ďalších nástrojov zdrojového kódu v IDE (prehliadače volania funkcií, sledovače volaní atď.).
3. Profilovanie– Opravením zistených chýb a únikov pamäte môže vývojár analyzovať využitie zdrojov v priebehu času, vrátane špičiek, priemerov zaťaženia a prekročenia zdrojov. V ideálnom prípade vám analytický nástroj poskytne vizuálnu reprezentáciu dlhodobého využívania zdrojov, čo vám umožní okamžite identifikovať špičky v prideľovaní pamäte a iné anomálie.
4. Optimalizácia– pomocou informácií z fázy profilovania môže teraz vývojár vykonať „jemnú“ analýzu využívania zdrojov programu. Okrem iného môžu takéto optimalizácie minimalizovať špičky zdrojov a réžiu zdrojov, vrátane využitia RAM a CPU.

Ryža. 5- Typická postupnosť akcií pre dynamickú analýzu

Kombinácia postupnosti akcií rôznych typov analýz vo vývojovom prostredí

Každý z nástrojov statickej a dynamickej analýzy má svoje silné stránky. Vývojové tímy by preto mali používať tieto nástroje v tandeme. Napríklad nástroje na statickú analýzu dokážu odhaliť chyby, ktoré nástroje dynamickej analýzy vynechali, pretože nástroje dynamickej analýzy zachytia chybu iba vtedy, ak sa počas testovania vykoná chybný fragment kódu. Na druhej strane nástroje dynamickej analýzy zisťujú softvérové ​​chyby v konečnom spustenom procese. Sotva je potrebné diskutovať o chybe, ak už bolo objavené použitie nulového ukazovateľa.

V ideálnom prípade bude vývojár používať oba analytické nástroje pri svojej každodennej práci. Úloha je značne uľahčená, ak sú nástroje dobre integrované do vývojového prostredia na pracovisku.

Tu je príklad spoločného použitia dvoch typov nástrojov:

1. Na začiatku pracovného dňa si vývojár pozrie správu o výsledkoch nočnej stavby. Táto správa obsahuje samotné chyby zostavy aj výsledky statickej analýzy vykonanej počas zostavovania.
2. V správe o statickej analýze sú uvedené zistené chyby spolu s informáciami, ktoré vám ich pomôžu opraviť, vrátane odkazov na zdrojový kód. Pomocou IDE môže vývojár označiť každú situáciu buď ako skutočnú chybu, alebo ako „falošne pozitívnu“. Potom sa opravia skutočné chyby.
3. Vývojár uloží zmeny vykonané lokálne v rámci IDE spolu so všetkými novými útržkami kódu. Vývojár nepotvrdí tieto zmeny späť do systému kontroly zdroja, kým zmeny nebudú skontrolované a otestované.
4. Vývojár analyzuje a opravuje nový kód pomocou nástroja statickej analýzy na miestnom pracovisku. Aby sa zabezpečila kvalitná detekcia chýb a absencia „falošných poplachov“, analýza využíva rozšírené informácie na systémovej úrovni. Tieto informácie sú prevzaté z nočného procesu zostavovania/analýzy.
5. Po analýze a „vyčistení“ akéhokoľvek nového kódu vývojár zostaví kód do lokálneho testovacieho obrazu alebo spustiteľného súboru.
6. Pomocou nástrojov dynamickej analýzy vývojár spúšťa testy na overenie vykonaných zmien.
7. S pomocou IDE môže vývojár rýchlo identifikovať a opraviť chyby, ktoré sú nahlásené prostredníctvom nástrojov dynamickej analýzy. Kód sa považuje za konečný a pripravený na použitie, keď prešiel statickou analýzou, testovaním jednotiek a dynamickou analýzou.
8. Vývojár odošle zmeny do systému riadenia zdroja; potom sa upravený kód zúčastňuje následného procesu nočného prepojenia.

Tento pracovný postup je podobný ako pri stredných až veľkých projektoch, ktoré už využívajú nočné zostavy, kontrolu zdrojového kódu a vlastníctvo kódu. Keďže nástroje sú integrované do IDE, vývojári môžu rýchlo vykonávať statickú a dynamickú analýzu bez toho, aby sa odchýlili od typického pracovného postupu. Vďaka tomu sa kvalita kódu výrazne zvyšuje už vo fáze tvorby zdrojového kódu.

Úloha architektúry RTOS

V rámci diskusie o nástrojoch statickej a dynamickej analýzy sa môže zdať zmienka o architektúre RTOS nevhodná. Ukazuje sa však, že dobre zostavený RTOS môže výrazne uľahčiť detekciu, lokalizáciu a riešenie mnohých softvérových chýb.

Napríklad v mikrokerneli RTOS, ako je QNX Neutrino, sú všetky aplikácie, ovládače zariadení, súborové systémy a sieťové zásobníky umiestnené mimo jadra v samostatných adresných priestoroch. V dôsledku toho sú všetky izolované od jadra a od seba navzájom. Tento prístup poskytuje najvyšší stupeň lokalizácie zlyhania: zlyhanie jedného z komponentov nevedie ku kolapsu systému ako celku. Navyše sa ukazuje, že je ľahké izolovať chybu súvisiacu s RAM alebo inú logickú chybu presne na komponent, ktorý túto chybu spôsobil.

Ak sa napríklad ovládač zariadenia pokúsi o prístup k pamäti mimo svojho procesného kontajnera, operačný systém môže identifikovať proces, indikovať umiestnenie chyby a vygenerovať súbor výpisu, ktorý môžu zobraziť ladiace programy zdrojového kódu. Zároveň bude zvyšok systému naďalej fungovať a vývojár môže problém lokalizovať a pracovať na jeho odstránení.

Ryža. 6- V operačnom systéme s mikrojadrom nevedú zlyhania pamäte RAM ovládačov, zásobníkov protokolov a iných služieb k narušeniu iných procesov alebo jadra. Okrem toho môže OS okamžite zistiť neoprávnený pokus o prístup do pamäte a uviesť, z akého kódu bol tento pokus vykonaný.

V porovnaní s bežným jadrom OS má mikrokernel po zlyhaní nezvyčajne krátky stredný čas opravy (MTTR). Zvážte, čo sa stane, keď ovládač zariadenia zlyhá: OS môže vypnúť ovládač, obnoviť zdroje používané ovládačom a reštartovať ovládač. Zvyčajne to trvá niekoľko milisekúnd. V typickom monolitickom operačnom systéme musí byť zariadenie reštartované - tento proces môže trvať niekoľko sekúnd až niekoľko minút.

Záverečné poznámky

Nástroje na statickú analýzu dokážu odhaliť chyby programovania ešte pred spustením kódu. Zistia sa dokonca aj tie chyby, ktoré nie sú odhalené vo fázach testovania blokov, testovania systému a tiež vo fáze integrácie, pretože je veľmi ťažké poskytnúť úplné pokrytie kódu pre zložité aplikácie, čo si vyžaduje značné náklady. Okrem toho môžu vývojové tímy používať nástroje na statickú analýzu počas pravidelných stavieb systému, aby sa zabezpečilo, že bude analyzovaný každý kúsok nového kódu.

Medzitým nástroje dynamickej analýzy podporujú integračné a testovacie fázy hlásením chýb (alebo potenciálnych problémov), ktoré sa vyskytnú počas vykonávania programu, vývojovému prostrediu. Tieto nástroje tiež poskytujú úplné spätné sledovanie miesta, kde sa vyskytla chyba. Pomocou týchto informácií môžu vývojári vykonať posmrtné ladenie záhadných zlyhaní programu alebo zlyhania systému v oveľa kratšom čase. Dynamická analýza prostredníctvom stôp zásobníka a premenných môže odhaliť základné príčiny problému – je to lepšie, ako všade používať príkazy „if (ptr != NULL)“, aby ste predišli zlyhaniam a obišli ich.

Použitie včasnej detekcie, lepšie a úplné pokrytie testovaním kódu spolu s opravou chýb pomáha vývojárom vytvárať kvalitnejší softvér v kratšom časovom rámci.

Bibliografia

• Eigler, Frank Ch., “Mudflap: Pointer Use Checking for C/C++”, Proceedings of the GCC Developers Summit 2003, str. 57-70. http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf
• „Analýza haldy: Chyby pamäte sa stali minulosťou“, Príručka programátora QNX Neutrino RTOS. http://pegasus.ott.qnx.com/download/download/16853/neutrino_prog.pdf

O softvérových systémoch QNX

QNX Software Systems je dcérskou spoločnosťou Harman International a popredným svetovým poskytovateľom inovatívnych technológií pre vstavané systémy, vrátane middlewaru, vývojových nástrojov a operačných systémov. QNX® Neutrino® RTOS, QNX Momentics® Development Kit a middleware QNX Aviage®, založené na modulárnej architektúre, tvoria najrobustnejší a najškálovateľnejší softvérový balík na budovanie vysokovýkonných vstavaných systémov. Popredné globálne spoločnosti ako Cisco, Daimler, General Electric, Lockheed Martin a Siemens vo veľkej miere využívajú technológie QNX v sieťových smerovačoch, lekárskych zariadeniach, telematických jednotkách vozidiel, bezpečnostných a zabezpečovacích systémoch, priemyselných robotoch a iných kritických a kritických aplikáciách. úlohy. Hlavné sídlo spoločnosti sa nachádza v Ottawe (Kanada) a distribútori produktov sa nachádzajú vo viac ako 100 krajinách po celom svete.

O spoločnosti Klocwork

Produkty Klocwork sú určené na automatizovanú analýzu statického kódu, detekciu a prevenciu softvérových defektov a bezpečnostných problémov. Naše produkty poskytujú vývojovým tímom nástroje na identifikáciu základných príčin nedostatkov v kvalite softvéru a zabezpečenia a na sledovanie a prevenciu týchto nedostatkov počas celého procesu vývoja. Patentovaná technológia spoločnosti Klocwork bola založená v roku 1996 a priniesla vysokú návratnosť investícií (ROI) pre viac ako 80 klientov, z ktorých mnohí patria do rebríčka Fortune 500 a ponúkajú svetovo najžiadanejšie prostredia na vývoj softvéru. Klocwork je súkromná spoločnosť s pobočkami v Burlingtone, San Jose, Chicagu, Dallase (USA) a Ottawe (Kanada).

Analýza binárneho kódu, teda kódu, ktorý je vykonávaný priamo strojom, nie je triviálna úloha. Vo väčšine prípadov, ak potrebujete analyzovať binárny kód, najskôr sa obnoví rozobratím a potom dekompiláciou do nejakej reprezentácie na vysokej úrovni a potom sa analyzuje, čo sa stalo.

Tu treba povedať, že kód, ktorý bol obnovený, má z hľadiska reprezentácie textu len málo spoločného s kódom, ktorý pôvodne napísal programátor a skompiloval do spustiteľného súboru. Nie je možné presne obnoviť binárny súbor získaný z kompilovaných programovacích jazykov, ako sú C / C ++, Fortran, pretože ide o algoritmicky neformalizovanú úlohu. V procese konverzie zdrojového kódu, ktorý programátor napísal, do programu, ktorý stroj vykonáva, kompilátor vykonáva nezvratné transformácie.

V 90. rokoch minulého storočia bol rozšírený názor, že kompilátor ako mlynček na mäso zomelie zdrojový program a úloha obnoviť ho je podobná úlohe obnoviť ovečku z klobásy.

Nie je to však všetko zlé. V procese získavania klobásy baran stráca svoju funkčnosť, zatiaľ čo binárny program si ju zachováva. Ak by výsledná klobása mohla bežať a skákať, úlohy by boli podobné.

Takže, keďže binárny program si zachoval svoju funkčnosť, môžeme povedať, že je možné obnoviť spustiteľný kód do reprezentácie na vysokej úrovni, takže funkčnosť binárneho programu, ktorého pôvodná reprezentácia neexistuje, a program , ktorých textové znázornenie sme dostali, sú ekvivalentné.

Podľa definície sú dva programy funkčne ekvivalentné, ak na rovnakom vstupe oba ukončia alebo zlyhajú pri ukončení ich vykonávania a ak sa vykonávanie ukončí, vytvoria rovnaký výsledok.

Úloha demontáže sa zvyčajne rieši v poloautomatickom režime, to znamená, že špecialista vykonáva obnovu ručne pomocou interaktívnych nástrojov, napríklad interaktívneho disassemblera IdaPro, radaru alebo iného nástroja. Ďalej sa dekompilácia vykonáva aj v poloautomatickom režime. Ako dekompilačný nástroj na pomoc skúsenej osobe použite HexRays, SmartDecompiler alebo iný dekompilátor, ktorý je vhodný pre danú úlohu dekompilácie.

Obnovenie pôvodnej textovej reprezentácie programu z bajtového kódu sa dá urobiť celkom presne. Pre interpretované jazyky ako Java alebo jazyky rodiny .NET, ktoré sú preložené do bajtového kódu, je úloha dekompilácie riešená inak. V tomto článku sa touto otázkou nezaoberáme.

Takže binárne programy môžu byť analyzované pomocou dekompilácie. Takáto analýza sa zvyčajne vykonáva na pochopenie správania programu s cieľom nahradiť ho alebo upraviť.

Z praxe práce s legacy programami

Určitý softvér, napísaný pred 40 rokmi v nízkoúrovňových jazykoch C a Fortran, riadi zariadenia na výrobu ropy. Porucha tohto zariadenia môže byť kritická pre výrobu, takže zmena softvéru je veľmi nežiaduca. V priebehu rokov sa však zdrojové kódy stratili.

Nový pracovník oddelenia informačnej bezpečnosti, ktorého úlohou bolo pochopiť, ako čo funguje, zistil, že program na ovládanie senzorov s určitou pravidelnosťou niečo zapisuje na disk, ale nie je jasné, čo zapisuje a ako sa tieto informácie dajú použiť. Mal tiež predstavu, že monitorovanie zariadení by sa mohlo zobraziť na jednej veľkej obrazovke. Na to bolo potrebné zistiť, ako program funguje, čo a v akom formáte zapisuje na disk, ako možno tieto informácie interpretovať.

Na vyriešenie problému bola použitá technológia dekompilácie s následnou analýzou obnoveného kódu. Softvérové ​​komponenty sme najskôr jeden po druhom rozobrali, potom sme lokalizovali kód, ktorý bol zodpovedný za vstup/výstup informácií a postupne sme z tohto kódu začali obnovovať s prihliadnutím na závislosti. Potom sa obnovila logika programu, čo umožnilo odpovedať na všetky otázky bezpečnostnej služby týkajúce sa analyzovaného softvéru.

Ak potrebujete analyzovať binárny program s cieľom obnoviť logiku jeho činnosti, čiastočne alebo úplne obnoviť logiku prevodu vstupných údajov na výstupné údaje atď., Je vhodné to urobiť pomocou dekompilátora.

Okrem takýchto úloh existujú v praxi úlohy analýzy binárnych programov podľa požiadaviek informačnej bezpečnosti. Zákazník zároveň nie vždy chápe, že táto analýza je časovo veľmi náročná. Zdalo by sa, že dekompilujte a spustite výsledný kód pomocou statického analyzátora. Ale ako výsledok kvalitatívnej analýzy to takmer nikdy nevyjde.

Po prvé, nájdené zraniteľnosti musia byť schopné nielen nájsť, ale aj vysvetliť. Ak sa v vysokoúrovňovom jazykovom programe nájde zraniteľnosť, analytik alebo nástroj na analýzu kódu v ňom ukáže, ktoré fragmenty kódu obsahujú chyby, ktoré spôsobili zraniteľnosť. Čo ak neexistuje zdrojový kód? Ako ukázať, ktorý kód spôsobil zraniteľnosť?

Dekompilátor obnoví kód, ktorý je „posiaty“ artefaktmi obnovy a je zbytočné mapovať identifikovanú zraniteľnosť na takýto kód, aj tak nie je nič jasné. Obnovený kód je navyše zle štruktúrovaný, a preto nie je vhodný pre nástroje na analýzu kódu. Vysvetlenie zraniteľnosti z hľadiska binárneho programu je tiež ťažké, pretože osoba, pre ktorú sa vysvetlenie robí, sa musí dobre orientovať v binárnej reprezentácii programov.

Po druhé, binárna analýza podľa požiadaviek informačnej bezpečnosti sa musí vykonávať s pochopením toho, čo robiť s výsledkom, pretože je veľmi ťažké opraviť zraniteľnosť v binárnom kóde, ale neexistuje žiadny zdrojový kód.

Napriek všetkým vlastnostiam a ťažkostiam vykonávania statickej analýzy binárnych programov podľa požiadaviek informačnej bezpečnosti existuje veľa situácií, keď je potrebné takúto analýzu vykonať. Ak z nejakého dôvodu neexistuje zdrojový kód a binárny program vykonáva funkčnosť, ktorá je kritická podľa požiadaviek informačnej bezpečnosti, musí sa skontrolovať. Ak sa zistia slabé miesta, takáto aplikácia by sa mala podľa možnosti zaslať na revíziu, prípadne by sa pre ňu mal vytvoriť dodatočný „shell“, ktorý umožní kontrolovať pohyb citlivých informácií.

Keď bola zraniteľnosť skrytá v binárnom súbore

Ak má kód, ktorý program vykonáva, vysokú úroveň kritickosti, aj keď je dostupný zdrojový kód programu v jazyku vysokej úrovne, je užitočné vykonať audit binárneho súboru. Pomôže to eliminovať vrtochy, ktoré by kompilátor mohol priniesť vykonaním optimalizácie transformácií. Takže v septembri 2017 sa široko diskutovalo o optimalizačnej transformácii vykonanej kompilátorom Clang. Jeho výsledkom bolo volanie funkcie, ktorá by sa nikdy nemala volať.

#include typedef int(*Funkcia)(); statická funkcia Do; static int EraseAll() ( return system("rm -rf /"); ) void NeverCalled() ( Do = EraseAll; ) int main() ( return Do(); )

V dôsledku optimalizačných transformácií dostane kompilátor takýto kód assembleru. Príklad bol skompilovaný pod Linuxom X86 s príznakom -O2.

Text .globl NeverCalled .align 16, 0x90 .type NeverCalled,@function NeverCalled: # @NeverCalled retl .Lfunc_end0: .size NeverCalled, .Lfunc_end0-NeverCalled .globl main .align 16, #x90 main: main subl $12, %esp movl $.L.str, (%esp) calll system addl $12, %esp retl .Lfunc_end1: .size main, .Lfunc_end1-main .type .L.str,@object # @.str . sekcia .rodata.str1.1,"aMS",@progbits,1 .L.str: .asciz "rm -rf /" .size .L.str, 9

V zdrojovom kóde je nedefinované správanie. Funkcia NeverCalled() sa volá kvôli optimalizačným konverziám, ktoré kompilátor vykonáva. Počas procesu optimalizácie s najväčšou pravdepodobnosťou vykoná analýzu aliasov a v dôsledku toho funkcia Do() dostane adresu funkcie NeverCalled(). A keďže metóda main() volá funkciu Do(), ktorá nie je definovaná, čo je štandardom nedefinované správanie, získa sa nasledujúci výsledok: zavolá sa funkcia EraseAll(), ktorá vykoná „rm -rf /“ príkaz.

Nasledujúci príklad: v dôsledku optimalizačných transformácií kompilátora sme stratili kontrolu ukazovateľa na NULL pred jeho dereferenciou.

#include void Checker(int *P) ( int deadVar = *P; if (P == 0) return; *P = 8; )

Pretože riadok 3 dereferencuje ukazovateľ, kompilátor predpokladá, že ukazovateľ nie je nulový. Ďalej bol riadok 4 odstránený v dôsledku optimalizácie „odstránenia nedostupného kódu“, pretože porovnanie sa považuje za nadbytočné, a potom bol riadok 3 odstránený kompilátorom v dôsledku optimalizácie „eliminácie mŕtveho kódu“. Zostáva len riadok 5. Kód assembleru, ktorý je výsledkom kompilácie gcc 7.3 pod Linuxom x86 s príznakom -O2, je zobrazený nižšie.

Text .p2align 4,15 .globl _Z7CheckerPi .type _Z7CheckerPi, @funkcia _Z7CheckerPi: movl 4(%esp), %eax movl $8, (%eax) ret

Vyššie uvedené príklady optimalizácie kompilátora sú výsledkom nedefinovaného správania UB v kóde. Toto je však úplne normálny kód, o ktorom väčšina programátorov bude predpokladať, že je bezpečný. Dnes si programátori venujú čas, aby odstránili nedefinované správanie v programe, kým pred 10 rokmi tomu nevenovali pozornosť. V dôsledku toho môže starý kód obsahovať zraniteľné miesta súvisiace s UB.

Väčšina moderných analyzátorov statického zdrojového kódu nezistí chyby súvisiace s UB. Ak teda kód vykonáva funkciu, ktorá je kritická z hľadiska požiadaviek informačnej bezpečnosti, je potrebné skontrolovať jeho zdrojové kódy aj samotný kód, ktorý bude spustený.

anotácia

V súčasnosti bolo vyvinutých veľké množstvo nástrojov na automatizáciu hľadania softvérových zraniteľností. Tento článok bude diskutovať o niektorých z nich.

Úvod

Statická analýza kódu je softvérová analýza, ktorá sa vykonáva na zdrojovom kóde programov a je implementovaná bez skutočného spustenia skúmaného programu.

Softvér často obsahuje rôzne zraniteľnosti spôsobené chybami v kóde programu. Chyby pri vývoji programov v niektorých situáciách vedú k zlyhaniu programu, a preto je narušená normálna prevádzka programu: v takom prípade sa údaje často menia a poškodzujú, program alebo dokonca systém sa zastaví. . Väčšina zraniteľností súvisí s nesprávnym spracovaním údajov prijatých zvonku, prípadne s ich nedostatočne prísnym overovaním.

Na identifikáciu zraniteľností sa používajú rôzne nástroje, napríklad statické analyzátory zdrojového kódu programu, ktorých prehľad je uvedený v tomto článku.

Klasifikácia bezpečnostných zraniteľností

Pri porušení požiadavky na správnu činnosť programu na všetkých možných vstupných dátach je možný vznik takzvaných bezpečnostných zraniteľností (bezpečnostná zraniteľnosť). Zraniteľnosť zabezpečenia môže spôsobiť, že jeden program sa použije na prekonanie bezpečnostných obmedzení celého systému ako celku.

Klasifikácia bezpečnostných zraniteľností v závislosti od softvérových chýb:

1. Pretečenie vyrovnávacej pamäte. Táto chyba zabezpečenia sa vyskytuje v dôsledku nedostatočnej kontroly nad mimohraničným poľom v pamäti počas vykonávania programu. Keď dátový paket, ktorý je príliš veľký, pretečie obmedzenú vyrovnávaciu pamäť, obsah externých pamäťových buniek sa prepíše a program sa zrúti a zrúti. Podľa umiestnenia vyrovnávacej pamäte v pamäti procesu sa rozlišujú pretečenia vyrovnávacej pamäte na zásobníku (pretečenie vyrovnávacej pamäte zásobníka), halde (pretečenie vyrovnávacej pamäte haldy) a oblasti statických údajov (pretečenie vyrovnávacej pamäte bss).
2. Zraniteľnosť (zraniteľnosť pokazeného vstupu). Zraniteľnosť sa môže vyskytnúť, keď používateľský vstup prechádza bez dostatočnej kontroly tlmočníkovi nejakého externého jazyka (zvyčajne unixového shellu alebo jazyka SQL). V tomto prípade môže užívateľ zadať vstupné dáta tak, že spustený interpret vykoná úplne iný príkaz, než aký zamýšľali autori zraniteľného programu.
3. Chyba zabezpečenia formátovacieho reťazca. Tento typ bezpečnostnej zraniteľnosti je podtriedou zraniteľnosti. Vzniká nedostatočnou kontrolou parametrov pri použití formátových I/O funkcií printf, fprintf, scanf atď. štandardnej knižnice C. Tieto funkcie berú ako jeden z parametrov reťazec znakov, ktorý určuje vstupný alebo výstupný formát pre nasledujúce argumenty funkcie. Ak si používateľ môže nastaviť typ formátovania sám, táto chyba zabezpečenia môže byť výsledkom neúspešnej aplikácie funkcií formátovania reťazcov.
4. Zraniteľnosť v dôsledku chýb synchronizácie (súčasné podmienky). Problémy spojené s multitaskingom vedú k situáciám, ktoré sa nazývajú: program, ktorý nie je navrhnutý na spustenie v prostredí multitaskingu, sa môže domnievať, že napríklad súbory, ktoré používa pri spustení, nemôže zmeniť iný program. Výsledkom je, že útočník, ktorý včas nahradí obsah týchto pracovných súborov, môže prinútiť program vykonať určité akcie.

Samozrejme, okrem tých, ktoré sú uvedené, existujú aj ďalšie triedy bezpečnostných zraniteľností.

Prehľad existujúcich analyzátorov

Nasledujúce nástroje sa používajú na detekciu bezpečnostných zraniteľností v programoch:

• Dynamické debuggery. Nástroje, ktoré vám umožňujú ladiť program, keď je spustený.
• Statické analyzátory (statické debuggery). Nástroje, ktoré využívajú informácie nazhromaždené počas statickej analýzy programu.

Statické analyzátory indikujú miesta v programe, kde sa môže vyskytnúť chyba. Tieto podozrivé útržky kódu môžu obsahovať chybu alebo môžu byť úplne neškodné.

Tento článok poskytuje prehľad niekoľkých existujúcich statických analyzátorov. Pozrime sa bližšie na každý z nich.

1.BOON

Nástroj, ktorý na základe hĺbkovej sémantickej analýzy automatizuje proces skenovania zdrojových textov C pri hľadaní zraniteľností, ktoré môžu viesť k pretečeniu vyrovnávacej pamäte. Zisťuje možné chyby za predpokladu, že niektoré hodnoty sú súčasťou implicitného typu so špecifickou veľkosťou vyrovnávacej pamäte.

2.Kvalita

Analytický nástroj na vyhľadávanie chýb v programoch C. Program rozširuje jazyk C o ďalšie užívateľom definované špecifikátory typu. Programátor komentuje svoj program príslušnými špecifikátormi a cqual kontroluje chyby. Nesprávne anotácie označujú potenciálne chyby. Squal možno použiť na detekciu potenciálnych zraniteľností formátovacieho reťazca.

3. MOPS

(MOdel checking Programs for Security) je nástroj na vyhľadávanie bezpečnostných zraniteľností v programoch C. Jeho účel: dynamické nastavenie, aby sa zabezpečilo, že program C zodpovedá statickému modelu. MOPS používa model softvérového auditu, ktorý pomáha určiť, či program vyhovuje súboru pravidiel definovaných na vytvorenie bezpečného softvéru.

4.ITS4, RATS, PScan, Flawfinder

Nasledujúce statické analyzátory sa používajú na nájdenie chýb pretečenia vyrovnávacej pamäte a chýb formátovacieho reťazca:

1. . Jednoduchý nástroj, ktorý staticky skenuje zdrojový kód C/C++, aby odhalil potenciálne bezpečnostné chyby. Zaznamenáva volania na potenciálne nebezpečné funkcie, ako je strcpy/memcpy, a vykonáva povrchnú sémantickú analýzu v snahe posúdiť, aký nebezpečný je takýto kód, a tiež poskytuje rady, ako ho vylepšiť.
2. . Nástroj RATS (Rough Auditing Tool for Security) spracováva kód C/C++ a dokáže spracovať aj skripty Perl, PHP a Python. RATS skenuje zdrojový kód pre potenciálne nebezpečné volania funkcií. Účelom tohto nástroja nie je definitívne nájsť chyby, ale poskytnúť rozumné závery, na základe ktorých môže špecialista manuálne vykonať overenie kódu. RATS využíva kombináciu bezpečnostných kontrol robustnosti od sémantických kontrol v ITS4 až po hĺbkovú sémantickú analýzu, ktorá hľadá defekty pretečenia vyrovnávacej pamäte odvodené od MOPS.
3. . Skenuje zdrojové texty C kvôli potenciálne nesprávnemu použitiu funkcií podobných printf a nájde slabé miesta vo formátovacích reťazcoch.
4. . Rovnako ako RATS je to statický skener zdrojového kódu pre programy napísané v C/C++. Vyhľadáva funkcie, ktoré sa najčastejšie zneužívajú, priraďuje im rizikové skóre (na základe informácií, ako sú odovzdané parametre) a zostavuje zoznam potenciálnych zraniteľností a zoraďuje ich podľa závažnosti.

Všetky tieto nástroje sú podobné a používajú iba lexikálnu a jednoduchú analýzu. Preto výsledky produkované týmito programami môžu obsahovať až 100 % falošných správ.

5. Parta

Nástroj na analýzu a vizualizáciu programu C, ktorý vytvára graf závislosti, ktorý pomáha audítorovi pochopiť modulárnu štruktúru programu.

6 OSN

Jednoduchý analyzátor zdrojového kódu. Bol navrhnutý tak, aby zachytával chyby, ako sú neinicializované premenné, nulové ukazovatele a chyby poľa mimo hraníc. UNO vám umožňuje vykonávať jednoduchú analýzu riadiaceho toku a dátových tokov, vykonávať intra- a inter-procedurálnu analýzu a špecifikovať užívateľské vlastnosti. Tento nástroj však nebol dokončený na analýzu skutočných aplikácií, nepodporuje veľa štandardných knižníc a v tejto fáze vývoja neumožňuje analyzovať žiadne seriózne programy.

7. FlexeLint (PC-Lint)

Tento analyzátor je určený na analýzu zdrojového kódu s cieľom odhaliť rôzne typy chýb. Program vykonáva sémantickú analýzu zdrojového kódu, analýzu dát a kontrolné toky.

Na konci práce sa vydávajú správy niekoľkých hlavných typov:

• Je možný nulový ukazovateľ;
• Problémy s alokáciou pamäte (napr. no free() po malloc());
• Problematický tok kontroly (napríklad nedostupný kód);
• Možné pretečenie vyrovnávacej pamäte, aritmetické pretečenie;
• Upozornenia na zlý a potenciálne nebezpečný štýl kódu.

8. Viva64

Nástroj, ktorý pomáha špecialistovi vystopovať potenciálne nebezpečné fragmenty v zdrojovom kóde programov C/C++ súvisiace s prechodom z 32-bitových systémov na 64-bitové. Viva64 je integrovaný do prostredia Microsoft Visual Studio 2005/2008, čo prispieva k pohodlnej práci s týmto nástrojom. Analyzátor pomáha písať správny a optimalizovaný kód pre 64-bitové systémy.

9. Parasoft C++ Test

Špecializovaný nástroj pre Windows, ktorý vám umožňuje automatizovať analýzu kvality kódu C++. Balík C++Test analyzuje projekt a generuje kód na testovanie komponentov obsiahnutých v projekte. Balík C++Test robí veľmi dôležitú prácu pri analýze tried C++. Po načítaní projektu je potrebné nastaviť testovacie metódy. Softvér preskúma každý argument metódy a vráti zodpovedajúce typy hodnôt. Pre tieto jednoduché typy sú nahradené predvolené hodnoty argumentov; môžete definovať testovacie údaje pre užívateľom definované typy a triedy. Je možné prepísať predvolené argumenty C++ Test a vrátiť hodnoty získané z testu. Za zmienku stojí najmä schopnosť C++Test testovať nedokončený kód. Softvér generuje stub kód pre akúkoľvek metódu a funkciu, ktorá ešte neexistuje. Podporovaná je simulácia externých zariadení a užívateľsky definovaných vstupov. Obidve funkcie sú opätovne testovateľné. Po definovaní testovacích parametrov pre všetky metódy je balík C++Test pripravený na spustenie spustiteľného kódu. Balík generuje testovací kód volaním kompilátora Visual C++, aby ho pripravil. Je možné generovať testy na úrovni metódy, triedy, súboru a projektu.

10. Pokrytie

Nástroje sa používajú na identifikáciu a opravu chýb zabezpečenia a kvality v kritických aplikáciách. Technológia Coverity odstraňuje prekážky pri písaní a nasadzovaní zložitého softvéru automatizáciou odhaľovania a odstraňovania kritických chýb a bezpečnostných nedostatkov počas procesu vývoja. Nástroj Coverity je schopný spracovať desiatky miliónov riadkov kódu s minimálnou pozitívnou chybou a poskytuje 100% pokrytie sledovania.

11.KlocWork K7

Produkty spoločnosti sú určené na automatizovanú analýzu statického kódu, detekciu a prevenciu softvérových defektov a bezpečnostných problémov. Nástroje spoločnosti slúžia na identifikáciu základných príčin nedostatkov v kvalite a bezpečnosti softvéru a na sledovanie a prevenciu týchto nedostatkov počas celého procesu vývoja.

12 Frama-C

Otvorená, integrovaná sada nástrojov na analýzu zdrojového kódu C. Sada obsahuje ACSL (ANSI/ISO C Specification Language) - špeciálny jazyk, ktorý vám umožňuje podrobne popísať špecifikácie funkcií C, napríklad určiť rozsah platných vstupných hodnôt funkcie a rozsah normálneho výstupu. hodnoty.

Táto súprava nástrojov pomáha vykonávať nasledujúce akcie:

• Vykonajte formálne kontroly kódu;
• Hľadajte potenciálne chyby pri vykonávaní;
• Vykonajte audit alebo preskúmanie kódexu;
• Vykonajte reverzné inžinierstvo kódu na zlepšenie pochopenia štruktúry;
• Vytvorte formálnu dokumentáciu.

13. CodeSurfer

Nástroj na analýzu programu, ktorý nie je priamo navrhnutý na nájdenie chýb bezpečnostných zraniteľností. Jeho hlavné výhody sú:

• Analýza ukazovateľa;
• Rôzne analýzy dátových tokov (použitie a definícia premenných, závislosť dát, vytváranie grafov);
• Skriptovací jazyk.

CodeSurfer možno použiť na nájdenie chýb v zdrojovom kóde, na zlepšenie pochopenia zdrojového kódu a na spätné inžinierstvo programov. V rámci prostredia CodeSurfer bol vyvinutý prototyp nástroja na detekciu bezpečnostných zraniteľností, avšak vyvinutý nástroj je využívaný len v rámci vývojárskej organizácie.

14. FxCop

Poskytuje prostriedky na automatické overenie .NET zostáv podľa smerníc Microsoft .NET Framework Design Guidelines. Kompilovaný kód sa kontroluje pomocou reflexných mechanizmov, analýzy MSIL a analýzy grafu hovorov. Výsledkom je, že FxCop je schopný odhaliť viac ako 200 nedostatkov (alebo chýb) v nasledujúcich oblastiach:

• Architektúra knižnice;
• lokalizácia;
• pravidlá pomenovania;
• výkon;
• Bezpečnosť.

FxCop poskytuje možnosť vytvárať si vlastné pravidlá pomocou špeciálneho SDK. FxCop môže pracovať v grafickom rozhraní aj na príkazovom riadku.

15.JavaChecker

Je to statický programový analyzátor Java založený na technológii TermWare.

Tento nástroj vám umožňuje identifikovať chyby kódu, ako napríklad:

• nedbalé spracovanie výnimiek (prázdne bloky catch, všeobecné výnimky atď.);
• skrytie mien (napríklad, keď je názov člena triedy rovnaký ako názov formálneho parametra metódy);
• porušenie štýlu (štýl programovania môžete nastaviť pomocou sady regulárnych výrazov);
• porušenie štandardných zmlúv o používaní (napríklad, keď je prepísaná metóda rovná sa, ale nie hashCode);
• porušenie synchronizácie (napríklad, keď je prístup k synchronizovanej premennej mimo synchronizovaného bloku).

Súbor kontrol je možné kontrolovať pomocou kontrolných komentárov.

JavaChecker je možné volať zo skriptu ANT.

16 Simian

Analyzátor podobnosti, ktorý hľadá opakujúcu sa syntax vo viacerých súboroch súčasne. Program rozumie syntaxi rôznych programovacích jazykov vrátane C#, T-SQL, JavaScriptu a Visual BasicR a dokáže vyhľadávať aj opakujúce sa fragmenty v textových súboroch. Mnohé možnosti prispôsobenia vám umožňujú doladiť pravidlá pre hľadanie duplicitného kódu. Napríklad prahový parameter (threshold) určuje, koľko opakovaných riadkov kódu sa má považovať za duplikát.

Simian je malý nástroj určený na efektívne vyhľadávanie opakovaní kódu. Nemá grafické rozhranie, ale dá sa spustiť z príkazového riadku alebo k nemu pristupovať programovo. Výsledky sa zobrazujú v textovej forme a môžu byť prezentované v jednom zo vstavaných formátov (napríklad XML). Zatiaľ čo riedke rozhranie Simian a obmedzené výstupné možnosti vyžadujú určitú krivku učenia, pomáha udržiavať integritu a efektivitu produktu. Simian je vhodný na hľadanie duplicitného kódu vo veľkých aj malých projektoch.

Opakujúci sa kód znižuje udržiavateľnosť a upgradovateľnosť projektu. Simian môžete použiť na rýchle nájdenie duplicitných útržkov kódu v mnohých súboroch súčasne. Keďže Simian možno spustiť z príkazového riadku, môže byť zahrnutý do procesu zostavovania, aby dostával upozornenia alebo zastavil proces v prípade opakovania kódu.

Záver

V tomto článku sme teda uvažovali o statických analyzátoroch zdrojového kódu, čo sú pomocné nástroje pre programátora. Všetky nástroje sú odlišné a pomáhajú sledovať najrôznejšie triedy bezpečnostných zraniteľností v programoch. Možno konštatovať, že statické analyzátory musia byť presné a citlivé. Ale, bohužiaľ, nástroje statického ladenia nemôžu poskytnúť absolútne spoľahlivý výsledok.