Ինչո՞ւ Codex Անվտանգությունը չի ներառում SAST հաշվետվություն

Տասնամյակներ շարունակ, հավելվածների անվտանգության ստատիկ փորձարկումը (SAST՝ հավելվածների անվտանգության ստատիկ փորձարկում) եղել է անվտանգության թիմերի համար կոդի վերանայումը մասշտաբավորելու ամենաարդյունավետ եղանակներից մեկը։ 

Բայց երբ մենք կառուցեցինք Codex Անվտանգությունը, մենք միտումնավոր նախագծային ընտրություն կատարեցինք. մենք չսկսեցինք ներմուծելով ստատիկ վերլուծության հաշվետվություն և խնդրելով ագենտին այն վերլուծել։ Մենք համակարգը նախագծեցինք սկսել հենց պահոցից՝ դրա ճարտարապետությունից, վստահության սահմաններից և նախատեսված վարքագծից, և վավերացնել այն, ինչ հայտնաբերում է նախքան խնդրելը, որ մարդը ժամանակ ծախսի դրա վրա։ 

Պատճառը պարզ է․ ամենադժվար խոցելիությունները սովորաբար տվյալների հոսքի խնդիրներ չեն։ Դրանք տեղի են ունենում, երբ կոդը կարծես պարտադրում է անվտանգության ստուգում, բայց այդ ստուգումն իրականում չի երաշխավորում այն հատկությունը, որի վրա համակարգը հիմնվում է։ Այլ կերպ ասած մարտահրավերը միայն այն չէ, թե ինչպես է տվյալը շարժվում ծրագրի միջով, այլ սահմանելը, թե արդյոք կոդում առկա պաշտպանական միջոցներն իսկապես աշխատո՞ւմ են։

SAST-ը հաճախ ձևակերպվում է որպես մաքուր խողովակաշար՝ նույնականացնել անվստահելի մուտքային տվյալների աղբյուրը, հետևել տվյալներին ծրագրի միջով և նշել այն դեպքերը, երբ այդ տվյալները առանց մաքրման հասնում են զգայուն ընդունիչի։ Դա առաջնակարգ մոդել է և ընդգրկում է բազմաթիվ իրական սխալներ։

Գործնականում SAST-ը պետք է դիմի մոտարկումների, որպեսզի մեծ մասշտաբով հաշվարկային առումով կառավարելի մնա՝ հատկապես իրական կոդային բազաներում, որտեղ կան անուղղակի կապեր, դինամիկ հաղորդումներ, հետկանչեր, արտացոլում և շրջանակային կառավարման հոսքի ծանրաբեռնվածություն։ Այդ մոտարկումները SAST-ի հասցեին քննադատություն չեն․ դրանք կոդի մասին դատողություններ անելու փորձի իրականությունն են առանց այն գործարկելու։

Դա ինքնին այն չէ, թե ինչու Codex Անվտանգությունը չի սկսում SAST հաշվետվությունից։

Ավելի խորքային խնդիրն այն է, թե ինչ է տեղի ունենում այն բանից հետո, երբ հաջողությամբ հետագծում եք աղբյուրից ընդունիչը։

Նույնիսկ երբ ստատիկ վերլուծությունը ճիշտ է հետագծում մուտքագրումը բազմաթիվ ֆունկցիաների և շերտերի միջով, այն դեռ պետք է պատասխանի այն հարցին, որը փաստացի որոշում է՝ արդյոք խոցելիություն առկա է․

Վերցրեք մի սովորական օրինաչափություն. կոդը, անվստահելի բովանդակությունը ցուցադրելուց առաջ, կանչում է ինչ-որ բան, օրինակ՝ sanitize_html() ։ Ստատիկ անալիզատորը կարող է տեսնել, որ մաքրման ծրագիրը գործարկվել է։ Այն, ինչ սովորաբար չի կարող որոշել, այն է՝ արդյոք այդ մաքրման ծրագիրը իրականում բավարար է ներգրավված կոնկրետ կատարման համատեքստի, ձևանմուշների շարժիչի, կոդավորման վարքագծի և հետագա փոխակերպումների համար։

Այստեղ է, որ ամեն ինչ բարդանում է։ Խնդիրը միայն այն չէ, թե արդյոք տվյալները հասնում են ընդունիչին։ Խոսքն այն մասին է, թե արդյոք կոդում առկա ստուգումները իրականում սահմանափակում են արժեքն այնպես, ինչպես ենթադրում է համակարգը։

Այլ կերպ ասած՝ մեծ տարբերություն կա «կոդը կանչում է մաքրման ծրագիր» և «համակարգն անվտանգ է» տարբերակների միջև։

Ահա մի օրինաչափություն, որը անընդհատ հանդիպում է իրական համակարգերում։

Վեբ հավելվածը ստանում է JSON բեռնվածք, առանձնացնում է redirect_url դաշտը, ստուգում է այն՝ թույլատրելի ցանկի կանոնավոր արտահայտության (regex) միջոցով, URL-ն ապակոդավորում է և արդյունքը փոխանցում է վերահղման մշակիչին։

Դասական «աղբյուրից ընդունիչ» հաշվետվությունը կարող է նկարագրել հոսքը՝

անվստահելի մուտք → regex ստուգում → URL-ի ապակոդավորում → վերահղում

Բայց իրական հարցն այն չէ, թե արդյոք ստուգումը գոյություն ունի։ Խոսքն այն մասին է, թե արդյոք այդ ստուգումը հետագա փոխակերպումներից հետո դեռևս սահմանափակում է արժեքը։

Եթե regex-ը գործարկվում է ապակոդավորումից առաջ, արդյո՞ք այն փաստացի սահմանափակում է ապակոդավորված URL-ն այնպես, ինչպես վերուղղման մշակիչը մեկնաբանում է այն։

Դրան պատասխանելը ենթադրում է հիմնավորում ամբողջ փոխակերպման շղթայի վերաբերյալ՝ ինչ է թույլ տալիս regex-ը, ինչպես են գործում ապակոդավորումն ու նորմալացումը, ինչպես է URL-ի վերլուծումը վերաբերվում եզրային դեպքերին, և ինչպես է վերահղման տրամաբանությունը լուծում սխեմաներն ու հեղինակությունները։

Գործնականում կարևոր նշանակություն ունեցող շատ խոցելիություններ այսպիսի տեսք ունեն՝ գործողությունների հերթականության սխալներ, մասնակի նորմալացում, վերլուծության երկիմաստություններ և վավերացման ու մեկնաբանման միջև անհամապատասխանություններ։ Տվյալների հոսքը տեսանելի է։ Թույլ կողմն այն է, թե ինչպես են սահմանափակումները տարածվում կամ չեն տարածվում փոխակերպումների շղթայի միջով։

Սա պարզապես տեսական ձևաչափ չէ։ CVE-2024-29041⁠(բացվում է նոր պատուհանում)-ում Express շրջանակը տուժել է բաց վերահղման խոցելիությունից, որի դեպքում սխալ ձևաչափված URL-ները կարող էին շրջանցել թույլատրման ցանկի (allowlist-ի) սովորական իրականացումները՝ վերահղման նպատակակետերի կոդավորման և դրանց հետագա մեկնաբանման ձևի պատճառով։ Տվյալների հոսքը հստակ էր։ Ավելի դժվար հարցը և այն, որը որոշում էր՝ արդյոք սխալն առկա էր, այն էր՝ արդյոք վավերացումը դեռ ուժի մեջ էր փոխակերպումների շղթայից հետո։

Codex Անվտանգությունը կառուցված է պարզ նպատակի շուրջ՝ նվազեցնել խնդիրների տեսակավորումը ավելի ամուր ապացույցներով։ Պրոդուկտի մեջ սա նշանակում է օգտագործել պահոցին հատուկ համատեքստը (ներառյալ սպառնալիքների մոդելը) և մեկուսացված միջավայրում վավերացնել բարձր ազդանշան ունեցող խնդիրները՝ նախքան դրանք ի հայտ բերելը։ 

Երբ Codex Անվտանգությունը հանդիպում է սահմանագծի, որը նման է «վավերացման» կամ «մաքրման», այն դա չի դիտարկում որպես նշման դաշտ։ Այն փորձում է հասկանալ, թե ինչ երաշխիք է փորձում ապահովել կոդը և ապա փորձում է կեղծարկել այդ երաշխիքը։

Գործնականում դա, որպես կանոն, այսպիսի խառնուրդի է նմանվում՝

• Կարդալ համապատասխան կոդային ուղին՝ պահոցի ամբողջական համատեքստով, ինչպես անվտանգության հետազոտողը կկարդար, և փնտրել անհամապատասխանություններ նպատակի և իրականացման միջև։ Սա ներառում է մեկնաբանություններ, բայց մոդելը պարտադիր չէ, որ հավատա մեկնաբանություններին, ուստի ձեր կոդի վերևում //Halvar says: this is not a bug ավելացնելը նրան չի շփոթեցնի, եթե իսկապես սխալ կա։
• Խնդիրը նվազեցնել ամենափոքր փորձարկելի հատվածի (օրինակ՝ մեկ մուտքագրի շուրջ փոխակերպման խողովակաշարի), որպեսզի կարողանաք այն հիմնավորել՝ առանց համակարգի մնացած մասերի խանգարելու։ Այս իմաստով Codex Անվտանգությունն առանձնացնում է կոդի փոքր հատվածներ, ապա դրանց համար գրում է միկրո-ֆազերներ։
• Փոխակերպումների ընթացքում սահմանափակումների վերաբերյալ հիմնավորումը՝ առանց յուրաքանչյուր ստուգումը առանձին դիտարկելու։ Պատշաճ դեպքերում սա կարող է ներառել նաև ձևակերպում՝ որպես բավարարելիության խնդիր։ Այլ կերպ ասած, մենք մոդելին տրամադրում ենք հասանելիություն Python միջավայր՝ z3-solver-ով, և այն կարողանում է արդյունավետորեն օգտագործել անհրաժեշտության դեպքում, ճիշտ ինչպես մարդը կօգտագործեր՝ պատասխանելու հատկապես բարդ մուտքային սահմանափակումների խնդրին։ Սա հատկապես օգտակար է ոչ ստանդարտ ճարտարապետություններում ամբողջ թվերի գերլցումներ կամ նմանատիպ սխալներ հայտնաբերելու համար։
• Հնարավորության դեպքում հիպոթեզների իրականացում պաշտպանված վավերացման միջավայրում՝ «սա կարող է խնդիր լինել»-ը «սա խնդիր է»-ից տարբերելու համար։ Չկա ավելի լավ ապացույց, քան ամբողջական սկզբից մինչև վերջ PoC-ը (Proof of Concept)՝ կոդը կազմարկված վրիպազերծման ռեժիմում։ 

Սա է հիմնական տեղաշարժը. «ստուգում կա» կետում կանգ առնելու փոխարեն համակարգը շարժվում է դեպի «անփոփոխելին պահպանվում է (կամ՝ ոչ), և ահա ապացույցները»։ Եվ մոդելը ընտրում է այդ աշխատանքի համար լավագույն գործիքը։

Խելամիտ արձագանքը հետևյալն է՝ ինչո՞ւ չանել երկուսն էլ։ Սկսեք SAST հաշվետվությունից, ապա օգտագործեք ագենտը՝ ավելի խորը հիմնավորման համար։

Կան դեպքեր, երբ նախապես հաշվարկված արդյունքները օգտակար են, հատկապես սահմանափակ, հայտնի սխալների դասերի համար։ Բայց համատեքստում խոցելիությունները հայտնաբերելու և վավերացնելու համար նախագծված ագենտի դեպքում՝ SAST հաշվետվությունից սկսելը ստեղծում է երեք կանխատեսելի խափանման ռեժիմներ։

Նախ, դա կարող է խրախուսել վաղաժամ սահմանափակումը։ Գտածոների ցանկը քարտեզ է, թե որտեղ է գործիքն արդեն որոնել։ Եթե դա դիտարկեք որպես մեկնարկային կետ, ապա կարող եք համակարգը կողմնակալել՝ ստիպելով, որ այն անհամաչափ ջանք ծախսի նույն տարածքներում, օգտագործի նույն աբստրակցիաները և բաց թողնի խնդիրների այն դասերը, որոնք չեն տեղավորվում գործիքի աշխարհայացքի մեջ։

Երկրորդ՝ այն կարող է ներմուծել թաքնված դատողություններ, որոնք դժվար է չեղարկել։ SAST-ի շատ հայտնաբերումներ ներառում են ենթադրություններ մաքրման, վավերացման կամ վստահության սահմանների մասին։ Եթե այդ ենթադրությունները սխալ են կամ թերի, դրանք հիմնավորման ցիկլի մեջ ներառելը կարող է ագենտին տեղափոխել «հետաքննել»-ից դեպի «հաստատել կամ մերժել», ինչը չենք ցանկանում, որ ագենտն անի։

Երրորդ, դա կարող է դժվարացնել հիմնավորման համակարգի գնահատումը։ Եթե խողովակաշարը սկսվում է SAST-ի ելքային տվյալներից, դժվար է տարանջատել՝ ինչն է ագենտը հայտնաբերել սեփական վերլուծությամբ, և ինչը ստացել մեկ այլ գործիքից։ Այդ տարանջատումը կարևոր է, եթե ցանկանում եք ճշգրիտ չափել համակարգի հնարավորությունները, ինչն անհրաժեշտ է համակարգի ժամանակի ընթացքում կատարելագործման համար։

Այսպիսով, մենք ստեղծեցինք Codex Անվտանգությունը՝ սկսելու այնտեղից, որտեղ սկսվում են անվտանգության հետազոտությունները՝ կոդից և համակարգի մտադրությունից, որտեղ վավերացումը օգտագործվում է վստահության նշաձողը բարձրացնելու համար նախքան մարդուն ընդհատելը։

SAST գործիքները կարող են գերազանց լինել այն գործում, որի համար նախատեսված են՝ ապահով կոդավորման ստանդարտների կիրառման մեջ, պարզ «աղբյուրից ընդունիչ» խնդիրների հայտնաբերման մեջ և հայտնի օրինաչափությունների մասշտաբային հայտնաբերման մեջ՝ կանխատեսելի փոխզիջումներով։ Դրանք կարող են լինել խորքային պաշտպանության ուժեղ մաս։

Այս գրառումն ավելի սահմանափակ է. այն վերաբերում է նրան, թե ինչու վարքագծի վերաբերյալ հիմնավորելու և արդյունքները վավերացնելու համար նախագծված ագենտը չպետք է իր աշխատանքը սկսի՝ հիմնվելով անփոփոխ արդյունքների ցուցակի վրա։

Արժե նաև ընդգծել մաքուր «աղբյուրից ընդունիչ» մտածողության հետ կապված մի սահմանափակում․ ոչ բոլոր խոցելիություններն են տվյալների հոսքի խնդիր։ Շատ իրական խափանումներ վիճակի և անփոփոխելիի խնդիրներ են՝ աշխատանքային հոսքի շրջանցումներ, լիազորման բացեր և «համակարգը սխալ վիճակում է» տեսակի սխալներ։ Այս տեսակի սխալների դեպքում աղտոտված արժեքը չի հասնում որևէ մեկ «վտանգավոր ընդունիչի»։ Ռիսկը կայանում է նրանում, թե ինչն է ծրագիրն ենթադրում, որ միշտ ճշմարիտ կլինի։ 

Մենք ակնկալում ենք, որ անվտանգության գործիքակազմի էկոհամակարգը կշարունակի բարելավվել. ստատիկ վերլուծությունը, ֆազզինգը, գործարկման ժամանակի պաշտպանիչ մեխանիզմները և գործակալական աշխատանքային հոսքերը բոլորը կունենան իրենց դերերը։

Մենք ուզում ենք, որ Codex Անվտանգությունը լավագույնը լինի անվտանգության թիմերի համար ամենաթանկարժեք փուլում՝ «սա կասկածելի է թվում»-ը վերածել «սա իրական խնդիր է, ահա ինչպես է այն խափանվում, և ահա համակարգի նպատակին համապատասխանող շտկումը»։ 

Եթե ցանկանում եք ավելին իմանալ այն մասին, թե ինչպես է Codex Անվտանգությունը սկանավորում պահոցները, վավերացնում արդյունքները և առաջարկում շտկումներ, տեսեք մեր փաստաթղթերում⁠(բացվում է նոր պատուհանում)։