A legtöbb biztonsági ajánló ott hibázik, hogy általános „weboldal-szkennelést” javasol. Fejlesztőként azonban minket nem a teljes szerver érdekel, hanem egy konkrét bővítmény sérthetetlensége.
Az alábbi teszteket NE éles oldalon futtasuk!
Hanem például WSL környezetben, wp-env alatt dolgozzunk, itt van lehetőségünk a bővítményt mikroszkóp alá tenni és izoláltan tesztelni minden egyes függvényét. Aki LocalWP-t használ, annak érdemes teszteléshez egy Docker alapú WordPress futtatásra áttérni! A példákban én http://localhost:8888 -ot használok, mint tesztkörnyezet, a portszám nálad más lehet!
Támadás szimulálására (Fuzzing): Wapiti
Ez egy nyílt forráskódú program, ami úgy működik, mint egy igazi hacker. Végignézi az oldaladat, megkeresi az összes beviteli mezőt (például kereső, űrlapok), és megpróbál XSS vagy SQL kódokat beírni rajtuk keresztül. Szintén ingyenes és nem kér tokent.
A fenti kettőt gond nélkül automatizálhatjuk, és kiadhatjuk a favágómunkát egy ágensnek is; a WSL:Ubuntu, a wp-env és a Docker-környezet biztosítja majd hozzá a jogosultságot:
Gyors és modern hibakereső: Nuclei
Ez egy nagyon népszerű, nyílt forráskódú eszköz. Rengeteg előre megírt sablonja van, amelyekkel gyakori WordPress és szerver hibákat keres. Van hozzá hivatalos Docker képfájl, így könnyen el tudod indítani a környezetedben, token nélkül.
Aktív támadás: Wapiti és SQLmap
SQLmap (Az adatbázis-specialista): Ha gyanús adatbázis-lekérdezést találunk, az SQLmap segítségével az ágens megpróbálja „feltörni” azt. Ha sikerül, az ágens azonnal tudja, hogy a $wpdb->prepare() használata elkerülhetetlen az adott sorban.
Futtass dinamikus biztonsági teszteket a helyi Docker környezetemen futó WordPress bővítményeimen. Használd a Nuclei, SQlmap és a Wapiti eszközöket a http://localhost:8888 címen. Keresd meg a sebezhetőségeket (például XSS, CSRF, SQL injekció).Miért törli a fenti biztonsági teszt az oldalakat, és hogyan védekezz ellene?
Ha a wp-env beállításaidnál (a .wp-env.json fájlban) a "testsEnvironment": false szerepel, az azt jelenti, hogy a rendszer nem indít el egy külön, eldobható teszt weboldalt. Ilyenkor csak egyetlen oldalad fut (például a 8889-es porton), és minden ott történik.
Mi történt pontosan a tesztelés alatt?
Amikor egy automatikus biztonsági tesztet (például Wapitit) futtatsz, az úgy viselkedik, mint egy nagyon gyorsan kattintgató robot.
- A tesztelő program adminisztrátorként lépett be a WordPress vezérlőpultjára (
/wp-admin). - Végigkattintott minden elérhető linket és gombot, amit csak talált.
- Mivel adminisztrátori jogai voltak, rákattintott a „Kukába helyezés” (trash) linkekre is. Emiatt kerültek a tartalmaid a kukába.
Hogyan kerüld el ezt a jövőben?
Ahhoz, hogy a weboldalad biztonságban maradjon a tesztelés alatt, ezt az 5 szabályt érdemes követned:
Készíts biztonsági mentést:
A teszt indítása előtt készíts egy gyors mentést (snapshot) az adatbázisról. Ha a program mégis elront valamit, egy lépésben mindent vissza tudsz állítani.
Zárd ki a veszélyes linkeket:
Állítsd be a tesztelő programot úgy, hogy hagyja ki a törlő és módosító linkeket (például: action=trash, action=delete, post.php, edit.php).
Használj korlátozott tesztfiókot:
Ne futtass automatikus tesztet főadminisztrátori fiókkal. Készíts egy egyszerű teszt felhasználót, akinek egyáltalán nincs joga tartalmat törölni.
Készíts külön tesztkörnyezetet:
A komoly, kattintgató teszteket futtasd egy teljesen különálló, erre a célra indított környezeten (például egy külön .wp-env.scan.json fájllal), és soha ne azon az oldalon, amin éppen fejlesztesz.
Csak olvass az admin felületen:
A vezérlőpulton csak olyan tesztet engedélyezz, ami csak nézelődik (passzív teszt), de nem kattint rá a műveleti gombokra.
A „Targeted” szemlélet: Mit nézünk egy pluginban?
Egy plugin biztonsága három pilléren nyugszik: hogyan fogadja az adatot, hogyan tárolja azt, és hogyan jeleníti meg. Az AI ágensek, mint a Devstral, Codex stb, itt tudnak a legtöbbet segíteni, mert képesek végigkövetni egy változó útját a $_POST kéréstől egészen az adatbázisig.
1. Belépési pontok feltérképezése (Entry Points)
Mielőtt bármilyen eszközt indítanánk, az AI ágens segítségével összeírjuk a plugin „támadási felületét”. Ez nem a konténerről szól, hanem a plugin saját kapuiról:
- AJAX végpontok: Minden
wp_ajax_éswp_ajax_nopriv_kampó egy potenciális bejárat. - REST API route-ok: Ha a bővítmény saját API végpontokat regisztrál.
- Shortcode-ok és űrlapok: Bárhol, ahol a felhasználó adatot küldhet be.
- Admin oldalak: Olyan beállítások, ahol egy „szándékosan kártékony” admin felhasználó próbálhat meg kódot injektálni (XSS).
2. Statikus mélyelemzés (SAST) a plugin szintjén
Ebben a fázisban a PHPCS és a PHPStan csak és kizárólag a plugin mappáját vizsgálja. A cél az, hogy a kód szintjén zárjuk ki a banális hibákat.
Szigorú szűrés és típuskezelés
A 2026-os elvárás a WordPress-nél a „szigorú típusosság”. Az ágensnek kiadott parancs: „Vizsgáld meg a plugin összes bejövő paraméterét. Ha egy paraméterről tudjuk, hogy egész szám (pl. termék ID), ellenőrizd, hogy az absint() függvényt használjuk-e a sanitize_text_field() helyett, mert a típus-szűrés a legjobb védelem!”
A PHPStan „Level 9” kihívás
A PHPStan legmagasabb szintjén az ágensnek bizonyítania kell, hogy a kód minden ága biztonságos. Ez megfogja azokat a logikai hibákat, ahol egy függvény váratlanul null értékkel térhetne vissza, megnyitva egy kaput a hibás futtatásnak.
3. Célzott dinamikus tesztelés (Plugin-Fuzzing)
Itt nem a localhost-ot támadjuk általánosságban, hanem a plugin specifikus URL-jeit és paramétereit. Olyan eszközöket használunk, mint az SQLmap vagy a Wapiti, de paraméterezve.
Példa: Specifikus AJAX teszt
Ha a pluginod egy my_plugin_save_settings nevű AJAX akciót használ, az ágens így konfigurálja a tesztet: