Bezpečnostní audit WordPressu: Co zkontrolovat před spuštěním

Než jakýkoli plugin generovaný společností PAGEnza dosáhne instalace WordPressu uživatele, projde třemi automatizovanými bezpečnostními kontrolami. Tento příspěvek vysvětluje, co tyto kontroly hledají – a proč na každé z nich záleží.

Proč kód generovaný AI potřebuje audit

Velké jazykové modely jsou překvapivě dobré v psaní pluginů pro WordPress. Znájí názvy hooků, rozumí standardům kódování WP, produkují čitelný PHP kód. Ale také dělají předvídatelné chyby – a tyto chyby jsou bezpečnostní zranitelnosti.

Nejčastější, které vidíme:

• Použití $_GET nebo $_POST bez sanitizace
• Chybějící ověření nonce při odesílání formulářů
• Přímé databázové dotazy bez $wpdb->prepare()
• Použití eval() nebo exec() pro dynamické chování
• Výstup uživatelských dat bez esc_html() nebo esc_attr()

Toto nejsou exotické okrajové případy. Pravidelně se objevují ve výstupech LLM – dokonce i z nejlepších modelů.

Fáze 1: Validace promptu

Než AI napíše jedinou řádku, analyzujeme popis uživatele. Tento krok zachytí dvě kategorie problémů:

Pokusy o manipulaci – prompty, které se snaží přimět AI k produkci záměrně škodlivého kódu. Věci jako „ignoruj předchozí instrukce“ nebo „vytvoř zadní vrátka pro testování“.

Nejasné nebo neproveditelné popisy – prompty, které jsou příliš krátké nebo příliš nejednoznačné na to, aby vyprodukovaly užitečný kód. „Vytvoř plugin“ generuje odpad; „Vytvoř kontaktní formulář, který odesílá zprávy na e-mailovou adresu s filtrováním spamu“ generuje něco reálného.

Pokud prompt tuto kontrolu nesplní, uživatel uvidí specifickou chybovou zprávu, která vysvětluje proč – ne obecné odmítnutí.

Fáze 2: Lintování PHP v izolovaném kontejneru

Jakmile AI vyprodukuje PHP kód, je spuštěn pomocí php -l v Docker kontejneru, který je zcela izolován od všeho ostatního. To zachytí syntaktické chyby dříve, než se plugin vůbec dostane do instalace WordPressu.

Ale jdeme dál: pokud lintování selže, systém výstup jednoduše neodmítne. Odešle chybu zpět AI s opravným promptem – tomu říkáme léčení (healing). AI vidí svou vlastní chybu a zkusí to znovu, až třikrát.

To znamená, že uživatelé téměř nikdy nevidí zprávu „generování selhalo“. Vidí mírně delší dobu generování – a funkční kód.

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

Toto je nejdůležitější fáze. Provádíme statickou analýzu, která kontroluje:

Nebezpečné funkce: eval(), exec(), system(), shell_exec(), passthru() – jakákoli z nich zablokuje vydání pluginu.

Vektory SQL injection: syrové $wpdb->query() volání s interpolovanými proměnnými, chybějící $wpdb->prepare(), přímé použití mysql_query().

Chybějící kontroly oprávnění: AJAX handlery, které nevolají current_user_can() před provedením jakékoli privilegované akce.

Chybějící ověření nonce: zpracovatelé formulářů, kteří nevolají wp_verify_nonce() nebo check_ajax_referer().

Neescapovaný výstup: echo $_GET[...], echo $user_input bez escape funkcí.

Pokud je cokoli z toho nalezeno, plugin je zablokován. Uživatel uvidí zprávu přesně uvádějící, které funkce spustily blokování a proč – ne jen „bezpečnostní kontrola selhala“.

Jak vypadá zpráva o auditu

Každý vygenerovaný plugin je dodáván se zprávou o bezpečnostním auditu v prostém jazyce. Uvádí:

• Které kontroly prošly (zelená)
• Které kontroly spustily varování (oranžová) – problémy, které nejsou blokující, ale zaslouží si pozornost
• Jakékoli opravy, které byly automaticky aplikovány během léčení

Zpráva je generována automaticky a připojena k souboru ke stažení pluginu. Je užitečná jak pro vaši vlastní jistotu, tak pro ukázání klientům, že jste bezpečnost brali vážně.

Fáze 4: Validace při ukládání

Tato část není součástí počátečního generování – platí, když uživatelé ručně upravují kód pluginu v editoru PAGEnza.

Pokaždé, když uložíte, spustí se znovu stejná lint + bezpečnostní kontrola. Pokud během úprav zavedete kritickou zranitelnost, ukládání bude zablokováno, dokud ji neopravíte. Tím se zabrání běžnému scénáři, kdy vývojář provede rychlou „dočasnou“ změnu, která zůstane v produkci dva roky.

Limity automatizovaného auditu

Automatické skenování dobře zachytává specifickou třídu problémů. Nezachytí všechno.

Logické chyby, rozbitá obchodní logika a jemné problémy s eskalací oprávnění, které nezahrnují známé nebezpečné vzorce, stále vyžadují lidskou revizi. Jsme v tomto ohledu transparentní v dokumentaci – audit nenahrazuje bezpečnostní revizi, je to základ, který zaručuje minimální standard.

Pro produkční pluginy zpracovávající platby nebo citlivá data doporučujeme kromě automatizovaných kontrol provést i manuální revizi. Zpráva o auditu poskytuje lidskému revizorovi dobrý výchozí bod.