Pe scurt: Un code review de securitate pentru PHP este citirea țintită a codului sursă cu o întrebare: unde pot introducerile din exterior să facă ceva ce nu au voie? Se dovedesc utile două forme, un review al fiecărei modificări și un review de bază al întregului proiect, susținute de analiza statică cu PHPStan sau Psalm. Vulnerabilitățile din interpretorul PHP, precum PHP2Shell, nu le găsește un review, dar le găsește pe cele multe erori care apar în codul propriu.
De ce să priviți tocmai acum în codul propriu?
În ultima săptămână din octombrie 2026, PHP2Shell i-a ocupat mai ales pe administratori. Patch, repornire, dovadă: munca s-a aflat pe server. Pentru echipele de dezvoltare rămâne după aceea o întrebare incomodă. Dacă un atacator poate executa cod printr-o altă vulnerabilitate, ce găsește în aplicația noastră? Și câte dintre aceste vulnerabilități le-am scris noi înșine?
OWASP Top 10 arată de ani că majoritatea vulnerabilităților din aplicațiile web nu sunt exotice. Controlul de acces lipsă, injection și configurarea nesigură se află sus. Acestea sunt erori pe care o privire exersată le găsește în codul sursă, cu mult înainte ca un atacator să le încerce.
La aceasta se adaugă un motiv practic. Multe companii își verifică, își patch-uiesc și își întăresc oricum serverele chiar acum. Cine privește aplicația proprie în aceeași trecere închide golul dintre operare și dezvoltare. Un server întărit cu o aplicație vulnerabilă rămâne atacabil, iar o aplicație scrisă curat pe un PHP nepatch-uit la fel.
Review de bază sau review al modificărilor?
Cheat Sheet-ul OWASP privind Secure Code Review distinge două tipuri, care se completează în practică:
| Tip | Când | Amploare | Scop |
|---|---|---|---|
| Review de bază (baseline) | Proiect nou, release mare, după un incident | Întregul proiect, ponderat după risc | Inventarierea vulnerabilităților existente |
| Review al modificărilor (diff) | Fiecare pull request | Doar codul modificat | Prevenirea erorilor noi |
Un review de bază după un incident este deosebit de valoros. Cine tocmai a curățat un server ar trebui să știe dacă aplicația oferă alte puncte de intrare. Review-ul modificărilor menține starea curată după aceea, deoarece fiecare modificare este citită înainte de integrare și din perspectiva securității.
Code review în PHP: unde se acumulează erorile de securitate
În proiectele PHP merită o privire țintită asupra anumitor funcții și tipare. Ele nu sunt interzise, dar fiecare apariție merită întrebarea dacă pot ajunge în ele date străine.
| Tipar în cod | Risc posibil | Aprofundare |
|---|---|---|
| SQL prin concatenare de șiruri cu variabile | SQL injection | Prevenirea SQL injection în PHP |
unserialize() pe date din exterior |
Injecție de obiecte | Deserializarea nesigură în PHP |
include sau require cu cale variabilă |
Includerea de fișiere străine | Prevenirea Local și Remote File Inclusion |
exec(), system(), shell_exec(), proc_open() |
Execuție de comenzi | Command Injection |
Ieșire fără htmlspecialchars() |
Cross-Site Scripting | Escaping adecvat contextului |
== la token-uri sau hash-uri |
Conversia de tip ocolește verificările | hash_equals(), comparații stricte |
eval(), extract() pe intrări |
Injecție de cod sau de variabile | De cele mai multe ori se elimină fără înlocuire |
O primă privire de ansamblu rapidă reușește cu o căutare simplă. Nu înlocuiește un review, dar arată de unde ar trebui început:
# Apariții ale funcțiilor riscante în codul propriu (vendor exclus)
grep -rnE "\b(unserialize|eval|extract|shell_exec|exec|system|passthru|proc_open)\s*\(" src/ app/ 2>/dev/null
La fel de important este ce lipsește din cod. Verifică fiecare controller dacă utilizatorul autentificat are voie să vadă sau să modifice exact această înregistrare? Sunt upload-urile limitate ca tip și loc de depunere? Asemenea vulnerabilități nu le găsește nicio căutare după nume de funcții, ci doar citirea fluxului.
Instrumente care susțin review-ul
Analiza statică verifică codul fără a-l executa. PHPStan și Psalm găsesc erori de tip, cod inaccesibil și presupuneri greșite despre valorile returnate. Psalm oferă în plus o analiză taint, care urmărește dacă datele din cereri ajung nevalidate în locuri critice. Ambele pot fi înăsprite treptat, astfel încât și proiectele mai vechi pot începe. O privire de ansamblu oferă Analiza statică: PHPStan și Psalm.
# Analiză statică în proiect, creșteți treptat nivelul
vendor/bin/phpstan analyse src --level=5
# Analiză taint cu Psalm
vendor/bin/psalm --taint-analysis
Instrumentele oferă indicii, nu verdicte. Fiecare rezultat are nevoie de o evaluare, iar un raport gol nu înseamnă că aplicația este sigură.
La fel de important ca găsirea este consemnarea. Fiecare constatare ar trebui înregistrată cu locul, o scurtă descriere, evaluarea riscului, remedierea recomandată și starea, cel mai bine direct în sistemul de tickete al echipei. Astfel se poate urmări ce a fost remediat, ce a fost acceptat în mod deliberat și ce este încă deschis. După remediere merită o a doua privire: a fost eliminată cauza sau doar un simptom? Apare același tipar și în alte locuri din cod? O eroare făcută o dată se află, potrivit experienței, rareori într-un singur loc.
O listă de verificare pentru echipa dumneavoastră
Pentru review-urile modificărilor s-a dovedit utilă o listă scurtă, fixă. Ea aparține în șablonul pentru pull request-uri:
- De unde provin toate datele pe care le procesează această modificare și sunt verificate pe server?
- Sunt interogările de bază de date construite exclusiv cu substituenți?
- Este fiecare ieșire protejată (escaped) pentru contextul ei, adică HTML, atribut, JavaScript sau URL?
- Verifică codul autorizarea pentru exact acest obiect, nu doar autentificarea?
- Ajung parole, token-uri sau date cu caracter personal în jurnale sau în mesaje de eroare?
- Se află secrete în cod sau în fișiere versionate?
- Au fost adăugate dependențe noi și sunt ele întreținute?
Lăsați părțile critice pentru securitate, precum autentificarea, administrarea drepturilor, fluxurile de plată și upload-urile, să fie citite întotdeauna de o a doua persoană care nu a participat la cod. Privirea străină găsește presupuneri pe care autorul le consideră de la sine înțelese.
Cum ajută PHP SOS concret?
- Realizăm împreună cu parteneri specializați un review de bază al aplicației dumneavoastră PHP, ponderat după părțile cu cel mai mare risc.
- Configurăm PHPStan sau Psalm potrivit stadiului proiectului dumneavoastră și redactăm lista de verificare pentru pull request-urile dumneavoastră.
- Legăm review-ul de o privire asupra serverului și configurării, deoarece multe vulnerabilități apar abia din interacțiune.
- Acolo unde se dorește o verificare din exterior, completăm review-ul cu audit de securitate și test de penetrare.
Concluzie: Un code review este cel mai ieftin loc pentru remedierea erorilor de securitate, și anume înainte ca ele să fie livrate. Cine verifică fiecare modificare cu o listă scurtă și parcurge ocazional complet proiectul reduce durabil suprafața de atac.
Întrebări frecvente
Care este diferența dintre code review și testul de penetrare?
Un code review citește codul sursă și găsește erori înainte ca acestea să fie livrate. Un test de penetrare atacă din exterior aplicația aflată în funcțiune. Ambele se completează: review-ul găsește cauzele, testul arată ce este efectiv exploatabil.
Găsește un code review vulnerabilități precum PHP2Shell?
Nu. PHP2Shell se află în interpretorul PHP, nu în codul aplicației. Împotriva ei ajută doar o actualizare PHP cu repornire. Un review găsește erori din codul propriu, de exemplu injection, verificări de autorizare lipsă sau deserializare nesigură.
Sunt suficiente PHPStan sau Psalm pentru un review de securitate?
Sunt o bază bună și găsesc automat multe erori. Erorile de logică, verificările de autorizare lipsă și presupunerile greșite despre fluxuri le recunoaște însă doar un om care știe ce trebuie să facă aplicația.
Cât durează un code review de securitate?
Depinde de amploare. Un review al fiecărei modificări din pull request costă puțin timp. Un review complet al unui proiect crescut în timp este un proiect separat, care se limitează, în funcție de risc, la părțile cele mai importante.