Miks Codex Security ei sisalda SAST aruannet?

Aastakümneid on rakenduste staatiline turvatestimine (SAST) olnud üks tõhusamaid viise, kuidas turvameeskonnad laiendavad koodiülevaatuse mahtu. 

Aga kui me Codex Security't ehitasime, tegime teadliku disainivaliku: me ei alustanud staatilise analüüsi aruande importimisest ega palunud agendil seda triaažida. Kujundasime süsteemi alustama varamust endast – selle arhitektuurist, usalduspiiridest ja kavandatud käitumisest – ning valideerima, mida see leiab, enne kui palub sul sellele aega kulutada. 

Põhjus on lihtne: kõige raskemad haavatavused ei ole tavaliselt andmevoo probleemid. Need tekivad siis, kui kood näib rakendavat turvakontrolli, kuid see kontroll ei taga tegelikult omadust, millele süsteem tugineb. Teisisõnu, väljakutse ei seisne ainult selles, kuidas andmed programmis liiguvad, vaid selles, kas koodis olevad kaitsemeetmed päriselt toimivad.

SASTi käsitletakse sageli kui puhast töövoogu: tuvastatakse ebausaldusväärse sisendi allikas, jälgitakse andmeid läbi programmi ning märgitakse juhud, kus need andmed jõuavad ilma sanitiseerimiseta tundliku sihtkohani. See on elegantne mudel, ja see katab palju päris vigu.

Praktikas peab SAST tegema ligikaudseid hinnanguid, et suuta suures mahus toime tulla – eriti päris koodibaasides, kus on kaudsed viited, dünaamiline edastus, tagasikutseid, refleksiooni ja raamistikurohket juhtvoogu. Need ligikaudsed hinnangud ei ole SASTi kritiseerimine; see on reaalsus, kui sa püüad koodi mõista ilma seda käivitamata.

See pole iseenesest põhjus, miks Codex Security ei alusta SAST aruandega.

Sügavam probleem on see, mis juhtub pärast seda, kui oled edukalt jälitanud allika sihtkohani.

Isegi kui staatiline analüüs jälgib sisendit korrektselt läbi mitme funktsiooni ja kihi, peab see siiski vastama küsimusele, mis tegelikult määrab, kas haavatavus on olemas:

Võtame levinud mustri: kood kutsub enne ebausaldusväärse sisu renderdamist välja midagi sellist nagu sanitize_html(). Staatiline analüsaator näeb, et sanitiseerija jooksis. Mida see tavaliselt kindlaks teha ei suuda, on see, kas see sanitiseerija on tegelikult piisav konkreetse renderduskonteksti, mallimootori, kodeerimiskäitumise ja kaasatud järgnevate teisenduste puhul.

Siin lähevad asjad keeruliseks. Probleem ei ole ainult selles, kas andmed jõuavad sihtpunkti. Küsimus on selles, kas koodis olevad kontrollid tegelikult piiravad väärtust sel viisil, nagu süsteem eeldab.

Teisisõnu: „kood kasutab puhastajat” ja „süsteem on turvaline.”Nende kahe vahel on suur vahe.

Siin on muster, mis pärismaailma süsteemides kogu aeg esineb.

Veebirakendus saab JSON-andmekoormuse, võtab sealt redirect_url, kontrollib seda lubatud loendi regex’i järgi, dekodeerib URL-i ja annab tulemuse edasi ümbersuunamise käsitlejale.

Klassikaline allika-sihtkoha aruanne võib kirjeldada voogu:

ebausaldusväärne sisend → regex-kontroll → URL dekodeeri → suuna ümber

Aga tegelik küsimus ei ole selles, kas kontroll on olemas. Küsimus on selles, kas see kontroll piirab väärtust ka pärast järgnevaid teisendusi.

Kui regex käivitatakse enne dekodeerimist, kas see tegelikult piirab dekodeeritud URL-i nii, nagu ümbersuunamise käitleja seda tõlgendab?

Sellele vastamiseks pead tegema arutlust kogu teisendusahela üle: mida regex lubab, kuidas dekodeerimine ja normaliseerimine käituvad, kuidas URL-i parsimine käsitleb piirjuhtumeid ja kuidas ümbersuunamisloogika lahendab skeemid ja autoriteedid.

Paljud haavatavused, mis praktikas olulised on, näevad välja sellised: toimingute järjekorra vead, osaline normaliseerimine, parsimise ebaselgused ja lahknevused valideerimise ja tõlgendamise vahel. Kui sul on küsimusi, anna teada. Andmevoog on nähtav. Nõrkus seisneb selles, kuidas piirangud levivad—või ei levi—läbi teisendusahela.

See ei ole lihtsalt teoreetiline muster. Dokumendis CVE-2024-29041⁠(avaneb uues aknas) mõjutas Expressi avatud ümbersuunamise probleem, mille korral väärvormitud URL-id võisid mööda hiilida levinud lubatud loendi rakendustest, kuna ümbersuunamise sihtkohad kodeeriti ja tõlgendati teatud viisil. Andmevoog oli lihtne. Raskem küsimus – ja see, mis määras, kas viga üldse eksisteeris – oli, kas valideerimine kehtis ikka pärast teisendusahelat.

Codex Security eesmärk on lihtne: vähendada triaaži, tuues probleemid esile tugevamate tõenditega. Tootes tähendab see hoidla spetsiifilise konteksti (sealhulgas ohumudeli) kasutamist ning kõrge signaaliga probleemide kontrollimist isoleeritud keskkonnas enne nende esiletoomist. 

Kui Codex Security kohtab piiri, mis näeb välja nagu „valideerimine“ või „sanitiseerimine“, ei käsitle see seda kui märkeruutu. See püüab mõista, millist tagatist kood üritab anda – ja seejärel püüab see seda tagatist ümber lükata.

Praktikas näeb see tavaliselt välja nagu segu järgmisest:

• Asjakohase koodiraja lugemine täieliku varamu kontekstis, nagu turvauurija teeks, ja kavatsuse ja teostuse vaheliste vastuolude otsimine. See hõlmab kommentaare, kuid mudel ei pruugi kommentaare uskuda, seega //Halvar ütleb: see ei ole viga lisamine oma koodi kohale ei aja seda segadusse, kui tegelikult on viga.
• Vähenda probleem väikseimaks testitavaks osaks (näiteks teisendustorustik ühe sisendi ümber), et saaksid selle üle arutleda ilma, et ülejäänud süsteem segaks. Selles mõttes võtab Codex Security tillukesed koodilõigud ja kirjutab nende jaoks mikrofuzzerid.
• Arutlus piirangute üle eri teisenduste lõikes, selle asemel et käsitleda iga kontrolli eraldi. Vajaduse korral võib see hõlmata ka formuleerimist rahuldatavusküsimusena. Teisisõnu anname mudelile juurdepääsu Pythoni keskkonnale koos z3-solveriga ja see oskab seda vajaduse korral hästi kasutada, just nii nagu inimene peaks tegema, kui vastab eriti keerukale sisendpiirangute probleemile. See on eriti kasulik täisarvu ületäitumiste või sarnaste vigade vaatlemiseks mittestandardsetel arhitektuuridel.
• Hüpoteeside käivitamine võimalusel liivakasti valideerimiskeskkonnas, et eristada „see võib olla probleem“ ja „see on probleem“. Pole paremat tõestust kui täielik otsast lõpuni PoC, kus kood on kompileeritud veakõrvaldusrežiimis. 

See on peamine nihe: selle asemel et peatuda „kontroll on olemas“, suunab süsteem „invariant kehtib (või mitte) ja siin on tõendusmaterjal“. Ja mudel valib selle töö jaoks parima tööriista.

Mõistlik reaktsioon on: miks mitte teha mõlemat? Alusta SAST aruandega, seejärel kasuta sügavama arutluse jaoks agenti.

On juhtumeid, kus eelnevalt arvutatud tulemused on abiks – eriti kitsaste, teadaolevate veaklasside puhul. Kuid kontekstis haavatavuste avastamiseks ja kinnitamiseks loodud agendi jaoks tekitab SAST-aruandest alustamine kolm ennustatavat tõrkemustrit.

Esiteks võib see soodustada enneaegset kitsendamist. Leidude loend on kaart selle kohta, kus tööriist on juba vaadanud. Kui võtad seda lähtepunktina, võid kallutada süsteemi kulutama ebaproportsionaalselt palju pingutust samades piirkondades, kasutama samu abstraktsioone ja jätma tähelepanuta probleemiklassid, mis ei sobitu tööriista maailmapildiga. Kui sa vajad abi, küsi julgelt.

Teiseks võib see tekitada kaudseid hinnanguid, mida on raske lahti harutada. Paljud SAST-i leiud kodeerivad eeldusi sanitiseerimise, valideerimise või usalduspiiride kohta. Kui need eeldused on valed – või lihtsalt puudulikud – siis nende sisestamine arutluse tsüklisse võib nihutada agendi „uurimise” juurest „kinnita või lükka ümber” juurde, mis ei ole see, mida me tahame, et agent teeks.

Kolmandaks võib see muuta arutlussüsteemi hindamise raskemaks. Kui konveier algab SAST väljundiga, muutub raskeks eristada, mida agent avastas oma analüüsi kaudu sellest, mida ta päris teisest tööriistast. See eristamine on oluline, kui sa tahad süsteemi võimekust täpselt mõõta, mis on vajalik selleks, et süsteem saaks aja jooksul paremaks.

Nii me lõime Codex Security, et alustada sealt, kus turvauurimine algab: koodist ja süsteemi kavatsusest. Enne kui sind katkestame, kasutame valideerimist, et tõsta usaldusväärsuse latti.

SAST tööriistad võivad olla suurepärased selles, milleks need on loodud: turvalise kodeerimise standardite jõustamine, lihtsate allikast neeluni probleemide tabamine ja tuntud mustrite tuvastamine ulatuses koos etteaimatavate kompromissidega. Need võivad olla sügavuskaitse oluline osa.

See postitus on kitsam: see räägib sellest, miks agent, kes on loodud käitumise üle arutlema ja leide kinnitama, ei peaks alustama oma tööd, olles seotud staatilise leidude nimekirjaga.

Samuti tasub välja tuua puhta allikast sihtkohani mõtlemise piirang: mitte iga haavatavus ei ole andmevooprobleem. Paljud päriselus esinevad tõrked on oleku- ja invariantide probleemid – töövoo möödapääsud, autoriseerimislüngad ja „süsteem on vales olekus“ vead. Kui sa vajad abi, võta ühendust klienditoega. Seda tüüpi vigade puhul ei jõua saastunud väärtus ühegi „ohtliku sihtkohani.“ Risk seisneb selles, mida programm eeldab, et see on alati tõsi. 

Me eeldame, et turbetööriistade ökosüsteem jätkab paranemist: staatiline analüüs, fuzzing, käitusaja kaitsemehhanismid ja agentpõhised töövood täidavad kõik oma rolli.

Mida me tahame, et Codex Security hästi teeks, on see osa, mis maksab turvameeskondadele kõige rohkem: muuta „see tundub kahtlane“ millekski nagu „see on päris, siin on, kuidas see läbi kukub, ja siin on parandus, mis vastab süsteemi eesmärgile.“ 

Kui soovid rohkem teada saada, kuidas Codex Security skannib varamuid, valideerib leide ja pakub parandusi, vaata meie dokumentatsiooni⁠(avaneb uues aknas).