Kwa miongo kadhaa, upimaji wa usalama wa programu tuli (SAST) umekuwa mojawapo ya njia bora zaidi ambazo timu za usalama hutumia kuongeza uwezo wa ukaguzi wa msimbo.
Lakini tulipounda Usalama wa Codex, tulifanya chaguo la makusudi la muundo: hatukuanza kwa kuingiza ripoti ya uchanganuzi tuli na kumuomba wakala aiweke katika vipaumbele. Tuliubuni mfumo kuanza na uhifadhi wenyewe—usanifu wake, mipaka ya uaminifu, na tabia inayokusudiwa—na kuthibitisha kile inachopata kabla ya kumwomba binadamu kutumia muda wake juu yake.
Sababu ni rahisi: udhaifu mgumu zaidi kwa kawaida si matatizo ya mtiririko wa data. Hutokea wakati msimbo unaonekana kutekeleza ukaguzi wa usalama, lakini ukaguzi huo hauhakikishi kabisa sifa ambayo mfumo unategemea. Kwa maneno mengine, changamoto si kufuatilia tu jinsi data inavyopita kwenye programu—bali ni kubaini kama ulinzi katika msimbo unafanya kazi kweli.
SAST mara nyingi huwasilishwa kama mchakato msafi: tambua chanzo cha ingizo lisiloaminika, fuatilia data kupitia programu, na baini matukio ambapo data hiyo hufikia sehemu nyeti bila kusafishwa. Ni muundo wa kifahari, na unashughulikia hitilafu nyingi halisi.
Kihalisia, SAST hulazimika kufanya makadirio ili ibaki rahisi kushughulikia katika kiwango kikubwa—hasa katika misingi ya misimbo halisi yenye uelekezaji usio wa moja kwa moja, usambazaji unaobadilika, kazi-rejeshi (callbacks), utafakari (reflection), na mtiririko wa udhibiti unaotegemea sana mifumo-tumizi (frameworks). Makadirio hayo si lawama kwa SAST; ni uhalisia wa kujaribu kuichanganua misimbo bila kuitekeleza.
Hiyo, kivyake, si sababu kwa nini Usalama wa Codex haianzi na ripoti ya SAST.
Suala la kina zaidi ni nini hutokea baada ya kufanikiwa kufuatilia chanzo hadi hifadhi.
Hata wakati uchanganuzi tuli unafuatilia ingizo kwa usahihi katika kazi nyingi na tabaka nyingi, bado unapaswa kujibu swali ambalo kwa kweli huamua iwapo udhaifu upo:
Chukua muundo wa kawaida: msimbo huita kitu kama sanitize_html() kabla ya kutoa maudhui yasiyoaminika. Kichambuzi tuli kinaweza kuona kwamba kisafishaji kimetumika. Kile ambacho kwa kawaida hakiwezi kubaini ni iwapo kisafishaji hicho kinatosha kwa kweli kwa muktadha mahususi wa uwasilishaji, injini ya kiolezo, tabia ya usimbaji, na mabadiliko yanayohusika.
Hapo ndipo mambo yanapokuwa magumu. Tatizo si tu ikiwa data inafika kwenye lengo. Ni kuhusu ikiwa ukaguzi katika msimbo kwa kweli unaweka kikomo kwa thamani kwa njia ambayo mfumo unadhania hivyo.
Kwa maneno mengine: kuna tofauti kubwa kati ya “msimbo unatumia kisafishaji” na “mfumo ni salama.”
Huu hapa ni muundo unaojitokeza katika mifumo halisi kila wakati.
Programu ya wavuti hupokea mzigo wa JSON, hutoa redirect_url, huihalalisha dhidi ya allowlist regex, huifanyia usimbuaji wa URL, na kupitisha matokeo kwa kishughulikia uelekezaji upya.
Ripoti ya kawaida ya chanzo hadi hifadhi inaweza kuelezea mtiririko huu:
ingizo lisiloaminika → ukaguzi wa regex → usimbaji wa URL → elekeza kwingine
Lakini swali la kweli si kama ukaguzi upo. Ni kama ukaguzi huo bado unaweka kikomo kwenye thamani baada ya mabadiliko yanayofuata.
Ikiwa regex inaendeshwa kabla ya kusimbua, je, inaweka kikomo kwa URL iliyosimbuliwa kwa njia ambayo kishughulikia uelekezaji upya kinaifasiri kwa usahihi?
Kujibu hilo kunamaanisha kufikiria kuhusu msururu mzima wa mabadiliko: kile ambacho regex inaruhusu, jinsi uundaji wa msimbo na urekebishaji unavyofanya kazi, jinsi uchanganuzi wa URL unavyoshughulikia hali za pembezoni, na jinsi mantiki ya uelekezaji inavyotatua mipango na mamlaka.
Udhaifu mwingi muhimu katika utendaji huonekana hivi: makosa ya mpangilio wa shughuli, urekebishaji wa sehemu, uchanganuzi wa utata, na kutolingana kati ya uthibitishaji na tafsiri. Mtitiriko wa data unaonekana. Udhaifu uko katika jinsi vikwazo vinavyoenea—au kushindwa kueneza—kupitia msururu wa mabadiliko.
Huu sio tu muundo wa kinadharia. Katika CVE-2024-29041(fungua katika dirisha jipya), Express iliathiriwa na tatizo la uelekezaji huru ambapo URL zenye hitilafu zingeweza kukwepa utekelezaji wa orodha ya kawaida ya vibali kwa sababu ya jinsi malengo ya uelekezaji yalivyosimbwa na kisha kufasiriwa. Mtiririko wa data ulikuwa wa moja kwa moja. Swali gumu zaidi—na lile lililoamua ikiwa hitilafu hiyo ilikuwepo—lilikuwa ikiwa uthibitishaji bado uliendelea kushikilia baada ya msururu wa mabadiliko.
Usalama wa Codex umeundwa kwa lengo rahisi: kupunguza uchunguzi wa awali kwa kuonyesha masuala kwa ushahidi thabiti zaidi. Katika bidhaa, hiyo inamaanisha kutumia muktadha mahususi wa hifadhi (ikiwa ni pamoja na muundo wa vitisho) na kuthibitisha masuala yenye ishara kubwa katika mazingira yaliyotengwa kabla ya kuyaibua.
Wakati Usalama wa Codex unapokutana na mpaka unaoonekana kama "uthibitishaji" au "usafi," haiuchukulii hiyo kama kisanduku cha kuweka tiki. Hujaribu kuelewa kile ambacho msimbo unajaribu kudhamini—kisha hujaribu kukanusha dhamana hiyo.
Kwa vitendo, hiyo inaonekana kama mchanganyiko wa:
- Kusoma njia husika ya msimbo yenye muktadha kamili wa hifadhi, jinsi mtafiti wa usalama angefanya, na kutafuta tofauti kati ya nia na utekelezaji. Hii inajumuisha maoni, lakini muundo si lazima uamini maoni kwa hivyo kuongeza //Halvar inasema: hii si hitilafu juu ya msimbo wako hakuichanganyi, ikiwa kwa kweli kuna hitilafu.
- Kupunguza tatizo hadi sehemu ndogo zaidi inayoweza kujaribiwa (kwa mfano, mkondo wa mabadiliko unaozunguka ingizo moja), ili uweze kufikiria kuhusu hilo bila sehemu nyingine ya mfumo kuingilia. Kwa njia hii, Usalama wa Codex hutoa vipande vidogo vya msimbo na kisha huandika vifupisho vidogo kwa ajili yao.
- Uwazaji kuhusu vikwazo katika mabadiliko, badala ya kuchukulia kila ukaguzi kwa kujitegemea. Pale inapofaa, hii inaweza kujumuisha urasimishaji kama swali la uridhikishaji. Kwa maneno mengine, tunaipa muundo ufikiaji wa mazingira ya Python yenye z3-solver na ni bora katika kuitumia inapohitajika, kama vile binadamu angehitaji kufanya wakati wa kujibu tatizo la vikwazo vya ingizo lililo changamano sana. Hii ni muhimu sana kwa kuangalia idadi kamili ya vipengee au hitilafu zinazofanana kwenye usanifu usio wa kawaida.
- Kutekeleza dhana katika mazingira ya uthibitishaji yaliyotengwa inapowezekana, ili kutofautisha “hili linaweza kuwa tatizo” na “hili ni tatizo”. Hakuna uthibitisho bora kuliko PoC kamili kutoka mwanzo hadi mwisho yenye msimbo uliokusanywa katika hali ya urekebishaji wa hitilafu.
Hili ndilo badiliko muhimu: badala ya kusimama kwenye "ukaguzi upo," mfumo unasukuma kuelekea "kigezo kisichobadilika (au hakipo), na huu hapa ushahidi". Na muundo huchagua zana bora kwa kazi hiyo.
Mwitikio wa busara ni: kwa nini usifanye yote mawili? Anza na ripoti ya SAST, kisha tumia wakala kutafakari kwa kina zaidi.
Kuna visa ambapo matokeo yaliyohesabiwa mapema yanafaa—hasa kwa madarasa finyu ya hitilafu yanayojulikana. Lakini kwa wakala aliyeundwa kugundua na kuthibitisha udhaifu katika muktadha, kuanzia ripoti ya SAST huunda hali tatu za kushindwa zinazoweza kutabirika.
Kwanza, inaweza kuhimiza kupunguza mapema. Orodha ya matokeo ni ramani ya mahali ambapo zaba tayari iliangalia. Ikiwa utaichukulia kama sehemu ya kuanzia, unaweza kuielekeza mfumo kuelekea kutumia juhudi zisizo sawia katika maeneo yale yale, ukitumia dhahania zile zile, na kukosa aina za masuala ambayo hayalingani na mtazamo wa zana hiyo.
Pili, inaweza kuleta hukumu zisizo wazi ambazo ni vigumu kuzitatua. Matokeo mengi ya SAST huweka dhana kuhusu usafishaji, uthibitishaji, au mipaka ya uaminifu. Ikiwa dhana hizo si sahihi—au hazijakamilika—kuziingiza katika mzunguko wa hoja kunaweza kumhamisha mwakilishi kutoka "kuchunguza" hadi "kuthibitisha au kukataa," jambo ambalo silo tunalotaka mwakilishi afanye.
Tatu, inaweza kufanya iwe vigumu zaidi kutathmini mfumo wa uwazaji. Ikiwa uchakataji utaanza na matokeo ya SAST, inakuwa vigumu kutenganisha kile ambacho wakala aligundua kupitia uchambuzi wake mwenyewe na kile alichorithi kutoka kwa zana nyingine. Mgawanyiko huo ni muhimu ikiwa unataka kupima uwezo wa mfumo kwa usahihi, ambao unahitajika ili mfumo uboreshwe kadi muda unavyopita.
Kwa hivyo tuliunda Usalama wa Codex kuanzia pale utafiti wa usalama unapoanzia: kutoka kwenye msimbo na dhamira ya mfumo, huku uthibitishaji ukitumika kuinua kiwango cha uaminifu kabla hatujamkatiza binadamu.
Zana za SAST zinaweza kuwa bora katika kile kilichoundwa kwa ajili yake: kutekeleza viwango salama vya usimbaji, kubaini masuala ya moja kwa moja kutoka chanzo hadi kuzama, na kugundua mifumo inayojulikana kwa kiwango kikubwa kwa kubadilishana kunakoweza kutabirika. Zinaweza kuwa sehemu thabiti ya ulinzi wa kina.
Chapisho hili ni finyu zaidi: linahusu kwa nini wakala aliyebuniwa kufikiria kuhusu tabia na kuthibitisha matokeo hapaswi kuanza kazi yake akiwa amejikita kwenye orodha ya matokeo isiyobadilika.
Inafaa pia kutaja kizuizi kinachohusiana cha mawazo ya “chanzo hadi hifadhi” pekee: si kila udhaifu ni tatizo la mtiririko wa data. Kushindwa kwingi kwa kweli ni matatizo ya hali na yasiyobadilika—kukwepa taratibu za kazi, mapengo ya idhini, na hitilafu za "mfumo uko katika hali mbaya". Kwa aina hizi za hitilafu, thamani iliyochafuliwa haifikii “hifadhi hatari” moja. Hatari iko katika kile ambacho programu inadhania kuwa kitakuwa kweli daima.
Tunatarajia mfumo ikolojia wa zana za usalama kuendelea kuimarika: uchanganuzi tuli, uchakavu, walinzi wa muda wa utekelezaji, na taratibu za kazi za kiutendaji zote zitakuwa na majukumu.
Tunachotaka Usalama wa Codex uwe bora katika ni sehemu ambayo hugharimu zaidi kwa timu za usalama: kubadilisha “hii inaonekana ya kutiliwa shaka” kuwa “hii ni kweli, hivi ndivyo inavyoshindwa, na hapa kuna marekebisho yanayoendana na nia ya mfumo.”
Ikiwa ungependa kupata maelezo zaidi kuhusu jinsi Usalama wa Codex unavyochanganua uhifadhi, kuthibitisha matokeo, na kupendekeza marekebisho, tafadhali angalia hati zetu(fungua katika dirisha jipya).
