Revizija sigurnosti WordPressa: Što 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 što 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 pogreške — i te pogreš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
• Izravni 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. Redovito 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 hvata dvije kategorije problema:

Pokušaji manipulacije — upiti koji pokušavaju natjerati AI da proizvede namjerno zlonamjeran kod. Stvari poput "ignoriraj prethodne upute" ili "stvori 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; "Stvori kontaktni 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 pogrešci koja objašnjava zašto — ne opće odbijanje.

Faza 2: Linting PHP-a u izoliranom spremniku

Nakon što AI generira PHP kod, on se izvršava putem php -l unutar Docker spremnika koji je potpuno izoliran od svega ostalog. Ovo hvata sintaktičke pogreške prije nego što dodatak uopće dosegne WordPress instalaciju.

Ali idemo dalje: ako linting ne uspije, sustav ne odbacuje samo izlaz. On šalje grešku natrag AI-u s upitom za ispravak — ono što nazivamo iscjeljivanjem (healing). AI vidi svoju pogreš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(), izravno korištenje mysql_query().

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

Nedostajuća provjera nonce: 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 pronađe bilo što od navedenog, dodatak se blokira. Korisnik vidi izvješće koje točno navodi koje su funkcije pokrenule blokadu i zašto — ne samo "provjera sigurnosti nije uspjela“.

Kako izgleda izvješće o reviziji

Svaki generirani dodatak dolazi s izvješćem o reviziji sigurnosti jednostavnim jezikom. Navodi:

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

Izvješće se generira automatski i prilaže preuzimanju dodatka. Korisno 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, ponovno se pokreće ista provjera lint + sigurnosti. Ako tijekom uređivanja unesete kritičnu ranjivost, spremanje će biti blokirano dok je ne popravite. Ovo sprječava uobičajeni scenarij u kojem programer napravi brzu "privremenu" promjenu koja ostaje u produkciji dvije godine.

Ograničenja automatske revizije

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

Logičke pogreš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 nije zamjena za sigurnosni pregled, ona je podloga koja jamči minimalni standard.

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