Af hverju Codex Security inniheldur ekki SAST-skýrslu

Í áratugi hafa kyrrlegar prófanir á forritsöryggi (SAST) verið ein áhrifaríkasta leiðin fyrir öryggisteymi til að yfirfara kóða í stórum stíl. 

En þegar við byggðum Codex Security tókum við meðvitaða hönnunarákvörðun: við byrjuðum ekki á því að flytja inn skýrslu úr stöðugreiningu og biðja fulltrúann um að forgangsraða henni. Við hönnuðum kerfið til að byrja á geymslunni sjálfri—högun hennar, traustmörkum og fyrirhugaðri hegðun—og til að sannreyna það sem það finnur áður en það biður manneskju um að eyða tíma í það. 

Ástæðan er einföld: erfiðustu veikleikarnir eru oftast ekki tengdir vandamálum í gagnaflæði. Þetta gerist þegar kóði virðist framfylgja öryggisathugun, en sú athugun tryggir í raun ekki þann eiginleika sem kerfið treystir á. Með öðrum orðum, áskorunin er ekki bara að rekja hvernig gögn fara í gegnum forritið—heldur að ákvarða hvort varnirnar í kóðanum virka í raun.

SAST er oft sett fram sem hreint línuferli: greina uppsprettu óáreiðanlegs inntaks, rekja gögn í gegnum forritið og merkja tilvik þar sem þau gögn ná til viðkvæms viðtaka án hreinsunar. Þetta er glæsilegt líkan og það nær yfir marga raunverulega galla.

Í reynd þarf SAST að gera nálganir til að vera viðráðanlegt í stórum skala—sérstaklega í raunverulegum kóðagrunnum með óbeinum tilvísunum, kvikri útsendingu, endurkalli, speglun og rammaþungu stýriflæði. Þessar nálganir eru ekki árás á SAST; þær eru einfaldlega veruleikinn við að reyna að álykta um kóða án þess að keyra hann.

Þetta, út af fyrir sig, er ekki ástæðan fyrir því að Codex Security byrjar ekki á SAST-skýrslu.

Dýpra vandamálið er hvað gerist eftir að þú rekur uppsprettu í viðtaka.

Jafnvel þegar stöðugreining rekur inntak á réttan hátt í gegnum margar aðgerðir og lög, þarf hún samt að svara spurningunni sem í raun ræður því hvort veikleiki sé til staðar:

Skoðum algengt mynstur: kóði kallar á eitthvað eins og sanitize_html() áður en óáreiðanlegt efni er birt. Kyrrlegt kóðagreiningarforrit getur séð að hreinsarinn keyrði. Það sem það getur yfirleitt ekki ákvarðað er hvort þessi hreinsari sé í raun nægjanlegur fyrir tiltekið birtingarsamhengi, sniðmátavél, kóðunarhegðun og þær niðurstreymisumbreytingar sem eiga sér stað.

Þarna verða hlutirnir flóknir. Vandinn snýst ekki bara um það hvort gögn berist til viðtaka. Það snýst um hvort athuganirnar í kóðanum setji í raun skorður á gildið á þann hátt sem kerfið gerir ráð fyrir að þær geri.

Orðum þetta á annan hátt: það er mikill munur á „kóðinn kallar á hreinsun“ og „kerfið er öruggt.“

Hér er mynstur sem kemur oft fyrir í raunverulegum kerfum.

Vefforrit tekur við JSON-innihaldi, dregur út redirect_url, sannreynir það með reglulegri segð í leyfislista, afkóðar það og sendir niðurstöðuna áfram til endurbeiningarstjóra.

Klassísk skýrsla um uppruna og niðurstöðu getur lýst flæðinu:

óáreiðanlegt inntak → regex-athugun → URL-afkóðun → áframsending

En raunverulega spurningin er ekki hvort athugunin sé til. Það snýst um hvort sú athugun setji enn skorður á gildið eftir þær umbreytingar sem fylgja.

Ef regex-ið keyrir fyrir afkóðun, takmarkar það í raun afkóðuðu vefslóðina á þann hátt sem redirect-handlerinn túlkar það?

Að svara þessu krefst þess að rökstyðja um alla umbreytingarkeðjuna: hvað regex leyfir, hvernig afkóðun og stöðlun virka, hvernig vefslóðarþáttun meðhöndlar jaðartilvik og hvernig áframsendingarreglur leysa skemu og yfirvöld.

Margir þeirra veikleika sem skipta máli í reynd líta svona út: mistök í röð aðgerða, hlutbundin stöðlun, tvíræðni í þáttun og misræmi milli sannprófunar og túlkunar. Gagnaflæðið er sýnilegt. Veikleikinn liggur í því hvernig skorður berast—eða bregðast við að berast—í gegnum umbreytingarkeðjuna.

Þetta er ekki eingöngu fræðilegt mynstur. Í CVE-2024-29041⁠(opnast í nýjum glugga) varð Express fyrir framsendingargalla (open redirect) þar sem rangmótaðar slóðir gátu framhjá farið algengum útfærslum á leyfislista vegna þess hvernig framsendingarmarkmið voru kóðuð og túlkuð. Gagnaflæðið var einfalt. Erfiðari spurningin—og sú sem réði úrslitum um hvort villan væri til staðar—var hvort staðfestingin héldi enn eftir umbreytingarkeðjuna.

Codex Security er byggt á einföldu markmiði: að draga úr forgangsröðun með því að varpa ljósi á vandamál með sterkari sönnunargögnum. Í vörunni þýðir það að nota samhengi sem er sértækt fyrir geymsluna (þar á meðal ógnarlíkan) og staðfesta mikilvæg vandamál í einangruðu umhverfi áður en þau eru kynnt. 

Þegar Codex Security rekst á mörk sem líta út eins og „staðfesting“ eða „hreinsun“, þá lítur það ekki á það sem gátreit. Það reynir að skilja hvað kóðinn er að reyna að tryggja—og síðan reynir það að hrekja þá tryggingu.

Í reynd hefur þetta tilhneigingu til að líta út eins og blanda af:

• Að lesa viðeigandi kóðaleið með fullu samhengi geymslunnar, eins og öryggisrannsakandi myndi gera, og leita að misræmi milli ásetnings og útfærslu. Þetta felur í sér athugasemdir, en líkanið trúir ekki endilega athugasemdum svo að bæta við //Halvar segir: þetta er ekki villa fyrir ofan kóðann þinn ruglar það ekki, ef það er í raun villa.
• Að minnka vandamálið niður í minnsta prófanlega hluta (til dæmis umbreytingarferlið í kringum eitt inntak), svo þú getir rökstutt um það án þess að restin af kerfinu trufli. Í þessum skilningi dregur Codex Security út örsmáar kóðasneiðar og skrifar síðan ör-fuzzera fyrir þær.
• Rök um takmarkanir yfir umbreytingar, frekar en að meðhöndla hverja athugun sjálfstætt. Þegar við á getur þetta falið í sér framsetningu sem fullnægjandi spurningu. Með öðrum orðum veitum við líkaninu aðgang að Python-umhverfi með z3-solver og það er gott í að nota það þegar þörf er á, rétt eins og manneskja þyrfti að gera þegar hún svarar sérstaklega flóknu vandamáli um inntakstakmarkanir. Þetta er sérstaklega gagnlegt til að skoða heiltöluofhlaup eða svipaðar villur á óstöðluðum högunum.
• Keyra tilgátur í einangruðu sandkassaumhverfi til staðfestingar þegar mögulegt er, til að greina „þetta gæti verið vandamál“ frá „þetta er vandamál“. Það er engin betri sönnun en heildstæð boðunarvottun (PoC) þar sem kóðinn er þýddur í kembiforritastillingu. 

Þetta er lykilbreytingin: í stað þess að stoppa við „athugun er til staðar,“ ýtir kerfið í átt að „fastinn gildir (eða ekki), og hér eru sönnunargögnin“. Og líkanið velur besta verkfærið fyrir það verkefni.

Sanngjarnt viðbragð er: af hverju ekki að gera bæði? Byrjaðu á SAST-skýrslu, notaðu síðan fulltrúann til að rökstyðja dýpra.

Það eru tilvik þar sem forútreiknaðar niðurstöður eru gagnlegar — sérstaklega fyrir þrönga, þekkta flokka galla. En fyrir fulltrúa sem er hannaður til að uppgötva og staðfesta veikleika í samhengi, skapar það þrjá fyrirsjáanlega bilunarhama að byrja á SAST-skýrslu.

Í fyrsta lagi getur það hvatt til ótímabærrar þrengingar. Listi yfir niðurstöður er kort yfir hvar verkfæri hefur þegar verið notað. Ef þú notar þetta sem upphafspunkt geturðu skekkt kerfið í átt að því að eyða óhóflegri fyrirhöfn á sömu svæðum, nota sömu abstrakt hugmyndir og vantar þá flokka mála sem passa ekki við heimssýn verkfærisins.

Í öðru lagi getur það leitt til óbeinna dóma sem er erfitt að vinda ofan af. Margar SAST-niðurstöður fela í sér forsendur um hreinsun, staðfestingu eða traustmörk. Ef þessar forsendur eru rangar—eða bara ófullkomnar—getur það að mata þær inn í röklykkjuna fært fulltrúann frá „rannsaka“ yfir í „staðfesta eða afskrifa“, sem er ekki það sem við viljum að fulltrúinn geri.

Í þriðja lagi getur það gert erfiðara að meta rök kerfisins. Ef verkfærakeðjan byrjar á SAST-úttaki verður erfitt að aðgreina það sem fulltrúinn uppgötvaði með eigin greiningu frá því sem hann erfði frá öðru verkfæri. Sú aðgreining er mikilvæg ef þú vilt mæla getu kerfisins nákvæmlega, sem er nauðsynlegt til að kerfið geti batnað með tímanum.

Þess vegna byggðum við Codex Security til að byrja þar sem öryggisrannsóknir byrja: út frá kóðanum og tilgangi kerfisins, með sjálfvirkri staðfestingu til að hækka viðmið um vissu áður en við truflum manneskju.

SAST-verkfæri geta verið frábær í því sem þau eru hönnuð fyrir: að framfylgja öruggum kóðunarstöðlum, að greina einföld vandamál frá upphafi til enda og að bera kennsl á þekkt mynstur í stórum stíl með fyrirsjáanlegum málamiðlunum. Þau geta verið mikilvægur hluti af margþættri varnaraðferð.

Þessi færsla er þrengri: hún fjallar um hvers vegna fulltrúi sem er hannaður til að rökstyðja hegðun og staðfesta niðurstöður ætti ekki að hefja verk sitt með því að vera bundinn við fastan lista yfir niðurstöður.

Það er líka þess virði að benda á tengda takmörkun hreinnar uppspretta-til-viðtaka hugsunar: ekki er hver veikleiki vandamál í gagnaflæði. Margar raunverulegar bilanir eru vandamál tengd stöðu og óbreytileikum—framhjáhlaup í verkflæði, glufur í heimildum og „kerfið er í rangri stöðu“ villur. Fyrir svona tegundir galla nær mengað gildi ekki til eins einasta „hættulegs viðtaka.“ Áhættan felst í því sem forritið gerir ráð fyrir að muni alltaf vera satt. 

Við búumst við að vistkerfi öryggisverkfæra haldi áfram að þróast: stöðugreining, fuzzing, keyrsluvaktir og fulltrúamiðuð verkflæði munu öll gegna hlutverki.

Það sem við viljum að Codex Security sé sérstaklega gott í er sá hluti sem kostar öryggisteymi mest: að breyta „þetta lítur grunsamlegt út“ í „þetta er raunverulegt, svona bilar þetta, og hér er lagfæring sem samræmist tilgangi kerfisins.“ 

Ef þú vilt læra meira um hvernig Codex Security skannar geymslur, sannreynir niðurstöður og leggur til lagfæringar, skoðaðu skjölin okkar⁠(opnast í nýjum glugga).