Ce e o injecție: date tratate drept cod

O injecție se întâmplă într-o singură clipă: o bucată de text pe care ai crezut că e doar o dată, un nume, un mesaj, un parametru din adresă, ajunge să fie citită de sistem ca și cum ar fi o instrucțiune. Acesta e tot mecanismul. Restul cursului îți arată unde se întâmplă, de ce codul generat cu AI o face des și cum îl oprești, cu exemple de „înainte și după”.

Mecanismul, într-o singură idee

Aplicația ta amestecă, tot timpul, două lucruri diferite: instrucțiuni scrise de tine, adică ce trebuie făcut, și date venite din afară, adică ce a scris utilizatorul. O interogare spre baza de date e o instrucțiune. Numele pe care omul îl completează într-un formular e o dată. Cât timp cele două rămân separate, totul e în regulă.

Injecția apare exact în punctul în care datele și instrucțiunile se amestecă. Dacă lipești textul utilizatorului direct în mijlocul unei comenzi, sistemul nu are cum să știe unde se termină comanda ta și unde începe textul lui. Citește tot la un loc. Iar dacă în acel text există caractere cu înțeles special pentru sistem, ele nu mai sunt tratate ca litere, ci ca parte din comandă.

De ce e o familie, nu un singur atac

SQL e cazul cel mai cunoscut, dar același mecanism apare oriunde un text ajunge să fie interpretat. Un nume redat într-o pagină web, fără grijă, devine cod care rulează în browserul altcuiva, adică XSS. Un parametru lipit într-o comandă de sistem devine o a doua comandă. Un câmp trimis către o bază NoSQL devine un operator de căutare. Un text pus într-un șablon devine expresie evaluată de motorul de șabloane. Toate sunt aceeași greșeală, în contexte diferite: date lăsate să treacă drept cod.

De aceea le tratăm împreună. Odată ce înțelegi mecanismul, îl recunoști peste tot, iar apărarea are mereu aceeași formă: ține datele separate de comandă și, când chiar trebuie să le pui împreună, spune-i clar sistemului că bucata aceea e doar text.

De ce apare des în codul generat cu AI

Un model scrie codul cel mai scurt care rezolvă ce i-ai cerut. Când îi ceri „caută utilizatorul după nume”, cea mai directă variantă e să lipească numele în interogare. Merge, trece testul pe care îl ai în cap, arată curat. Pasul în plus, acela care ține numele separat de comandă, nu l-ai cerut, iar în codul din care a învățat modelul lipsește foarte des.

Cifrele confirmă tiparul. Veracode testează cod generat de peste 150 de modele pe sarcini cu risc de securitate cunoscut. În raportul din 2026, la sarcinile de tip cross-site scripting doar 15% din cod a trecut testul, iar concluzia lor a rămas memorabilă: „sintaxa e rezolvată, securitatea nu”. Un studiu separat, tot Veracode, a măsurat că un model are de 2,74 ori mai multe șanse să introducă un XSS decât un om care scrie același cod. Injecțiile nu sunt o teamă abstractă, sunt exact acolo unde codul generat greșește cel mai des.

Cum citești restul cursului

Mergem de la mecanism la reflexe. Întâi SQL, cu interogări parametrizate și cu binding-ul corect din ORM. Apoi XSS, cu escaping și cu ce te apără și ce nu te apără din framework. Pe urmă CSP, plasa care prinde ce a scăpat. La final, celelalte injecții, validarea de input și un capitol nou și important: ce faci cu ce îți răspunde un model de limbaj, pentru că și acela e text netrusted.

De reținut

• O injecție înseamnă că date venite din afară ajung să fie citite de sistem ca instrucțiune, nu ca text.
• E o familie întreagă: SQL, XSS, comenzi de sistem, NoSQL, șabloane. Același mecanism, contexte diferite.
• Codul generat cu AI o face des: în testele Veracode 2026 doar 15% din cod trecea la XSS, iar modelele au de 2,74 ori mai multe șanse să introducă un XSS.
• Apărarea are mereu aceeași formă: ține datele separate de comandă, iar când le pui împreună, spune-i sistemului că bucata aceea e doar text.