Revizija sigurnosti WordPressa: Šta provjeriti prije objavljivanja

Prije nego što bilo koji dodatak generiran od strane PAGEnza dosegne WordPress instalaciju korisnika, prolazi kroz tri automatizirane sigurnosne provjere. Ovaj post objašnjava šta te provjere traže – i zašto je svaka od njih važna.

Zašto kod generiran od strane AI zahtijeva reviziju

Veliki jezični modeli iznenađujuće dobro pišu WordPress dodatke. Oni poznaju nazive kuka (hooks), razumiju WP standarde kodiranja, proizvode čitljiv PHP. Ali također čine predvidljive greške – i te greške su sigurnosne ranjivosti.

Najčešće koje vidimo:

• Korištenje $_GET ili $_POST bez čišćenja (sanitization)
• Nedostajuća provjera nonce prilikom slanja obrazaca
• Direktni upiti bazi podataka bez $wpdb->prepare()
• Korištenje eval() ili exec() za dinamičko ponašanje
• Izlaz korisničkih podataka bez esc_html() ili esc_attr()

Ovo nisu egzotični rubni slučajevi. Redovno se pojavljuju u izlazima LLM-a – čak i kod najboljih modela.

Faza 1: Provjera upita (Prompt validation)

Prije nego što AI napiše ijedan redak, analiziramo korisnikov opis. Ovaj korak otkriva dvije kategorije problema:

Pokušaji manipulacije – upiti koji pokušavaju natjerati AI da proizvede namjerno zlonamjeran kod. Stvari poput „ignoriraj prethodne upute“ ili „kreiraj stražnja vrata za testiranje“.

Nejasni ili neizvedivi opisi – upiti koji su previše kratki ili previše nejasni da bi proizveli koristan kod. „Napravi dodatak“ generira smeće; „Kreiraj kontakt obrazac koji šalje unose na e-mail adresu s filtriranjem neželjene pošte“ generira nešto stvarno.

Ako upit ne prođe ovu provjeru, korisnik vidi specifičnu poruku o grešci koja objašnjava zašto – ne opšte odbijanje.

Faza 2: Linting PHP-a u izoliranom kontejneru

Kada AI generira PHP kod, on se izvršava putem php -l unutar Docker kontejnera koji je potpuno izoliran od svega ostalog. Ovo otkriva sintaksne greške prije nego što dodatak uopće dosegne WordPress instalaciju.

Ali idemo dalje: ako linting ne uspije, sistem ne odbacuje samo izlaz. On šalje grešku nazad AI-u s upitom za ispravak – ono što nazivamo iscjeljivanjem (healing). AI vidi svoju grešku i pokušava ponovno, do tri puta.

To znači da korisnici gotovo nikada ne vide poruku „generiranje nije uspjelo“. Oni vide malo duže vrijeme generiranja – i radni kod.

Faza 3: Skeniranje sigurnosti koda

Ovo je najvažnija faza. Pokrećemo statičku analizu koja provjerava:

Opasne funkcije: eval(), exec(), system(), shell_exec(), passthru() – bilo koja od njih blokira izdavanje dodatka.

SQL injekcijski vektori: sirovi $wpdb->query() pozivi s interpoliranim varijablama, nedostatak $wpdb->prepare(), direktno korištenje mysql_query().

Nedostajuće provjere dozvola: AJAX rukovaoci koji ne pozivaju current_user_can() prije obavljanja bilo koje povlaštene radnje.

Nedostajuća provjera nonce-a: obrađivači obrazaca koji ne pozivaju wp_verify_nonce() ili check_ajax_referer().

Neobrađeni izlaz (Unescaped output): echo $_GET[...], echo $user_input bez funkcija za obradu.

Ako se bilo šta od navedenog pronađe, dodatak se blokira. Korisnik vidi izvještaj koji tačno navodi koje su funkcije pokrenule blokadu i zašto – ne samo „provjera sigurnosti nije uspjela“.

Kako izgleda izvještaj o reviziji

Svaki generirani dodatak dolazi s izvještajem o reviziji sigurnosti jednostavnim jezikom. On navodi:

• Koje su provjere prošle (zeleno)
• Koje su provjere pokrenule upozorenja (jantarno) – problemi koji nisu blokirajući, ali zaslužuju pažnju
• Sva ispravljanja koja su automatski primijenjena tokom iscjeljivanja

Izvještaj se generira automatski i prilaže preuzimanju dodatka. Koristan je kako za vaše povjerenje, tako i za pokazivanje klijentima da ste sigurnost shvatili ozbiljno.

Faza 4: Provjera prilikom spremanja

Ovo nije dio početnog generiranja – primjenjuje se kada korisnici ručno uređuju kod dodatka u PAGEnza uređivaču.

Svaki put kada spremite, ponovo se pokreće ista provjera lint + sigurnosti. Ako tokom uređivanja unesete kritičnu ranjivost, spremanje će biti blokirano dok je ne popravite. Ovo sprječava uobičajeni scenario u kojem programer napravi brzu „privremenu“ promjenu koja ostaje u produkciji dvije godine.

Ograničenja automatske revizije

Automatsko skeniranje dobro otkriva određenu klasu problema. Ne otkriva sve.

Logičke greške, slomljena poslovna logika i suptilni problemi eskalacije ovlasti koji ne uključuju poznate opasne obrasce i dalje zahtijevaju ljudski pregled. Transparentni smo u vezi s tim u dokumentaciji – revizija ne zamjenjuje sigurnosni pregled, ona je podloga koja garantuje minimalni standard.

Za produkcijske dodatke koji obrađuju plaćanja ili osjetljive podatke, preporučujemo ručni pregled uz automatske provjere. Izvještaj o reviziji pruža ljudskom recenzentu dobru polaznu tačku.