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:
# Csak a konkrét AJAX hívást támadjuk SQLmap-pel
sqlmap -u "http://localhost:8888/wp-admin/admin-ajax.php" \
--data="action=my_plugin_save_settings&user_id=1&data=test" \
-p "user_id" --dbms=mysql --batchEz a parancs nem a szervert nézi, hanem azt vizsgálja meg, hogy a user_id paraméteren keresztül be lehet-e injektálni kártékony SQL kódot a pluginod adatbázis-kezelőjébe.
4. Üzleti logika és jogosultsági rések (Broken Access Control)
Az automaták nem látják, ha egy plugin engedi, hogy az ‘A’ felhasználó módosítsa a ‘B’ felhasználó adatait. Ez a Broken Access Control, ami 2026-ban is az egyik leggyakoribb WP hiba.
Nézd meg a plugin törlési funkcióit. Mindenhol ellenőrizzük, hogy a kérést indító felhasználónak van-e jogosultsága (current_user_can()) az adott konkrét ID törléséhez, vagy csak azt nézzük, hogy 'admin' rangban van-e?Titkok a kódban: A Gitleaks használata
Gyakori hiba, hogy a fejlesztés során (például teszteléshez) API kulcsok, Stripe titkos kódok vagy adatbázis jelszavak kerülnek a kódba, amik aztán a Git verziókezelőben maradnak.
Gitleaks audit
Az ágensnek utasítást adhatunk a Gitleaks futtatására a WSL-en belül:
„Pásztázd át a plugin teljes Git előzményeit Gitleaks-szel. Ha találsz korábbi commit-ban maradt API kulcsot vagy jelszót, figyelmeztess, hogy törölhessük a history-ból!”
Ez a lépés kritikus, mielőtt a plugint publikálnánk a WordPress.org tárolóba vagy átadnánk az ügyfélnek.
Statikus bástyák: PHPCS és PHPStan a plugin védelmében
Míg a fenti eszközök a „támadók”, a statikus elemzők a „védők”. Ezek a WSL-ben futnak, és közvetlenül a forráskódot vizsgálják, még mielőtt az elindulna a Docker konténerben.
PHPCS (A WordPress szabványok őre)
A PHPCS segítségével az ágens kényszeríti a biztonsági protokollok betartását:
- Kiszűri az elfelejtett
wp_verify_nonce()hívásokat. - Jelzi, ha egy kimenet (
echo) nincs megfelelően ellátvaesc_html()vagyesc_attr()függvénnyel.
PHPStan (A logikai hibák gyilkosa)
A PHPStan (level 5 vagy magasabb szinten) megakadályozza a típus-hibákból eredő összeomlásokat. Az ágens így látja, ha egy változó értéke bizonytalan, és javasolja a szigorúbb típus-ellenőrzést, ami a modern WordPress fejlesztés alapkövetelménye.
A „Mester-Audit” Script: Minden egy helyen
Hogy ne kelljen minden eszközt külön indítanod, kérd meg az ágenst, hogy készítsen egy központi audit scriptet a WSL/Ubuntu környezetbe. Ez a script a plugin mappájában futva sorra veszi az összes eszközt.
audit-plugin.sh:
#!/bin/bash
echo "--- Célzott Plugin Audit Indítása ---"
# 1. Kódminőség és biztonsági szabványok
vendor/bin/phpcs --standard=WordPress .
# 2. Logikai és típus-ellenőrzés
vendor/bin/phpstan analyse --level 5 .
# 3. Titkos kulcsok keresése
gitleaks detect --source . --verbose
# 4. Dinamikus tesztelés (Docker URL)
wapiti -u http://localhost:8888 --scope folderA feladatod NEM az, hogy elméleti útmutatót adj, hanem az, hogy a rendelkezésedre álló terminálos / fejlesztői környezetben TÉNYLEGESEN futtasd le a statikus elemzést egy WordPress pluginon.
KÖRNYEZET:
- WSL Ubuntu
- Docker
- localhost
- A WordPress projekt konténerben fut
- A plugin egy lokális fejlesztői környezetben található
- Neked kell felderítened, hogy hol van a plugin, milyen a könyvtárszerkezet, van-e composer, van-e vendor mappa, és melyik konténerben kell futtatni a parancsokat
ESZKÖZÖK, AMIKET TÉNYLEG Futtatnod KELL:
1. PHP_CodeSniffer + WordPress Coding Standards
2. PHPStan
3. Semgrep
KÖTELEZŐ MŰKÖDÉSI SZABÁLYOK:
- Ne adj csak tanácsot. Futtasd le a parancsokat.
- Előbb derítsd fel a környezetet: aktuális mappa, projekt gyökér, plugin mappa, docker konténerek, composer elérhetőség, php elérhetőség.
- Ha szükséges, használd a host oldalt vagy a Docker konténert, attól függően, melyikben működőképes a futtatás.
- Ha valami hiányzik, próbáld meg telepíteni vagy a projekt meglévő eszközeivel megoldani.
- Ne állj meg az első hibánál: próbálj alternatív futtatási módot.
- A cél a tényleges audit futtatása, nem a telepítési dokumentáció.
FELADATMENET:
1. Térképezd fel a környezetet
- pwd
- ls
- docker ps
- docker compose ps, ha van
- keresd meg a plugin mappát
- ellenőrizd, van-e composer.json
- ellenőrizd, van-e vendor/bin/phpcs
- ellenőrizd, van-e vendor/bin/phpstan
- ellenőrizd, van-e semgrep
- derítsd ki, hogy hoston vagy konténerben célszerű futni
2. Állapítsd meg a plugin pontos elérési útját
3. Ellenőrizd vagy állítsd be a szükséges eszközöket
- PHPCS
- WordPress Coding Standards
- PHPStan
- Semgrep
Ha valami hiányzik, próbáld telepíteni a legbiztonságosabb és legkevesebb beavatkozást igénylő módon.
4. Futtasd le ténylegesen az ellenőrzéseket a pluginon
- PHPCS WordPress szabályokkal
- PHPStan a plugin kódján
- Semgrep a plugin kódján
5. Minden futtatásnál add meg:
- a pontos parancsot
- röviden, hogy hoston vagy konténerben futott
- a nyers kimenet lényegi részét
- a találatok összesítését kategóriák szerint
6. A végén készíts audit összefoglalót ilyen bontásban:
- Kritikus hibák
- Magas kockázatú hibák
- Közepes hibák
- Alacsony hibák
- Kódszabvány problémák
- Valószínű hamis pozitív találatok
WORDPRESS-SPECIFIKUS FÓKUSZ:
Külön figyeld és emeld ki ezeket:
- sanitize hiány
- escaping hiány
- nonce hiány
- capability check hiány
- közvetlen fájlelérés elleni védelem hiánya
- $wpdb->prepare hiánya
- nem validált input
- admin POST / AJAX / REST jogosultsági hibák
- XSS, CSRF, SQL injection kockázat
- output escaping hibák rövidkódokban, admin oldalon, sablonkimenetben
KIZÁRANDÓ MAPPÁK:
A vizsgálatból zárd ki, ha léteznek:
- vendor
- node_modules
- build
- dist
- assets/vendor
- tests
- .git
FONTOS:
- Ne kérj visszaigazolást, ha a környezetből megállapítható a következő lépés.
- Ne írj hosszú elméletet.
- Előbb dolgozz, aztán riportolj.
- Ha valamelyik eszköz nem futtatható, írd le pontosan miért, és próbálj helyette működő alternatívát.
- Ne találgass a futtatás eredményéről. Csak a valóban lefuttatott eredményt írd le.
- Ha több plugin is van, az aktuális projektben legvalószínűbb célpluginon dolgozz, vagy derítsd ki a plugin gyökérmappáját a könyvtárszerkezetből.
A válaszod szerkezete legyen:
1. Környezetfelderítés
2. Futtatott parancsok
3. PHPCS eredmények
4. PHPStan eredmények
5. Semgrep eredmények
6. Kockázati összefoglaló
7. Javítási prioritási listaAz audit kézi elemzése, zaj szűrése, példa:
A korábbi PHPCS / PHPStan / Semgrep eredmények után most NE futtass újabb általános scanneket, hanem végezz CÉLZOTT KÉZI KÓDAUDITOT a pluginban.
Feladat:
1. Nyisd meg és elemezd a gyanús kódrészeket.
2. Ellenőrizd a teljes láncot: bemenet → validáció → nonce / jogosultság → feldolgozás → kimenet.
3. Döntsd el, melyik találat valós sérülékenység, melyik csak hamis pozitív.
Kiemelten nézd át:
- milyen inputból épül a kérés
- van-e nonce
- van-e MIME / Content-Type allowlist
- lehet-e XSS, SSRF vagy veszélyes tartalom-visszaadás
Ha van SQL:
Minden SQL találatra mondd ki:
- csak dinamikus táblanév-e
- van-e user input
- kell-e prepare
- van-e injection kockázat
- kockázati szint
Nézd meg még:
- van-e hiányzó current_user_can vagy nonce az admin / AJAX belépési pontokon
- van-e escaping hiány kimenetnél
- van-e veszélyes fájlművelet vagy külső kérés
A válaszod szerkezete legyen:
1. Átnézett fájlok és függvények
2. Proxy endpoint értékelése
3. SQL találatok kézi osztályozása
4. Jogosultság / nonce ellenőrzés
5. Valós sérülékenységek
6. Hamis pozitívok
7. Javítási prioritás
Fontos:
- ne adj általános elméletet
- konkrét fájlokra és függvényekre hivatkozz
- csak azt írd le, amit a kódban ténylegesen látsz
- röviden, tárgyilagosan dolgozzÖsszegzés: A plugin-fókuszú biztonság előnye
Ha nem a konténert, hanem a plugint auditálod, a javításaid sokkal pontosabbak lesznek. A WSL és a Docker környezet csupán a stabil „színpad”, ahol ez a dráma zajlik. A valódi munka a kód tisztán tartása, a folyamatos statikus elemzés és a célzott paraméter-bombázás, amivel elérhetjük, hogy a bővítményünk a WordPress tároló legszigorúbb követelményeinek is megfeleljen.
Vélemény, hozzászólás?