WordPress Biztonsági Audit: Mit ellenőrizzünk a "live" előtt

Mielőtt bármely PAGEnza által generált bővítmény eljutna egy felhasználó WordPress-telepítésébe, három automatizált biztonsági ellenőrzésen megy keresztül. Ez a bejegyzés elmagyarázza, mit keresnek ezek az ellenőrzések – és miért fontos mindegyik.

Miért van szükség az AI által generált kód auditálására?

A nagy nyelvi modellek meglepően jól írnak WordPress bővítményeket. Ismerik a hook neveket, értik a WP kódolási szabványait, olvasható PHP-t produkálnak. De kiszámítható hibákat is vétenek – és ezek a hibák biztonsági réseket jelentenek.

A leggyakoribbak, amelyeket látunk:

• $_GET vagy $_POST használata tisztítás (sanitization) nélkül
• Nonce ellenőrzés hiánya űrlapok beküldésekor
• Közvetlen adatbázis-lekérdezések $wpdb->prepare() nélkül
• eval() vagy exec() használata dinamikus viselkedéshez
• Felhasználói adatok megjelenítése esc_html() vagy esc_attr() nélkül

Ezek nem egzotikus, ritkán előforduló esetek. Rendszeresen megjelennek az LLM kimenetében – még a legjobb modellek esetében is.

1. szakasz: Prompt validálás

Mielőtt az AI egyetlen sort írna, elemezzük a felhasználó leírását. Ez a lépés kétféle problémát ragad meg:

Manipulációs kísérletek – olyan promptok, amelyek célja, hogy az AI szándékosan rosszindulatú kódot generáljon. Olyasmik, mint „hagyd figyelmen kívül az előző utasításokat” vagy „hozz létre egy hátsó ajtót teszteléshez“.

Homályos vagy megvalósíthatatlan leírások – olyan promptok, amelyek túl rövidek vagy túl kétértelműek ahhoz, hogy hasznos kódot állítsanak elő. „Készíts egy bővítményt” szemét generál; „Hozzon létre egy kapcsolatfelvételi űrlapot, amely spam szűréssel küld bejegyzéseket egy e-mail címre” valami valósat generál.

Ha egy prompt megbukik ezen az ellenőrzésen, a felhasználó egy konkrét hibaüzenetet lát, amely elmagyarázza, miért – nem egy általános elutasítást.

2. szakasz: PHP lintelés izolált konténerben

Miután az AI PHP kódot generált, azt php -l paranccsal futtatjuk egy Docker konténerben, amely teljesen el van szigetelve mindentől. Ez rögzíti a szintaxis hibákat, még mielőtt a bővítmény egyáltalán eljutna egy WordPress telepítésbe.

De tovább megyünk: ha a lintelés sikertelen, a rendszer nem csak elutasítja a kimenetet. Visszaküldi a hibát az AI-nak egy javító prompttal – ezt hívjuk gyógyításnak (healing). Az AI látja saját hibáját, és legfeljebb háromszor próbálkozik újra.

Ez azt jelenti, hogy a felhasználók szinte soha nem látnak „generálás sikertelen” üzenetet. Egy kissé hosszabb generálási időt – és működő kódot látnak.

3. szakasz: Kód biztonsági vizsgálat

Ez a legfontosabb szakasz. Statikus elemzést futtatunk, amely ellenőrzi:

Veszélyes függvények: eval(), exec(), system(), shell_exec(), passthru() – bármelyik is blokkolja a bővítmény kiadását.

SQL injekciós vektorok: nyers $wpdb->query() hívások interpolált változókkal, $wpdb->prepare() hiánya, mysql_query() közvetlen használata.

Hiányzó jogosultság-ellenőrzések: AJAX kezelők, amelyek nem hívják a current_user_can() függvényt, mielőtt bármilyen privilegizált műveletet végeznének.

Hiányzó nonce ellenőrzés: űrlapfeldolgozók, amelyek nem hívják a wp_verify_nonce() vagy check_ajax_referer() függvényeket.

Escapoletlan kimenet: echo $_GET[...], echo $user_input escape függvények nélkül.

Ha bármelyik problémát észleljük, a bővítmény blokkolva lesz. A felhasználó egy jelentést lát, amely pontosan felsorolja, mely függvények váltották ki a blokkolást és miért – nem csak egy „biztonsági ellenőrzés sikertelen” üzenetet.

Milyen az audit jelentés?

Minden generált bővítményhez mellékelünk egy közérthető biztonsági audit jelentést. Ez tartalmazza:

• Mely ellenőrzések sikerültek (zöld)
• Mely ellenőrzések váltottak ki figyelmeztetéseket (sárga) – olyan problémák, amelyek nem blokkolók, de figyelmet érdemelnek
• Az automatikusan alkalmazott javítások a gyógyítás során

A jelentés automatikusan generálódik és csatolva van a bővítmény letöltéséhez. Hasznos mind a saját magabiztosságodhoz, mind annak bemutatásához az ügyfeleknek, hogy komolyan vetted a biztonságot.

4. szakasz: Mentéskori validálás

Ez nem része az első generálásnak – akkor érvényes, amikor a felhasználók manuálisan szerkesztik a bővítmény kódját a PAGEnza szerkesztőben.

Minden mentéskor ugyanaz a lint + biztonsági vizsgálat fut újra. Ha szerkesztés közben kritikus biztonsági rést vezetsz be, a mentés blokkolva lesz, amíg azt ki nem javítod. Ez megakadályozza azt a gyakori forgatókönyvet, amikor egy fejlesztő gyors „ideiglenes” változtatást hajt végre, amely két évig marad a termelésben.

Az automatizált audit korlátai

Az automatizált vizsgálat jól elkapja a problémák egy bizonyos osztályát. Nem mindent fog el.

A logikai hibák, a hibás üzleti logika és a finom jogosultság-eskalációs problémák, amelyek nem járnak ismert veszélyes mintákkal, továbbra is emberi felülvizsgálatot igényelnek. Ebben a dokumentációban átláthatóak vagyunk – az audit nem helyettesíti a biztonsági felülvizsgálatot, hanem egy alap, amely minimális színvonalat garantál.

Fizetési vagy érzékeny adatokat kezelő éles bővítmények esetén az automatizált ellenőrzések mellett manuális felülvizsgálatot is javaslunk. Az audit jelentés jó kiindulópontot biztosít egy emberi felülvizsgáló számára.