WordPress biztonság

A WordPress biztonság nem egyetlen funkció, beállítás vagy bővítmény kérdése. Sokkal inkább egy szemlélet és folyamatos gyakorlat, amelynek célja az, hogy egy weboldal ellenálló legyen a támadásokkal, visszaélésekkel és kód fertőzésekkel szemben.

Biztonságos a WordPress?

Fontos megérteni egy alapvető tényt: A WordPress önmagában nem veszélyes, sőt kifejezetten biztonságos rendszer. A WordPress core fejlesztését egy nemzetközi, hatalmas fejlesztői közösség végzi, amely folyamatosan javítja a hibákat és gyorsan reagál a biztonsági problémákra. A WordPress-nek külön Security csoportja van, a biztonság ellenőrzésére. A gondok túlnyomó többsége a használat módjából erednek. Ezért is készült ezen cikk, aminek az elolvasása erősen ajánlott.

A WordPress biztonság megértése nem csak fejlesztőknek fontos, hanem minden weboldal tulajdonosnak, aki adatokat kezel, ügyfelekkel kommunikál, vagy használja a wordpress.org-os WP rendszerét. A cikk legfontosabb részéhez nem szükséges programozási, informatikai tudás!

Mit jelent egy WordPress oldal „feltörése”?

Sokan azt gondolják, hogy egy feltört weboldal azonnal látványos jeleket mutat: idegen tartalom, átirányítás más oldalra, vagy figyelmeztetés a böngészőben. Ez azonban csak a legsúlyosabb esetek egy része.

Valójában egy WordPress oldal lehet úgy is kompromittált, hogy:

  • a látogatók semmit nem vesznek észre;
  • a támadó rejtett admin fiókot hoz létre;
  • a szerver spam leveleket küld;
  • SEO spam kerül az oldalba (rejtett linkek, kulcsszavak);
  • adatokat szivárogtat (felhasználói e-mailek, jelszó hash-ek).

Ez különösen veszélyes, mert az ilyen „csendes” fertőzések hónapokig észrevétlenek maradhatnak, miközben komoly reputációs és jogi kockázatot jelentenek.

A legtöbb feltörés mögött:

  • elavult bővítmények,
  • gyenge jelszavak,
  • rossz jogosultsági beállítások,
  • vagy nem megfelelő szerverkonfiguráció áll.

Alapfogalmak, amelyeket érdemes tisztázni

Mi az a sebezhetőség?

Sebezhetőségnek nevezünk minden olyan hibát vagy hiányosságot, amely lehetővé teszi, hogy egy támadó nem várt módon férjen hozzá a rendszerhez, vagy olyan műveletet hajtson végre, amelyhez nem lenne joga.

Ez lehet:

  • programozási hiba,
  • hiányzó ellenőrzés,
  • rosszul konfigurált beállítás,
  • vagy emberi mulasztás.

Mi az a támadási felület?

A támadási felület azoknak a pontoknak az összessége, ahol egy weboldal „érintkezik a külvilággal”. Ilyen például:

  • a bejelentkezési oldal,
  • az űrlapok,
  • az XML-RPC,
  • a REST API,
  • a fájlfeltöltési lehetőségek.

A WordPress biztonság egyik alapelve: minél kisebb a támadási felület, annál kisebb a kockázat.

Az 5 leggyakoribb WordPress támadási módok

1. Brute force támadások

Ez a legegyszerűbb, de még mindig rendkívül gyakori módszer. A támadó automatizált eszközökkel próbálja végig:

  • a leggyakoribb felhasználóneveket,
  • a leggyengébb jelszavakat.

Ha a jelszó gyenge, vagy az admin felhasználónév „admin”, a siker esélye drámaian megnő.

2. Elavult bővítmények kihasználása

A legtöbb WordPress sebezhetőség bővítményekhez kapcsolódik. Így ez kritikusan fontos a biztonság szempontjából. Egy régi verziós plugin:

  • ismert hibát tartalmazhat,
  • publikus exploit állhat hozzá rendelkezésre,
  • automatizált szkriptek célpontja lehet.

3. Cross-Site Scripting (XSS)

Az XSS során a támadó rosszindulatú JavaScript kódot juttat be az oldalba, amely:

  • ellophatja a felhasználók sütijeit,
  • átirányíthatja a látogatókat,
  • admin jogosultságot szerezhet.

Ez gyakran űrlapoknál vagy kommenteknél fordul elő, ha nincs megfelelő adatellenőrzés.

4. Jogosultsági hibák kihasználása

Ha egy bővítmény vagy téma nem megfelelően ellenőrzi, hogy egy felhasználó mit csinálhat, akkor:

  • egy egyszerű felhasználó admin funkciókhoz férhet hozzá,
  • beállításokat módosíthat,
  • fájlokat tölthet fel.

5. Rosszindulatú fájlfeltöltés

Ez az egyik legsúlyosabb kategória. Ha egy támadó képes:

  • PHP fájlt feltölteni,
  • majd azt futtatni,

akkor gyakorlatilag teljes irányítást szerezhet az oldal felett.

Top 10 WordPress biztonsági hiányosság

  1. Frissítések elhanyagolása
  2. Gyenge jelszavak használata
  3. „admin” felhasználónév alkalmazása
  4. Nem megbízható forrásból származó bővítmények
  5. HTTPS hiánya
  6. XML-RPC indokolatlan engedélyezése
  7. Biztonsági mentések hiánya
  8. Felesleges, nem használt bővítmények
  9. Rossz fájl- és mappajogosultságok
  10. Szerveroldali alapvédelem hiánya

Ezek többsége nem technikai hiba, hanem felhasználói döntés vagy odafigyelés hiányának a kérdése.

Alapvető biztonsági lépések WordPress-hez

Ezek azok a lépések, amelyeket már a weboldal tulajdonosa vagy adminisztrátora is el és érdemes is figyelembe venni, hogy a szerver konfigurációkba ne kellene nyúlnia.

  • Erős jelszavak és kétlépcsős azonosítás: Az admin felület védelmének első vonala a minőségi hitelesítés, amely jelentősen csökkenti a brute force kockázatot.
  • Felhasználói szerepkörök racionalizálása: Csak azoknak adj admin jogosultságot, akiknek tényleg szükséges; másoknak legyen korlátozottabb szerepkör. Ha szükséges, csak ideiglenesen kapjon szükségesnél magasabb szerepkört.
  • Legkevesebb szükséges plugin használata: Minden plugin potenciális sebezhetőséget jelent; ezért csak a nélkülözhetetleneket tartsd fenn és frissítsd őket folyamatosan.

A legfontosabb megelőző teendők – útmutató

Az 1. és 2. pontot mindenképpen vegyük komolyan, mivel ezek elvégzésével jelentősen javíthatunk wordPress honlapunk, WooCommerce webáruházunk biztonságán.

  1. WordPress, bővítmények és sablonok rendszeres frissítése
    A frissítések nem csak új funkciókat hoznak, hanem zárják az ismert hibákat és réseket is, amelyeket automatizált támadók próbálnak kihasználni.
  2. Erős, egyedi admin felhasználónév és jelszó használata
    Az alapértelmezett „admin” és gyenge jelszavak bruteforce támadások célpontjai; ezek megnehezítik a jogosulatlan belépést.
  3. HTTPS használata minden oldalon (SSL/TLS)
    A HTTPS titkosítja a kommunikációt, megakadályozza, hogy az adataid (pl. jelszó) lehallgathatók legyenek nyilvános hálózaton is.
  4. Megbízható tárhelyszolgáltató választása
    Egy jó szolgáltató rendszeresen frissíti a szerver szoftvereket, megfelelő tűzfalat és karbantartást biztosít, így a szerveroldali sebezhetőségek esélye csökken.
  5. Biztonsági mentések rendszeres készítése
    Mentések nélkül egy sikeres támadás esetén az oldalad visszaállítása nagyon nehéz lehet; érdemes külön szerverre/szolgáltatásba exportálni a mentéseket.
  6. Felesleges vagy inaktív bővítmények törlése
    Még inaktív plugin is hordozhat kódot, amely hibát tartalmazhat; ezért csak azt tartsd, amit valóban használsz.
  7. Gyenge FTP/WebDAV programok kerülése
    A nem biztonságos FTP‑kliensek jelszót vagy hitelesítő adatokat tárolhatnak rosszul, amelyeket helyi malware is kihasználhat. (Illetve sima FTP-t ne használjunk, helyette sFTP-vel kapcsolódjunk.)
  8. Az alapértelmezett tábla előtag (wp_) módosítása az adatbázisban
    Az elterjedt wp_ előtagot kihasználó támadások egyszerűbbé teszik a WordPress ID‑k és táblák felismerését; egyedi előtag csökkenti ezt a lehetőséget.
  9. Fájl‑ és mappajogosultságok helyes beállítása
    Olyan jogosultságokat állíts be (pl. 644/755), amelyek minimalizálják, hogy illetéktelenek írhassanak vagy módosíthassanak fájlokat.
  10. Biztonsági hibák és hibaüzenetek elrejtése a belépési felületen
    A hibaüzenetek gyakran túl sok információt adnak a támadónak. Ezek elrejtésével megnehezíthetjük a jogosulatlan feletti diagnosztizálást.

WordPress szerveroldali védelem növelése

A most következő szekcióban kifejezetten a szerveroldalt érintő védekezéseket tárgyaljuk, mert ezek a WordPresshez kapcsolódó legfontosabb „hardening” lépések. A megközelítésünk az, hogy tudatosan minimális támadási felületet hagyjunk maga körül — tehát ne csak az alkalmazást (WordPress), hanem a webkiszolgálót is keményítsük. A szabályok alapesetben két fő webszerver‑típusra alkalmazhatók: Apache és nginx.

Apache / .htaccess alapú védelem

Az Apache szerverek .htaccess konfigurációs fájljai lehetővé teszik, hogy mappaszintű szabályokat alkalmazzunk anélkül, hogy a szerver teljes főkonfigurációját módosítanánk. A Rotisoft cikk több ilyen kódot is javasol.

1. wp‑config.php elrejtése
Ez megakadályozza, hogy a konfigurációs fájl közvetlenül böngészőn keresztül elérhető legyen.

# wp-config.php védelme
<Files wp-config.php>
 order allow,deny
 deny from all
</Files>

2. Mappa indexelés tiltása
Megakadályozza, hogy külső látogatók (vagy támadók) a könyvtárak tartalmát listázzák.

# Mappa indexelés tiltása
Options -Indexes

3. IndexIgnore konfiguráció
További fájltípusok elrejtése a mappalistázásnál:

# Mappa listázás finomítása ha megis engedelyezve lenne
IndexIgnore *.php *.js *.log *.zip *.tar *.gz *.sql *.bak *.old *.backup *.tmp *.conf *.ini *.env *.yml *.yaml *.json .git .gitignore .gitattributes

4. XML‑RPC tiltása
Az XML‑RPC sok brute force és API‑t használó támadás célpontja lehet, ezért gyakran érdemes letiltani, ha nincs rá szükség.

# XML‑RPC tiltása
<Files xmlrpc.php>
 Require all denied
</Files>

5. Egyszerű XSS / URL szűrés .htaccess‑szel
Ez a szabály megakadályoz bizonyos típusú rosszindulatú szkriptkódok továbbadását az URL‑ben — egy egyszerű első védelmi vonal lehet, de nem helyettesíti a teljes alkalmazás‑szintű validációt. Ezt ellenőrizni kell, mert egyes pluginek érzékenyek lehetnek rá.

# Egyszerű XSS szűrés
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0‑9A‑Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0‑9A‑Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

6. Admin elérhetőség IP‑limitálással
Ha fix IP‑címed van, ezzel csak a saját címed engedélyezheted a /wp‑admin mappához.

# Admin IP korlátozás pelda ip-vel
order deny,allow
allow from 111.1.111.1
deny from all

Ezek a példapéldányok a Rotisoft cikkből származó, kézzel szerkeszthető .htaccess minták és tanácsok alapján állnak össze.

Nginx‑es szabályok

Az nginx nem használ .htaccess‑t, ezért minden szabályt a szerverkonfigurációban (pl. nginx.conf vagy a vhost konfigurációban) kell elhelyezni. A következő minták hasonló védelmet nyújtanak az Apache‑os példákhoz.

1. wp‑config.php elrejtése

location ~* wp-config.php {
    deny all;
}

2. Mappa indexelés tiltása

autoindex off;

3. XML‑RPC tiltása

location = /xmlrpc.php {
    deny all;
    return 403;
}

4. Egyszerű XSS kérésblokkolás

Ennél szintén ellenőrizzük a bővítményeket, mert érzékenyek lehetnek rá.

if ($query_string ~* "<script>") {
    return 403;
}

Ezek az alapok segítenek az nginx‑szerverek számára is minimalizálni a támadási felületet. A konkrét szabályok mindig a szerver egész kontextusában értelmezendők (pl. SSL, reverse proxy, CDN mögött).

Haladóbb, szerveroldali és fejlesztői szintű védelmek

Ezek a technikák már konfigurációs vagy fejlesztői tudást igényelnek, de lényegesen magasabb szintű védelmet adnak:

  • Web Application Firewall (WAF): A WAF képes kiszűrni a rosszindulatú kéréseket már azelőtt, hogy elérnék a WordPress alkalmazást. Nem WordPress‑plugin, hanem általában szerver/edge‑szolgáltatás (pl. Cloudflare), és erősen csökkenti a támadási felületet.
  • Szerveroldali PHP korlátozások: Bizonyos PHP függvények letiltása (mint exec, shell_exec stb.) csökkenti egy esetleges kompromittálás utáni mozgásteret.
  • Jogosultság minimalizálása a szerveroldalon: Ez magában foglalja az operációs rendszer fájlrendszer jogosultságainak, a MySQL felhasználói jogainak és a szerver folyamatok izolációjának optimalizálását.
  • Staging / tesztkörnyezet használata: Minden frissítést és módosítást egy külön tesztoldalon validálj, mielőtt éles oldalra kerülnének; így csökkented a hibák és biztonsági problémák esélyét.

Záró gondolatok

A WordPress biztonság nem egyetlen eszköz vagy beállítás kérdése, hanem egy tudatos, rétegzett védekezési rendszer. A felhasználói szintű intézkedésektől kezdve a szerveroldali keményítésig minden réteg hozzájárul ahhoz, hogy az oldalad kevésbé legyen célpont, és támadás esetén is gyorsabb legyen a helyreállítás.

A fentieket kombinálva, a cikkben valamint további forrásokban található tanácsokat követve egy olyan biztonsági stratégiát tudsz kialakítani, ami nem csak taktikai, hanem stratégiai szintű védelmet is ad az oldaladnak.

Ahol segítséget kérhetsz

Csatlakozzon ~16.000 tagot számláló legnagyobb és fő WordPress-es, magyar nyelvű csoportunkhoz.

WordPress fejlesztők és felhasználók csoportja → (új ablakban nyílik meg)

Várjuk WooCommerce-es magyar nyelvű csoportunkban fejlesztőket és webáruház tulajdonosokat egyaránt.

WooCommerce fejlesztők és felhasználók csoportja → (új ablakban nyílik meg)

WordPress specifikus, saját közösségi terünk. Egy régimódi, hagyományos fórum, ahol szintén lehet segítséget kérni.

Fórumunk → (új ablakban nyílik meg)