Miért nem tartalmaz a Codex Security SAST-jelentést

Évtizedek óta a statikus alkalmazásbiztonsági tesztelés (SAST) az egyik leghatékonyabb módja annak, hogy a biztonsági csapatok nagy léptékben végezzék a kódellenőrzést. 

De amikor megépítettük a Codex Securityt, tudatos tervezési döntést hoztunk: nem statikus elemzési jelentés importálásval és az ügynök triázsra elvégzésére való megkérésével kezdük. Úgy terveztük a rendszert, hogy magával az adattárral kezdjen—annak architektúrájával, bizalmi határaival és tervezett működésével —, és hogy validálja, amit talál, mielőtt arra kérne egy embert, hogy időt szánjon rá. 

Az ok egyszerű: a legnehezebb sebezhetőségek általában nem adatfolyam-problémák. Akkor fordulnak elő, amikor a kód látszólag egy biztonsági ellenőrzést hajt végre, de ez az ellenőrzés valójában nem garantálja azt a tulajdonságot, amelyre a rendszer támaszkodik. Más szóval, a kihívás nem csupán azt nyomon követni, hogyan mozognak az adatok egy programon keresztül—hanem azt meghatározni, hogy a kódban lévő védelmi intézkedések valóban működnek-e.

A SAST-et gyakran egy letisztult folyamatként írják le: azonosítani egy nem megbízható bemenet forrását, végigkövetni az adat útját a programban, majd jelezni azokat az eseteket, amikor ez az adat tisztítás (szanitizálás) nélkül jut el egy érzékeny végponthoz. Ez egy elegáns modell, amely sok valós hibát felfedez.

A gyakorlatban a SAST-nak közelítéseket kell alkalmaznia, hogy nagy léptékben is kezelhető maradjon—különösen a valós kódbázisokban, ahol közvetett hivatkozások, dinamikus diszpécselés, visszahívások, reflexió és keretrendszer-alapú vezérlésfolyam a jellemző. Ezek a közelítések nem a SAST kritikái; inkább annak a valóságát tükrözik, hogy kódot kell értelmezni anélkül, hogy ténylegesen végrehajtanánk.

Ám önmagában nem ez az oka annak, hogy a Codex Security nem egy SAST jelentéssel indul.

A mélyebb probléma az, hogy mi történik azután, hogy sikeresen nyomon követünk egy forrást egy végpontig.

Még ha a statikus elemzés helyesen követi is a bemenetet több függvényen és rétegen keresztül, akkor is meg kell válaszolnia azt a kérdést, amely valójában eldönti, hogy létezik-e sebezhetőség:

Vegyünk egy gyakori mintát: a kód valami olyat hív, mint a sanitize_html() a nem megbízható tartalom renderelése előtt. Egy statikus elemző képes észlelni, hogy a szanitizáló lefutott. Azt azonban általában nem tudja megállapítani, hogy ez a szanitizálás valóban elegendő-e az adott megjelenítési kontextushoz, sablonmotorhoz, kódolási viselkedéshez és a további feldolgozási lépésekhez.

És itt válik bonyolulttá a helyzet. A probléma nem csupán az, hogy az adat eljut-e egy végponthoz. Hanem az, hogy a kódban lévő ellenőrzések valóban úgy korlátozzák-e az értéket, ahogyan azt a rendszer feltételezi.

Másképp fogalmazva: óriási különbség van a „a kód behív egy szanitizáló rutint” és a „a rendszer biztonságos”között.

Íme egy minta, amely a valós rendszerekben gyakran előfordul.

Egy webalkalmazás fogad egy JSON-payloadot, kinyeri belőle a redirect_url mezőt, egy engedélyezési listát használó reguláris kifejezéssel ellenőrzi, majd URL-dekódolja, és az eredményt továbbadja egy átirányítás-kezelőnek.

Egy klasszikus forrás-végpont jelentés le tudja írni az adat útját:

nem megbízható bemenet → regex ellenőrzés → URL-dekódolás → átirányítás

De az igazi kérdés nem az, hogy létezik-e az ellenőrzés. Az a kérdés, hogy az ellenőrzés a további átalakítások után is korlátozza-e az értéket.

Hanem az, hogy ha a regex a dekódolás előtt fut le, akkor valóban úgy korlátozza-e a dekódolt URL-t, ahogyan azt az átirányítás-kezelő értelmezi.

Ennek megválaszolásához a teljes átalakítási láncot kell vizsgálni: mit enged meg a regex, hogyan működik a dekódolás és a normalizálás, hogyan kezeli az URL-parszolás a szélső eseteket, és hogyan oldja fel az átirányítási logika a sémákat és a hatóköröket.

A gyakorlatban sok fontos sebezhetőség pontosan így néz ki: műveleti sorrend hibák, részleges normalizálás, parszolási kétértelműségek, valamint az ellenőrzés és az értelmezés közötti eltérések. Az adatfolyam látható. A gyengeség abban rejlik, hogyan terjednek—vagy nem terjednek—tovább a megszorítások az átalakítási láncon keresztül.

Ez nem csupán egy elméleti minta. A(z) CVE-2024-29041⁠(új ablakban nyílik meg) esetében az Expresst egy nyílt átirányítási probléma érintette, amelynél a hibásan formázott URL-ek megkerülhették a szokásos engedélyezőlista-megvalósításokat, az átirányítási cél kódolásának és értelmezésének mikéntje miatt. Az adatfolyam egyszerű volt. A nehezebb kérdés—és az, amely eldöntötte, hogy a hiba létezett-e —az volt, hogy az ellenőrzés továbbra is fennállt-e az átalakítási lánc után.

A Codex Security egy egyszerű célra épül: a triázs csökkentésére azáltal, hogy erősebb bizonyítékokkal hozza felszínre a problémákat. A termékben ez a repo-specifikus kontextus (beleértve a fenyegetési modellt) használatát jelenti, valamint a nagy jelértékű problémák ellenőrzését egy elkülönített környezetben, mielőtt felszínre kerülnek. 

Amikor a Codex Security olyan határhoz ér, ami „validációnak” vagy „szanitizálásnak” tűnik, nem kezeli ezt egyszerű kipipálandó elemként. Megpróbálja megérteni, hogy a kód milyen garanciát próbál biztosítani—majd megkísérli ezt a garanciát megcáfolni.

A gyakorlatban ez így néz ki:

• Az adott kódrészlet elemzése a teljes repository kontextusában, ahogyan egy biztonsági kutató tenné, és az eltérések keresése a szándék és a megvalósítás között. Ez magában foglalja a kommenteket is, de a modell nem feltétlenül hisz nekik, tehát ha a kód fölé odaírod, hogy //Halvar szerint ez nem hiba, az nem fogja megtéveszteni, ha valójában mégis hiba van.
• A probléma leszűkítése a legkisebb tesztelhető részre (például egyetlen bemenet körüli transzformációs láncra), hogy azt a rendszer többi részének zavaró hatása nélkül lehessen elemezni. Ebben az értelemben a Codex Security kis kódrészleteket emel ki, majd ezekhez „mikro-fuzzereket” ír.
• A megszorítások elemzése az átalakítások teljes láncán keresztül, nem pedig az egyes ellenőrzések külön-külön kezelésével. Szükség esetén ez formalizálható kielégíthetőségi (satisfiability) problémaként is. Másképp megfogalmazva: a modell hozzáférést kap egy Python környezethez a z3-solverrel, és jól tudja használni, amikor szükséges – hasonlóan ahhoz, ahogy egy ember is tenné egy különösen összetett bemeneti feltételrendszer vizsgálatakor. Ez különösen hasznos például egész túlcsordulások vagy hasonló hibák elemzésénél nem szabványos architektúrákon.
• Amikor lehetséges, a hipotéziseket egy sandboxolt validációs környezetben futtatják, hogy meg lehessen különböztetni a „lehetséges probléma” és a „valódi probléma” állapotát. Nincs jobb bizonyíték, mint egy teljes end-to-end PoC a kóddal, debug módban fordítva. 

Ez a kulcsfontosságú váltás: ahelyett, hogy megállnánk annál, hogy „létezik egy ellenőrzés”, a rendszer az „invariáns fennáll (vagy nem), és itt a bizonyíték” irányába halad. A modell pedig kiválasztja az adott feladathoz legjobb eszközt.

Észszerű kérdés: miért ne lehetne mindkettőt megvalósítani? Kezdeni egy SAST-jelentéssel, majd az ügynököt mélyebb elemzésre használni.

Bizonyos esetekben a már előre kiszámított eredmények hasznosak lehetnek—különösen szűk, ismert hibakategóriák esetén. De egy ügynök, amelyet kontextusban történő sebezhetőség-felfedezésre és validálásra terveztek, SAST-jelentésből kiindulva három előre látható hibamódot hozhat létre.

Először is, elősegítheti a túl korai szűkítést. A találati lista térképként szolgál arról, hogy az eszköz hol keresett már. Ha ezt tekinted kiindulópontnak, a rendszer hajlamos lehet túlzott erőforrást fordítani ugyanazon területekre, ugyanazokat az absztrakciókat használva, miközben kihagy olyan hibakategóriákat, amelyek nem illeszkednek az eszköz világképébe.

Másodszor, rejtett ítéleteket vezethet be, amelyeket nehéz visszafejteni. Sok SAST-eredmény kódol feltételezéseket a szanitizálásról, validációról vagy bizalmi határokról. Ha ezek a feltételezések tévesek vagy hiányosak, a rendszerbe táplálva a logikai láncot az ügynök „vizsgálódás” helyett „megerősítés vagy elvetés” módba kapcsolhat, amit nem szeretnénk az ügynöknél látni.

Harmadszor, megnehezítheti az érvelési rendszer értékelését. Ha a pipeline SAST-kimenettel indul, nehéz szétválasztani, hogy az ügynök saját elemzése milyen felfedezéseket hozott, és mi származik egy másik eszköztől. Ez a szétválasztás fontos, ha pontosan szeretnéd mérni a rendszer képességeit, ami mindenképp szükséges a rendszer folyamatos javításához.

Ezért létrehoztuk a Codex Security-t, hogy ott kezdjük, ahol a biztonsági kutatás kezdődik: a kódnál és a rendszer szándékánál, az ellenőrzést pedig használjuk arra, hogy növeljük a megbízhatóságot, mielőtt megszakítanánk egy ember munkáját.

A SAST-eszközök kiválóak lehetnek abban, amire tervezték őket: a biztonságos kódolási szabványok betartatásában, az egyszerű forrás-végpont problémák felderítésében, valamint ismert minták nagy léptékű, előre látható kompromisszumokkal történő azonosításában.. A többrétegű védelem fontos elemét képezhetik.

Ez a bejegyzés szűkebb területre fókuszál: arról szól, hogy miért nem szabad egy viselkedés elemzésére és megállapítások érvényesítésére tervezett ügynök munkáját egy statikus megállapításlistához kötve kezdeni.

Érdemes kiemelni a tisztán forrás-végpont szemléletmód egy kapcsolódó korlátját is: nem minden sebezhetőség adatfolyam-probléma. Sok valódi meghibásodás állapot- és invariánsprobléma—munkafolyamat-megkerülések, jogosultsági hiányosságok, valamint „a rendszer rossz állapotban van” típusú hibák. Az ilyen típusú hibáknál egy szennyezett érték nem jut el egyetlen „veszélyes végponthoz” sem. A kockázat abban rejlik, amit a program mindig igaznak feltételez. 

Arra számítunk, hogy a biztonsági eszközök ökoszisztémája tovább fejlődik: a statikus elemzésnek, a hibakeresésnek, a futásidejű védelmeknek és az ügynöki munkafolyamatoknak is fontos szerepe lesz.

Azt szeretnénk, ha a Codex Security abban lenne igazán jó, ami a legtöbbe kerül a biztonsági csapatoknak: az „ez gyanúsnak tűnik” állapotot átfordítani „ez valódi hiba, így bukik el, és itt egy javítás, ami megfelel a rendszer szándékának” szintre. 

Ha többet szeretnél megtudni arról, hogyan vizsgálja át a Codex Security az adattárakat, hogyan ellenőrzi a megállapításokat, és hogyan javasol javításokat, olvasd el a dokumentációnkat⁠(új ablakban nyílik meg).