GitHub 10. jūlijā izlaida CodeQL 2.26.0 ar jaunu drošības vaicājumu js/system-prompt-injection — tas JavaScript un TypeScript kodā izseko ceļu, pa kuru neuzticams lietotāja ievades teksts var nonākt AI modeļa sistēmas uzvednes parametrā. Versija automātiski izvietota GitHub.com koda skenēšanā bez repozitorija konfigurācijas izmaiņām.
Uzbrukums ir strukturāli tāds pats kā SQL injekcija: izstrādātājs savieno fiksētu instrukciju ar lietotāja ievadi vienā virknē un nosūta to modeļa system laukā. Uzbrucējs, kontrolējot šo ievadi, var pārrakstīt instrukcijas, apiet drošības ierobežojumus vai iznest konfidenciālu kontekstu. Cloud Security Alliance 2026. gada jūnija pārskatā dokumentēts incidents no februāra, kurā caur vienu speciāli sagatavotu GitHub problēmziņu bija ietekmēts npm pakotnes izplatīšanas cauruļvads. Tajā pašā pētījumā “Comment and Control” parādīja, ka Claude Code, Gemini CLI un GitHub Copilot Agent nespēja sanitizēt pull request virsrakstus pirms nodošanas modelim — Aikido Security identificēja vismaz piecas Fortune 500 kompānijas ar šādu konfigurāciju.
Ko tieši pārbauda jaunais vaicājums
js/system-prompt-injection izmanto taint tracking — CodeQL metodi, ar kuru neuzticami ievades dati tiek marķēti un izsekoti caur funkciju izsaukumiem — lai atrastu visus ceļus līdz AI SDK sistēmas uzvednes parametriem, pat ja ievade tiek nodota caur vairākām starplīmeņa funkcijām. CodeQL 2.26.0 paplašina aptveramās sink vietas ar jauniem API punktiem:
- OpenAI: Sora uzvednes un Realtime sesijas instrukcijas
- Anthropic:
systemlauks legacycompletionAPI izsaukumos - Google GenAI: kešotais saturs un sistēmas instrukcijas
Pamata openai.chat.completions un Anthropic messages API sink bija pieejami jau iepriekšējās versijās. Šoreiz pievienotie punkti aptver SDK funkcijas, ko izmanto ražošanas lietotnēs — Realtime sesijas videokonferenču botos, Sora videoprodukcijas cauruļvados, Google GenAI kešota konteksta mehānismā.
Vaicājums nav statisks saraksts ar zināmiem izsaukumiem — tas analizē kodu datu plūsmas ziņā, tāpēc atrod ievainojamības arī gadījumos, kad ievades dati nonāk sistēmas uzvednē caur palīgfunkcijām vai moduļu robežām. Ja lietotāja pieprasījuma teksts tiek nodots utilītfunkcijai, kas to apvieno ar sistēmas instrukciju un atgriež gatavu modeļa parametru, CodeQL šādu ceļu izsekos.
Pārējie jauninājumi versijā 2.26.0
C# analīze tagad izseko datus no Razor Page apstrādātāju metodēm (OnGet, OnPost, OnPostAsync). Tas ļauj SQL injekcijas un XSS vaicājumiem atrast ievainojamības ASP.NET Core Razor Pages lietotnēs, kur iepriekš datu plūsmas analīze apstājās pie lapu modeļa robežas. Go analīze saņēma atbalstu standarta bibliotēkas log/slog pakotnei, kas parādījās Go 1.21. Kotlin analīze paplašināta līdz 2.4.0. Divi Swift kriptogrāfijas vaicājumi — weak-sensitive-data-hashing un weak-password-hashing — saņēma pilnīgāku CryptoKit modelēšanu ar mazāk viltus pozitīviem atradumiem.
Kā jauninājums nonāk pie izstrādātājiem
Katrs jauns CodeQL izlaidums nonāk GitHub.com koda skenēšanā automātiski. Vaicājums iekļauts noklusējuma “code-scanning” komplektā, nevis tikai eksperimentālajā kolekcijā, tāpēc JavaScript un TypeScript repozitoriji ar aktīvu GitHub Advanced Security saņems šo pārbaudi nākamajā skenēšanas ciklā bez izmaiņām darba plūsmā. GitHub Enterprise Server nākamā versija iekļaus CodeQL 2.26.0, taču tas parasti aizņem vairākas nedēļas pēc publiskās versijas.
Kāpēc statiskajai analīzei tas padodas
Dinamiskā pārbaude AI API izsaukumiem ir grūta, jo modeļu atbildes ir nedeterminētas un manuāli pārbaudīt katru koda ceļu nav iespējams. Statiskā analīze izseko datu ceļu kompilācijas laikā — to interesē tikai, vai neuzticami dati bez apstrādes var nonākt jutīgā parametrā. OWASP ieskaita šo klasi kā LLM01 — augstāko apdraudējumu LLM lietotnēs. SQL injekcija tika meklēta ar statiskas analīzes metodēm gadiem pirms tā kļuva par OWASP Web Top 10 augšgala ierakstu; sistēmas uzvednes injekcija šo ciklu atkārto.
Sistēmas uzvednes injekcija strukturāli neatšķiras no SQL injekcijas: lietotāja kontrolēts teksts nonāk vietā, kur tam jābūt tikai izstrādātāja kontrolētam.
Kā labot atrasto ievainojamību
Izplatītākais problēmu radošais koda paraugs izskatās šādi: system: `Tu esi asistents. Lietotājs vaicā: ${userInput}` — sistēmas instrukcija un lietotāja teksts apvienoti vienā template virknē. Tieši šo struktūru CodeQL vaicājums meklē un atzīmē.
Labojums ir viens: nodot lietotāja ievadi un sistēmas instrukciju SDK kā atsevišķus parametrus. OpenAI messages masīvā lietotāja teksts nonāk dedikētajā user ierakstā. Anthropic messages.create gadījumā sistēmas instrukcija iet system parametrā, lietotāja vēstījums — messages masīvā. SDK iepakojums nodrošina, ka lietotāja saturs nekad netiek interpretēts kā sistēmas instrukcija neatkarīgi no tajā iekļautā teksta.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.