WordPress-oldal átirányít egy másik oldalra: az átirányítás megkeresése

Miért nem látja Ön az átirányítást

A feltöréskor elhelyezett átirányítás megválogatja, kire vonatkozik. Többnyire megkíméli a webhelyet kezelő személyt, hogy minél tovább a helyén maradhasson. A leggyakoribb feltételek:

• Honnan érkezik a látogató: csak a keresőből vagy közösségi oldalról érkező látogatókat irányítja át. A kód a kérés Referer fejlécét olvassa.
• Az eszköz: csak a telefonokat irányítja át. A kód a User-Agent fejlécet olvassa.
• A bejelentkezés: a WordPressbe bejelentkezett adminisztrátor a rendes webhelyet látja.
• Az első látogatás: egy süti megjegyzi, hogy a látogatót már átirányította, így a következő látogatás rendben zajlik. A hiba ezért időszakosnak tűnik.

Ha egy ügyfél azt írja, hogy „a webhelyük máshová visz”, vegye komolyan, akkor is, ha Önnél minden rendben jelenik meg.

Az átirányítás előidézése

Helyezkedjen annak a látogatónak a helyzetébe, akit átirányít:

1. Nyisson privát böngészőablakot, keressen rá a cége nevére egy keresőben, és kattintson a saját találatára.
2. Ismételje meg telefonról, Wi-Fi helyett mobiladat-kapcsolaton.
3. Jegyezze fel a célcímet, az időpontot és az eszközt: erre a három adatra a tárhelyszolgáltatónak lesz szüksége, később pedig a Google-nek küldött felülvizsgálati kérelemnek.

Ha hozzáfér egy terminálhoz, ez a parancs úgy kéri le a kezdőlapját, mintha egy Google-ről érkező iPhone volna:

curl -s -i -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -e "https://www.google.com/" https://www.sajat-webhely.com/

Olvassa el a válasz első sorait. Ha 301 vagy 302 kód után egy ismeretlen címre mutató Location: sor következik, az átirányítást a szerver végzi: a .htaccess fájlban vagy egy PHP-fájlban van. Ha a kód 200, a böngészőt mégis átirányítja, az átirányítás az oldalon belül, JavaScriptben történik: többnyire az adatbázisban vagy a sablon egyik fájljában van.

Mielőtt hozzányúlna a webhelyhez: három lépés

1. Teljes másolat a jelenlegi állapotról. Fájlok és adatbázis, dátummal, a szerveren kívül tárolva. Bizonyítékként, összehasonlítási alapként és védőhálóként szolgál arra az esetre, ha a takarítás valami hasznosat is eltávolítana.
2. A jelszavak, egy fertőzésmentes eszközről. A tárhelyszolgáltató ügyfélfiókja, az FTP- vagy SFTP-fiókok, az adatbázis-felhasználó (az új jelszót vezesse át a wp-config.php fájl DB_PASSWORD állandójába), majd minden WordPress-adminisztrátori fiók.
3. A biztonsági kulcsok. Cserélje le a wp-config.php nyolc sorát, az AUTH_KEY sortól a NONCE_SALT sorig, egy új készletre, amelyet a https://api.wordpress.org/secret-key/1.1/salt/ címen generálhat. Minden nyitott munkamenet lezárul, a behatolóé is.

wp config shuffle-salts

Hol rejtőzik az átirányítás

1. A .htaccess fájl

A webhely gyökerében, néha egy almappában is, a .htaccess fájl a behatoló által hozzáadott átírási szabályokat tartalmazhat. A WordPress saját blokkja rövid, a # BEGIN WordPress és a # END WordPress sor fogja közre:

# BEGIN WordPress
# A `BEGIN WordPress` és az `END WordPress` sorok közötti tartalom dinamikusan lett létrehozva, és csak WordPress szűrők módosíthatják. E kettő sor közötti bármilyen kézi módosítás el fog veszni.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Az a RewriteCond szabály, amely a %{HTTP_REFERER} (google, bing, facebook) vagy a %{HTTP_USER_AGENT} (android, iphone, mobile) értéket vizsgálja, és amelyet egy külső címre mutató RewriteRule követ, maga az átirányítás. A gyorsítótárazó és biztonsági bővítmények is írnak saját, a nevükkel jelölt blokkokat: eltávolítás előtt vessen össze minden blokkot a bővítményei listájával.

2. A PHP-fájlok

A WP-CLI összeveti a WordPress-mag és a bővítmények fájljait a WordPress.org által közzétett ellenőrzőösszegekkel, és felsorol minden módosított vagy hozzáadott fájlt:

wp core verify-checksums
wp plugin verify-checksums --all

A második parancs a WordPress.org bővítménytárában terjesztett bővítményekre terjed ki. A kiadójától vásárolt bővítményt a nála lévő fiókjából letöltött friss példánnyal kell összevetni. Ez gyakori eset: 2026. szeptember 1-jei felmérésünk 540 kkv-s WordPress-oldalt vizsgált, és 66 %-uk legalább egy olyan bővítményt hordoz, amely hiányzik a nyilvános tárolóból.

WP-CLI nélkül két keresés ad első szűrést:

find . -name "*.php" -mtime -30
find wp-content/uploads -name "*.php"

Az első az elmúlt 30 napban módosított PHP-fájlokat listázza, a második a médiamappában tárolt PHP-fájlokat, amelyek ott eleve gyanúsak (egyes bővítmények üres index.php fájlt helyeznek oda, ez rendben van). A módosítás dátuma meghamisítható: a rossz helyen lévő régi fájlt is meg kell vizsgálni.

Elsőként ezeket nyissa meg: wp-config.php, a gyökérben lévő index.php, az aktív sablon functions.php és header.php fájlja, valamint a wp-content/mu-plugins mappa: az itt lévő bővítmények automatikusan betöltődnek, és a vezérlőpultról nem kapcsolhatók ki. A keresendő jelek: eval(, base64_decode(, gzinflate(, str_rot13(, hosszú, olvashatatlan karakterláncok, vagy window.location, amelyet egy ismeretlen cím követ.

3. Az adatbázis

A JavaScript-átirányítás szívesen fészkeli be magát az oldalak tartalmába vagy a beállításokba, ahol egyetlen fájl sem mutatja. A WP-CLI a WordPress összes táblájában keres egy karakterláncot:

wp db search "<script"
wp db search "fromCharCode"

WP-CLI nélkül ugyanezek a keresések a phpMyAdmin SQL fülén futtathatók:

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';
SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';

Egyes találatok jogosak: egy látogatottságmérő, egy sütisáv vagy egy Ön által elhelyezett widget. Azt kell megvizsgálni, ami semmivel sem egyezik abból, amit Ön telepített, különösen az olyan szkriptet, amely karakterkódokból állít össze egy címet.

4. A címbeállítások és a fiókok

A Beállítások > Általános oldalon a „WordPress cím (URL)” és a „Honlap cím (URL)” mezőben az Ön domainjének kell szerepelnie. Ugyanezek az értékek a wp-config.php fájlban a WP_HOME és a WP_SITEURL állandóval is rögzíthetők: mindkét helyet ellenőrizze.

wp option get home
wp option get siteurl
wp user list --role=administrator

Ha az állandók meg vannak adva, az első két parancs azok értékét adja vissza. Az utolsó felsorolja az adminisztrátorokat, regisztrációs dátumukkal; a vezérlőpulton ugyanez a lista a Felhasználók menüben érhető el, az Adminisztrátor szerepkörre szűrve. Azt a fiókot, amelyet senki sem ismer fel, törölje, a tartalmát egy jogos fiókhoz rendelve.

Az átirányítás eltávolítása, majd a hozzáférésé, amelyen bekerült

Az átirányító sor törlése megszünteti a tünetet. A behatoló által használt hozzáférés viszont nyitva marad, amíg meg nem találják, és az átirányítás napokon belül visszatér. A tartós sorrend:

1. Cserélje a mag fájljait friss példányra: törölje a wp-admin és a wp-includes mappát, majd futtassa a wp core download --skip-content --force parancsot, amely a bővítményei, sablonjai és médiafájljai érintése nélkül írja újra a magot. A parancs felülírja a meglévő fájlokat, de egyetlen hozzáadott fájlt sem töröl: ezért kell előbb a két mappát törölni, és ezért kell a gyökérben lévő ismeretlen PHP-fájlokat kézzel eltávolítani.
2. Telepítse újra a sablont és minden bővítményt a hivatalos forrásukból, és törölje azokat, amelyeket a webhely már nem használ, a kikapcsoltakat is: a fájljaik a szerveren maradnak.
3. Távolítsa el az idegen PHP-fájlokat a wp-content/uploads mappából, a .htaccess fájlhoz hozzáadott szabályokat és az adatbázisban talált szkripteket.
4. Ellenőrizze az ütemezett feladatokat a wp cron event list paranccsal: egy ismeretlen nevű feladat visszahelyezheti a kódot.
5. Frissítse a WordPresst, a sablont és a bővítményeket.
6. Ismételje meg a kezdeti teszteket, több eszközről és több napon át.

Ha a webhely személyes adatokat tárol (űrlapok, ügyfélfiókok, rendelések), jegyezze fel, mikor észlelte a feltörést. Az Európai Unióban az általános adatvédelmi rendelet (GDPR) előírja, hogy az adatkezelő a személyes adatokat érintő adatvédelmi incidenst legkésőbb 72 órával azután jelentse be a felügyeleti hatóságnak, hogy az a tudomására jutott, kivéve, ha az incidens valószínűsíthetően nem jár kockázattal a természetes személyek jogaira és szabadságaira nézve.

A Google, és amit a látogatói látnak

Ha a Google észleli az átirányítást, a Chrome a webhely megnyitása előtt piros „Veszélyes webhely” oldalt jeleníthet meg, a Google pedig a találata alá kiírhatja: „Lehet, hogy ezt a webhelyet feltörték”. A Google Search Console Biztonsági problémák jelentése megmutatja, mit talált és mely címeken. A webhely megtisztítása után a Felülvizsgálat kérése gomb indítja el az ellenőrzést.