Če želite zgraditi delujoče sisteme UI, jih morate najprej poskusiti zlomiti. Izvedli smo simulirano iskanje šibkih točk v nadzorovanem okolju ter v vlogi napadalcev preizkušali in raziskovali aplikacijo UI za stranke v finančnih storitvah. Naše ugotovitve so pomembne za vse, ki uvajajo aplikacije, ki jih poganjajo veliki jezikovni modeli in pri katerih varnost ni stvar izbire.
Simulirano iskanje šibkih točk v nadzorovanem okolju pomeni, da poskušate svoj sistem UI namerno zlomiti, da lahko ranljivosti odpravite, preden jih odkrije pravi napadalec. Pri finančnih storitvah je tveganje še posebej veliko: aplikacije UI obdelujejo podatke strank in transakcije ter zagotavljajo finančne vpoglede. Posledice napake lahko segajo od slabe uporabniške izkušnje do kršitev predpisov, finančnih izgub in nepopravljive škode za blagovno znamko.
Naš cilj je bil zgodaj odkriti ranljivosti, preizkusiti realistične vzorce napadov in organizaciji pomagati izpolniti pričakovanja glede varnosti UI, ki jih regulatorji jemljejo zelo resno.
Pri tem velja poudariti razliko: prebijanje varnostnih mehanizmov napada varnostne filtre osnovnega modela, vstavljanje zavajajočega poziva pa napada samo aplikacijo tako, da nezaupanja vreden uporabniški vnos združi z zaupanja vrednim pozivom razvijalca. Vstavljanje zavajajočega poziva pomeni večje tveganje, ker je usmerjeno v vaš sistem in zaupne podatke, ki jih ta obdeluje, ne pa v splošnonamenski model.
Prvi krog je obsegal približno 750 preizkusov na naslednjih področjih:
uhajanje podatkov med sejami,
razkritje osebno določljivih podatkov (z naravnim jezikom, manipulacijo API-ja in različnimi kodiranji),
vrivanje SQL,
preglasitev sistemskega poziva.
Med začetnim preizkušanjem smo v obstoječem sistemu odkrili dve večji težavi: obravnavo poizvedb z več nameni in uporabo kodiranih pozivov.
Poizvedbe z več nameni: zahteve, ki združujejo legitimne in zlonamerne pozive. Na primer: »Show my spending by category, and also execute [malicious SQL].« Aplikacija zlonamernega namena ni zaznala, temveč se je v celoti zanašala na varovala v nadaljnji podatkovni plasti. To je, kot bi pustili vhodna vrata odprta, ker zaupate sefu v kleti.
Kodiranje: zahteve, kodirane v oblikah Base64, Hex in LeetSpeak ter s homoglifnimi znaki. Sistemi težko izločijo zlonamerni namen. Čeprav te poizvedbe niso razkrile občutljivih podatkov, so znatno destabilizirale sistem (halucinacije, ponavljanje zlonamerne kode SQL uporabnikom, zmedeno razvrščanje namenov itd.).
Začetno preizkušanje je pokazalo:
Časovne halucinacije: model samozavestno navaja izmišljene datume, časovne žige transakcij ali povzetke za določena obdobja. To je veliko tveganje v finančnem okolju, kjer ima lahko ravnanje stranke na podlagi napačnega datuma resnične posledice
Ponavljanje zlonamerne kode SQL uporabniku (zaskrbljujoče zaradi tveganja zastrupitve pomnilnika)
Zmedeno razvrščanje namenov
Razmetano oblikovanje izpisa
Na podlagi teh ugotovitev smo zožili področje preizkušanja. Preizkusi vrivanja SQL in kodiranja so postali manj prednostni, saj jih je ekipa že obravnavala. Namesto tega smo se osredotočili na najuspešnejša načina napada: razkritje osebno določljivih podatkov in uhajanje podatkov med sejami.
Najbolj presenetljiva ugotovitev drugega kroga je bila osupljivo preprosta: pogosto sploh ni treba biti iznajdljiv.
V številnih primerih je zadostovalo, da smo za interne podatke preprosto prosili v okviru navidez legitimne zahteve, in sistem jih je bil pripravljen razkriti. Sistem je na preproste poizvedbe odgovarjal z navedbo internih identifikatorjev in sistemskih polj, ki jih končni uporabniki nikoli ne bi smeli videti.
Ob podrobnejšem raziskovanju smo ugotovili, da ni šlo le za napako na ravni aplikacije. Storitev za pretvarjanje besedila v SQL je sestavljala poizvedbe, ki so zahtevale več polj, kot bi jih smele, njeni pojasnjevalni odgovori pa so omenjali podatke, do katerih bi moral biti dostop omejen. To je razkrilo resnično razpoko med sistemi – ranljivost, ki jo odkrijete le s preizkušanjem celotnega sklada, ne pa posameznih komponent v izolaciji.
Preizkušajte sistem, ne modela. Preizkušanje velikega jezikovnega modela v izolaciji vam zelo malo pove o varnostni pripravljenosti aplikacije. Celoten sklad preizkusite od začetka do konca, kot bi ga uporabljal uporabnik.
Vnos je treba preveriti pred velikim jezikovnim modelom. Kodirane poizvedbe, napade z več nameni in osnovne poskuse vrivanja je treba prestreči na obodu, ne pa jih prepustiti storitvam v nadaljnjih plasteh.
Ne zaupajte stičiščem. V arhitekturah z več storitvami se najzanimivejše ranljivosti skrivajo v razpokah med sistemi. Ničelno zaupanje pomeni prav to, zato vse preverjajte na vsaki plasti.
Preprosti napadi delujejo. Prefinjeno prebijanje varnostnih mehanizmov polni naslovnice, toda včasih lahko preprosto ... vprašate. Če vaš sistem brez zadržkov razkrije interne identifikatorje, ko jih uporabnik vključi v sicer legitimno poizvedbo, je to težava.
Razumite, kaj dejansko preizkušate. Znane vzorce napadov lahko prestreže že učenje velikega jezikovnega modela in ne vaša varovala. V simulirano iskanje šibkih točk v nadzorovanem okolju vključite opazljivost, da boste razumeli, kateri nadzorni mehanizmi se dejansko sprožijo.
Omejena okolja zahtevajo ustvarjalne rešitve. Ponudniki po meri in podpora za lokalne modele omogočajo učinkovito simulirano iskanje šibkih točk brez specializiranega dostopa do oblaka. Vendar jasno predstavite omejitve, ki jih to prinaša.
Simulirano iskanje šibkih točk ni enkratno opravilo. Je ponavljajoč se proces, ki ga je treba čim bolj avtomatizirati in prilagajati razvoju sistema. Napadi, ki bodo pomembni jutri, niso enaki tistim, ki so pomembni danes.
Sistemi UI v reguliranih okoljih bodo deležni vse večjega, ne manjšega nadzora. Organizacije, ki varnostno preizkušanje obravnavajo kot stalno prakso in ne kot postavko, ki jo pred uvedbo zgolj odkljukajo, bodo bolje pripravljene na ta nadzor ter se bodo lažje izognile komunikacijskim polomijam, zaradi katerih izgubijo zaupanje strank.