Revizija varnosti WordPressa: Kaj preveriti pred objavo

Preden kateri koli vtičnik, ustvarjen s strani PAGEnza, doseže uporabnikovo namestitev WordPressa, gre skozi tri samodejne varnostne preglede. Ta objava pojasnjuje, kaj ti pregledi iščejo – in zakaj je vsak od njih pomemben.

Zakaj koda, ustvarjena z AI, potrebuje revizijo

Veliki jezikovni modeli so presenetljivo dobri pri pisanju vtičnikov za WordPress. Poznajo imena kljuk (hooks), razumejo standarde kodiranja WP, proizvajajo berljivo PHP. Vendar pa tudi delajo predvidljive napake – in te napake so varnostne ranljivosti.

Najpogostejše, ki jih vidimo:

• Uporaba $_GET ali $_POST brez čiščenja (sanitization)
• Manjkajoče preverjanje nonce pri pošiljanju obrazcev
• Neposredna poizvedba v bazo podatkov brez $wpdb->prepare()
• Uporaba eval() ali exec() za dinamično vedenje
• Izhod uporabniških podatkov brez esc_html() ali esc_attr()

To niso eksotični skrajni primeri. Redno se pojavljajo v izhodu LLM – celo pri najboljših modelih.

Faza 1: Preverjanje poziva (Prompt validation)

Preden AI napiše eno vrstico, analiziramo opis uporabnika. Ta korak zazna dve kategoriji težav:

Poskusi manipulacije – pozivi, ki poskušajo prisiliti AI, da ustvari namerno zlonamerno kodo. Stvari, kot so „ne upoštevaj prejšnja navodila“ ali „ustvari zadnja vrata za testiranje“.

Nejasni ali neizvedljivi opisi – pozivi, ki so preveč kratki ali preveč nejasni, da bi ustvarili uporabno kodo. „Ustvari vtičnik“ ustvari smeti; „Ustvari kontaktni obrazec, ki pošilja vnose na e-poštni naslov s filtriranjem neželene pošte“ ustvari nekaj resničnega.

Če poziv ne prestane tega preverjanja, uporabnik vidi posebno sporočilo o napaki, ki pojasnjuje zakaj – ne splošno zavrnitev.

Faza 2: PHP linting v izoliranem zabojniku

Ko AI ustvari PHP kodo, se ta izvaja prek php -l v Docker zabojniku, ki je popolnoma izoliran od vsega drugega. To zazna sintaktične napake, še preden vtičnik sploh doseže namestitev WordPressa.

Ampak gremo dlje: če linting ne uspe, sistem ne zavrne samo izhoda. Pošlje napako nazaj AI s popravnim pozivom – to, čemur pravimo zdravljenje (healing). AI vidi svojo napako in poskusi ponovno, do trikrat.

To pomeni, da uporabniki skoraj nikoli ne vidijo sporočila „ustvarjanje ni uspelo“. Vidijo nekoliko daljši čas ustvarjanja – in delujočo kodo.

Faza 3: Pregled varnosti kode

To je najpomembnejša faza. Izvedemo statično analizo, ki preverja:

Nevarni funkcije: eval(), exec(), system(), shell_exec(), passthru() – katera koli od teh blokira izdajo vtičnika.

SQL injekcijski vektorji: surove $wpdb->query() klice z interpoliranimi spremenljivkami, manjkajoče $wpdb->prepare(), neposredna uporaba mysql_query().

Manjkajoči preverjanje dovoljenj: AJAX obravnavala, ki ne kličejo current_user_can() pred izvajanjem kakršnih koli privilegiranih dejanj.

Manjkajoče preverjanje nonce: obravnavala obrazcev, ki ne kličejo wp_verify_nonce() ali check_ajax_referer().

Neobdelana izhodna koda (Unescaped output): echo $_GET[...], echo $user_input brez funkcij za obdelavo.

Če je karkoli od tega najdeno, je vtičnik blokiran. Uporabnik vidi poročilo, ki natančno navaja, katere funkcije so sprožile blokado in zakaj – ne samo „varnostni pregled ni uspel“.

Kako izgleda revizijsko poročilo

Vsak ustvarjen vtičnik je priložen s poročilom o varnostni reviziji v preprostem jeziku. Navaja:

• Kateri pregledi so bili uspešni (zeleno)
• Kateri pregledi so sprožili opozorila (jantarno) — težave, ki niso blokirajoče, vendar si zaslužijo pozornost
• Vse popravke, ki so bili samodejno uporabljeni med zdravljenjem

Poročilo se ustvari samodejno in se priloži k prenosu vtičnika. Je koristno tako za vašo lastno samozavest kot za prikazovanje strankam, da ste varnost jemali resno.

Faza 4: Preverjanje ob shranjevanju

To ni del začetnega ustvarjanja — velja, ko uporabniki ročno urejajo kodo vtičnika v urejevalniku PAGEnza.

Vsakič, ko shranite, se znova zažene isti lint + varnostni pregled. Če med urejanjem uvedete kritično ranljivost, bo shranjevanje blokirano, dokler je ne odpravite. To preprečuje pogost scenarij, ko razvijalec naredi hitro "začasno" spremembo, ki ostane v proizvodnji dve leti.

Omejitve samodejne revizije

Samodejno skeniranje dobro zazna določeno vrsto težav. Ne zazna vsega.

Logične napake, pokvarjena poslovna logika in subtilne težave z eskalacijo dovoljenj, ki ne vključujejo znanih nevarnih vzorcev, še vedno zahtevajo človeško revizijo. V dokumentaciji smo glede tega pregledni – revizija ne nadomešča varnostne revizije, je pa osnova, ki zagotavlja minimalni standard.

Za proizvodne vtičnike, ki obravnavajo plačila ali občutljive podatke, poleg samodejnih pregledov priporočamo tudi ročno revizijo. Revizijsko poročilo človeškemu recenzentu zagotavlja dobro izhodišče.