Bezpečnostný audit WordPressu: Čo skontrolovať pred spustením

Predtým, ako akýkoľvek plugin vygenerovaný spoločnosťou PAGEnza dosiahne inštaláciu WordPressu používateľa, prejde tromi automatizovanými bezpečnostnými kontrolami. Tento príspevok vysvetľuje, čo tieto kontroly hľadajú – a prečo na každej z nich záleží.

Prečo kód generovaný AI potrebuje audit

Veľké jazykové modely sú prekvapivo dobré v písaní pluginov pre WordPress. Poznajú názvy hookov, rozumejú štandardom kódovania WP, produkujú čitateľný PHP kód. Ale tiež robia predvídateľné chyby – a tieto chyby sú bezpečnostné zraniteľnosti.

Najčastejšie, ktoré vidíme:

• Použitie $_GET alebo $_POST bez sanitizácie
• Chýbajúce overenie nonce pri odosielaní formulárov
• Priame databázové dopyty bez $wpdb->prepare()
• Použitie eval() alebo exec() pre dynamické správanie
• Výstup používateľských dát bez esc_html() alebo esc_attr()

Toto nie sú exotické okrajové prípady. Pravidelne sa objavujú vo výstupoch LLM – dokonca aj z najlepších modelov.

Fáza 1: Validácia promptu

Predtým, ako AI napíše jediný riadok, analyzujeme popis používateľa. Tento krok zachytí dve kategórie problémov:

Pokusy o manipuláciu – prompty, ktoré sa snažia prinútiť AI k produkcii zámerne škodlivého kódu. Veci ako „ignoruj predchádzajúce inštrukcie“ alebo „vytvor zadné vrátka na testovanie“.

Nejasné alebo neuskutočniteľné popisy – prompty, ktoré sú príliš krátke alebo príliš nejednoznačné na to, aby vyprodukovali užitočný kód. „Vytvor plugin“ generuje odpad; „Vytvor kontaktný formulár, ktorý odosiela správy na e-mailovú adresu s filtrovaním spamu“ generuje niečo reálne.

Ak prompt túto kontrolu nesplní, používateľ uvidí špecifickú chybovú správu, ktorá vysvetľuje prečo – nie všeobecné odmietnutie.

Fáza 2: Lintovanie PHP v izolovanom kontajneri

Keď AI vyprodukuje PHP kód, je spustený pomocou php -l v Docker kontajneri, ktorý je úplne izolovaný od všetkého ostatného. To zachytí syntaktické chyby skôr, ako sa plugin vôbec dostane do inštalácie WordPressu.

Ale ideme ďalej: ak lintovanie zlyhá, systém výstup jednoducho neodmietne. Pošle chybu späť AI s opravným promptom – tomu hovoríme liečenie (healing). AI vidí svoju vlastnú chybu a skúsi to znova, až trikrát.

To znamená, že používatelia takmer nikdy nevidia správu „generovanie zlyhalo“. Vidia mierne dlhší čas generovania – a funkčný kód.

Fáza 3: Kontrola bezpečnosti kódu

Toto je najdôležitejšia fáza. Vykonávame statickú analýzu, ktorá kontroluje:

Nebezpečné funkcie: eval(), exec(), system(), shell_exec(), passthru() – ktorákoľvek z nich zablokuje vydanie pluginu.

Vektory SQL injection: surové $wpdb->query() volania s interpolovanými premennými, chýbajúce $wpdb->prepare(), priame použitie mysql_query().

Chýbajúce kontroly oprávnení: AJAX handlery, ktoré nevolajú current_user_can() pred vykonaním akejkoľvek privilegovanej akcie.

Chýbajúce overenie nonce: spracovatelia formulárov, ktorí nevolajú wp_verify_nonce() alebo check_ajax_referer().

Neunescapovaný výstup: echo $_GET[...], echo $user_input bez escape funkcií.

Ak sa čokoľvek z toho nájde, plugin je zablokovaný. Používateľ uvidí správu presne uvádzajúcu, ktoré funkcie spustili blokovanie a prečo – nie len „bezpečnostná kontrola zlyhala“.

Ako vyzerá správa o audite

Každý vygenerovaný plugin je dodávaný so správou o bezpečnostnom audite v jednoduchom jazyku. Uvádza:

• Ktoré kontroly prešli (zelená)
• Ktoré kontroly spustili varovania (oranžová) – problémy, ktoré nie sú blokujúce, ale zaslúžia si pozornosť
• Akékoľvek opravy, ktoré boli automaticky aplikované počas liečenia

Správa sa generuje automaticky a pripája sa k stiahnutému pluginu. Je užitočná tak pre vašu vlastnú istotu, ako aj pre ukázanie klientom, že ste bezpečnosť brali vážne.

Fáza 4: Validácia pri ukladaní

Táto časť nie je súčasťou počiatočného generovania – platí, keď používatelia manuálne upravujú kód pluginu v editore PAGEnza.

Zakaždým, keď uložíte, spustí sa rovnaká lint + bezpečnostná kontrola znova. Ak počas úprav zavediete kritickú zraniteľnosť, ukladanie bude zablokované, kým ju neopravíte. Tým sa predíde bežnému scenáru, keď vývojár vykoná rýchlu „dočasnú“ zmenu, ktorá zostane v produkcii dva roky.

Limity automatizovaného auditu

Automatické skenovanie dobre zachytáva špecifickú triedu problémov. Nezachytáva všetko.

Logické chyby, rozbitá obchodná logika a jemné problémy s eskaláciou oprávnení, ktoré nezahŕňajú známe nebezpečné vzorce, stále vyžadujú ľudskú revíziu. Sme v tomto transparentní v dokumentácii – audit nenahrádza bezpečnostnú revíziu, je to základ, ktorý zaručuje minimálny štandard.

Pre produkčné pluginy spracúvajúce platby alebo citlivé údaje odporúčame manuálnu revíziu okrem automatizovaných kontrol. Správa o audite poskytuje ľudskému revízorovi dobrý východiskový bod.