Átirányító fertőzések és rosszindulatú JavaScript: miért visz máshová a weboldalad?

Átirányító fertőzés – a látogató megnyitja a weboldaladat, de néhány pillanattal később már egy idegen honlapon találja magát. Te ugyanazt a címet ellenőrzöd, és minden rendben működik. Máskor csak telefonon jelentkezik a probléma, vagy kizárólag akkor, ha valaki a Google találatából érkezik.

Az eltérő tapasztalat fontos nyom. A Google biztonsági leírása is bemutat olyan feltört oldalakat, amelyek az érkezési hely, a böngészőt jelző adatok vagy az eszköz alapján csak egyes látogatókat irányítanak át. [1]

Ebben a részben az átirányító fertőzéseket és a rosszindulatú JavaScript-kódokat vizsgáljuk. Megnézzük, hol keletkezhet az átirányítás, mit érdemes rögzíteni, és miért nem elég kizárólag a weboldal fájljai között keresni a hibát. Külön WordPress- és Joomla-kitekintés, valamint fejlesztői magyarázatok segítik az eligazodást.

Nem minden átirányítás fertőzés

Az átirányítás a web szabályos működésének része. Szükség lehet rá például címváltozáskor vagy egy régi tartalom új helyre költöztetésekor. A Google a szabályos átirányítások között a bejelentkezés utáni belső navigációt is megemlíti. [1]

A biztonsági kérdés az, ki és milyen céllal állította be a működést. Egy ismeretlen céloldal vizsgálatot indokol, de a pontos okot az átirányítási lánc és az azt elindító összetevő elemzése mutathatja meg.

Szemléltető, kitalált összehasonlítás: a régi kapcsolatoldal az új kapcsolatoldalra vezet, mert a tulajdonos átszervezte a honlapot. Másik esetben ugyanaz a cím egy engedély nélkül elhelyezett kód miatt idegen reklámoldalt nyit meg. A látogató mindkét esetben címet vált, a háttér és a szükséges beavatkozás azonban eltér.

Hogyan történhet az átirányítás?

Az MDN három alapvető megvalósítást különít el: HTTP-válasszal, HTML-ben megadott frissítéssel és JavaScript segítségével történő átirányítást. [2]

Megvalósítás	Hol látszik a működés?	Mi indítja a navigációt?
HTTP-átirányítás	A kiszolgálótól kapott válaszban	Átirányítási státuszkód és jellemzően egy Location fejléc
HTML-frissítés	Az oldal HTML-tartalmában	Egy meta refresh utasítás
JavaScript	A böngészőben végrehajtott programban	Egy navigációt kezdeményező művelet

Ez a csoportosítás az átirányítás módját írja le. Önmagában nem azonosítja a fertőzés helyét.

HTTP-átirányítás: amikor már a válasz másik címre mutat

Apache-környezetben például kiszolgálói átirányítási szabályok is létrehozhatják ezt a működést. A mod_rewrite dokumentációja külön tárgyalja az átirányítást és a belső címleképezést. Utóbbinál a kiszolgáló belső feldolgozása változik, nem feltétlenül a böngésző címsora. [3]

Az alkalmazás szintén adhat átirányító választ. PHP-ban a header() használható HTTP-fejlécek küldésére, köztük a Location megadására. A vizsgálatnak ezért a kiszolgálói szabályok mellett az alkalmazás működésére is ki kell terjednie. [4]

Technikai magyarázat: Egy 301 vagy 302 válasz az adott hálózati lépést írja le. Nem bizonyítja, hogy az átirányítást egy konkrét .htaccess fájl hozta létre. A választ előállító réteget külön kell azonosítani.

JavaScript-átirányítás: amikor a böngésző kap új utasítást

A JavaScript a betöltött oldalból is indíthat navigációt. A location.replace() például az aktuális dokumentum helyett másik címet tölt be, és az aktuális oldalt nem őrzi meg külön előzménybejegyzésként. Ez szabályos webes API, amely kártékony célra is felhasználható. [5]

Kitalált példa: a weboldal először megjelenik, majd egy betöltött szkript idegen címre irányítja a látogatót. Az eredeti oldal első válasza ebben a példában lehet sikeres 200 válasz. Az átirányítás a később végrehajtott kódból következik.

Ezért az első HTTP-válasz ellenőrzése nem írja le a teljes böngészőbeli eseménysort.

Hol lehet a rosszindulatú kód forrása?

Saját fájlban vagy az oldalba illesztett tartalomban

Az XSS, vagyis cross-site scripting során nem megbízható adat végrehajtható kódként kerülhet a böngészőbe. A védelem függ attól, milyen környezetbe kerül az adat: például HTML-be, attribútumba vagy JavaScriptbe. [6]

A vizsgálatban ezért külön kell kezelni a kód tárolási és végrehajtási helyét. Egy adatbázisban tárolt tartalom részeként kiadott szkript a böngészőben fut. A böngészőbeli végrehajtásból nem következik, hogy a szerver és az adatbázis érintetlen.

Kitalált példa: egy jogosulatlanul módosított tartalmi blokk szkriptet illeszt a megjelenő oldalba. A sablon eredeti fájlja közben változatlan. Ebben az esetben a sablon ellenőrzése mellett a tartalom eredetét is fel kell tárni.

Külső szolgáltatótól betöltött szkriptben

Az oldal idegen kiszolgálóról is betölthet JavaScriptet. Az OWASP külön tárgyalja az ilyen függőségek kockázatait: a külső kód megváltozhat, és hozzáférhet az oldal böngészőben elérhető adataihoz. [7]

Kitalált példa: egy régebben beillesztett külső szolgáltatás szkriptje megváltozik, és jogosulatlan navigációt indít. A saját tárhely fájljainak összehasonlítása ebben a példában nem mutatja meg a külső kiszolgálóról érkező kód változását.

Vizsgálati szempontból azt is érdemes rögzíteni, melyik összetevő hivatkozik a külső programra. Egy külső domain ismeretlensége önmagában nem diagnózis; a rendeltetését és a működését kell ellenőrizni.

Nyílt átirányítás: amikor telepített malware nélkül is visszaélhetnek az oldallal

A nyílt átirányítás, angolul open redirect, akkor keletkezhet, ha az alkalmazás nem megfelelően ellenőrzött bemenet alapján választ átirányítási célpontot. Az OWASP szerint ez adathalász támadások támogatására is használható, mert a hivatkozás kezdetben egy megbízhatónak látszó oldalra mutathat. [8]

Kitalált példa: egy belépési folyamat a kérésben megadott visszatérési címet ellenőrzés nélkül elfogadja, és külső honlapra irányít. A támadó az így összeállított hivatkozást terjeszti.

Ebben a példában a probléma hibás bemenetellenőrzés. Az átirányítás létrejöttéhez nem szükséges külön kártékony fájlt telepíteni. A javításnak ezért az elfogadható célpontok és az alkalmazás logikájának ellenőrzésére kell irányulnia. [8]

Miért csak egyes látogatókat érint?

A feltételes működés miatt azonos URL megnyitása különböző eredményt adhat. A Google a feltört tartalmaknál kifejezetten említi a referrer, a user agent és az eszköz szerinti eltérést. [1]

Az összehasonlító vizsgálatban ezek mellett a bejelentkezési állapotot, az időpontot és a böngészőprofil állapotát is érdemes rögzíteni. Ezek vizsgálati változók, nem egy adott fertőzésre vonatkozó állítások.

Megfigyelés	Hasznos összehasonlítás
Keresőből érkezve jelentkezik	Ugyanaz a pontos URL közvetlen megnyitással
Telefonon jelentkezik	Másik eszköz, a további feltételek rögzítésével
Bejelentkezve eltérő	Kijelentkezett állapot, azonos címen
Csak egy böngészőprofilban látható	Új profil és másik böngésző
Az első és a későbbi megnyitás eltér	A megnyitások sorrendje és időpontja

Technikai magyarázat: A HTTP-fejléc neve történeti okból Referer. A böngészőben használt referrer-szabályozás határozza meg, milyen érkezési információ kerülhet a kérésbe. Ez az adat hiányozhat vagy korlátozott lehet; nem tekinthető teljes, biztos látogatói előzménynek. [9]

A táblázat lehetséges ellenőrzéseket ad. Ha egy új profilban nem jelentkezik a hiba, abból még nem dönthető el, hogy helyi böngészőprobléma vagy eltérő feltétellel működő weboldalkód okozza.

Gyorsítótár, böngészőbővítmény vagy service worker?

A gyorsítótár régebbi választ is kiszolgálhat

A HTTP-gyorsítótárazásnál a böngésző és köztes gyorsítótárak korábban kapott válaszokat is felhasználhatnak. A működést a válaszokhoz kapcsolódó szabályok befolyásolják. [10]

Kitalált példa: a szerveren javítottak egy szkriptet, de egy korábbi változat még gyorsítótárból töltődik. A böngészőben tapasztalt eltérés ilyenkor nem önmagában bizonyítja a szerver újrafertőződését. A hálózati ellenőrzés során a kiszolgált változatot és annak forrását kell összehasonlítani.

A böngészőbővítmény is módosíthatja az oldalt

A Chrome dokumentációja szerint a bővítmények tartalmi szkriptjei olvashatják és módosíthatják a weboldal DOM-ját. Emiatt a böngészőben látott állapot vizsgálatához a helyi bővítmények is hozzátartozhatnak. [11]

Ez lehetőség, nem automatikus magyarázat. Egyetlen érintett böngésző esetén is meg kell őrizni a pontos jelenséget és összehasonlítható körülmények között kell ellenőrizni a működést.

A service worker nem önmagában kártékony

A service worker az oldalhoz regisztrált, háttérben működő program, amely a hatókörébe tartozó kérések és válaszok kezelésében is részt vehet. Alkalmazható például offline működéshez és gyorsítótárazáshoz. Biztonságos környezetet igényel; éles weboldalnál ez jellemzően HTTPS. [12]

Nem tetszőleges, minden honlapot vezérlő böngészőprogram: az eredet és a regisztráció hatóköre korlátozza. A service worker jelenléte nem fertőzésjel. [12]

Technikai magyarázat: A Chrome DevTools az Application → Service Workers részen mutatja a regisztrációkat és a kapcsolódó vizsgálati lehetőségeket. A tesztelésnél a hálózati megkerülés is segíthet összehasonlítani a működést. A regisztráció és a gyorsítótár eltávolítása előtt érdemes rögzíteni, melyik szkript és hatókör szerepelt ott. [13]

Egy törlés után eltűnő tünet az adott böngésző állapotáról ad információt. A szkript eredetét és a webhely aktuális működését ettől még külön meg kell vizsgálni.

Hogyan követhető vissza az átirányítás?

Fejlesztői vizsgálatnál a hálózati események rögzítése segít elkülöníteni az egyes lépéseket. Chrome DevToolsban erre a Network panel használható. [14]

Egy lehetséges ellenőrzési sorrend:

1. Nyisd meg a fejlesztői eszközöket a jelenség reprodukálása előtt.
2. A Network panelen kapcsold be a Preserve log lehetőséget, hogy a navigációk között is megmaradjanak a bejegyzések.
3. A rögzített körülményekkel nyisd meg az érintett címet.
4. Vizsgáld meg a dokumentumkérések státuszát, válaszfejléceit és sorrendjét.
5. Ahol elérhető, nézd meg az Initiator adatot, amely a kérést elindító összefüggéshez adhat támpontot. [14]

A HAR-export megosztása előtt ellenőrizni kell annak tartalmát, mert hálózati adatokat és érzékeny információkat is tartalmazhat. [14]

A böngészőbeli eredményt ezután össze kell kapcsolni az alkalmazás és a kiszolgáló vizsgálatával. Egyetlen kérés vagy szkript neve ritkán írja le a teljes eredetet.

Kitalált példa: az oldal HTML-je egy saját domainen lévő szkriptet tölt be. Az további külső programot kér le, majd az indít navigációt. A külső célcím ismerete mellett az első hivatkozás beillesztésének helyét is meg kell találni.

WordPress: melyik összetevő adja a választ és tölti be a szkriptet?

A WordPress saját wp_redirect() függvénye HTTP-átirányítást indíthat. A függvényhez kapcsolódó dokumentáció a X-Redirect-By fejléc használatát is bemutatja. Ez nyom lehet a válasz vizsgálatakor, de önmagában nem azonosítja a konkrét bővítményt és nem igazolja a szabályos működést. [15]

A JavaScript-fájlok regisztrálására és betöltésére többek között a wp_enqueue_script() szolgál. A betöltött cím mögött ezért egy bővítmény vagy sablon hivatkozását is keresni kell. [16]

Kitalált vizsgálati példa: az idegen szkriptet egy szerkeszthető HTML-blokk tartalmazza. A bővítmények eredeti fájljainak összehasonlítása közben nem találni eltérést. Ebben az esetben a tartalom módosítását és az azt lehetővé tevő hozzáférést is fel kell tárni.

A fájlok, tartalmak és hozzáférések együttes ellenőrzése illeszkedik a WordPress hivatalos biztonsági útmutatójának több rétegre kiterjedő szemléletéhez. [17]

Joomla: a tartalom és az azt megjelenítő kód is számít

A Joomla dokumentációja XSS-példával mutatja be, hogyan válhat egy felhasználó által megadott tartalom végrehajtható JavaScriptté, ha az alkalmazás veszélyes módon jeleníti meg. A bevitel kezelése és a kimenet megfelelő escape-elése külön feladat. [18]

Kitalált példa: egy komponens által megjelenített szöveg veszélyes kódot tartalmaz. A szöveg eltávolítása a konkrét tartalmat kezeli, az azt végrehajthatóvá tevő programhiba viszont külön javítást igényelhet.

Joomla-oldalon az érintett tartalom, a megjelenítő komponens és a kapcsolódó modulok, pluginek vagy sablon együtt adhatják a vizsgálat hatókörét. A kód eredetét kell feltárni, nem az adott összetevőtípust általában gyanúsnak tekinteni.

Mi tartozik a helyreállításhoz?

Az alábbi munkamenet szerkesztett javaslat; az adott oldal állapota alapján kell alkalmazni.

Először a jelenséget és a láncot rögzítsd. Melyik címről, milyen lépéseken keresztül, milyen célra jutott a látogató? Milyen körülmények között ismételhető meg?

Azonosítsd az elindító összetevőt. A látható célcím mellett keresd meg a navigációt előidéző szabályt vagy programot, és azt is, hogyan került a rendszerbe.

Kezeld az érintett hozzáféréseket és hibákat. Egy idegen szkript eltávolítása nem válasz arra, hogy ugyanazzal a hozzáféréssel újra beilleszthető-e. A korábbi, hátsó kapukról szóló rész vizsgálati szempontjai itt is alkalmazhatók.

Ellenőrizd a kiszolgált változatokat. A javított szerverállapotot a gyorsítótárból, külső forrásból vagy service worker közreműködésével érkező válaszoktól is meg kell különböztetni.

Ismételd meg az összehasonlítható próbákat. A teszt eredményét a vizsgált URL-ekhez és körülményekhez kösd. Rögzítsd, ha bizonyos korábbi helyzeteket nem sikerült reprodukálni.

Miben segít a Content Security Policy?

A Content Security Policy, röviden CSP, böngésző által érvényesített szabályokkal korlátozhatja például a szkriptforrásokat és egyes kódfuttatási módokat. Az OWASP kiegészítő védelmi rétegként tárgyalja. [19]

Ez nem teljes körű átirányítás-tiltás. A script-src a szkriptfuttatás feltételeit szabályozza; nem helyettesíti a hibás szerveroldali átirányítás vagy nyílt átirányítás javítását. A szabályzatot az alkalmazás működéséhez kell megtervezni és ellenőrizni.

Technikai magyarázat: A Content-Security-Policy-Report-Only fejléc megfigyelésre szolgál: a szabálysértéseket jelzi, de a szabályzatot nem tiltó módban érvényesíti. A túl tág vagy rosszul kialakított szabályzat védelmi értékét külön kell értékelni. [19]

Gyakori kérdések

Ha nálam jó, attól még átirányíthat másokat?

Igen. A feltételes átirányítás dokumentált jelenség. A megfigyelés körülményeit az érintett látogatók körülményeivel is össze kell hasonlítani. [1]

Egy 200 OK válasz kizárja az átirányítást?

Nem. A betöltött HTML vagy az utána futó JavaScript később is indíthat navigációt. [2][5]

Ha csak egy böngésző érintett, biztosan az fertőzött?

Ezt nem lehet a tünetből megállapítani. A helyi állapotot és a webhely feltételes működését is vizsgálni kell.

Elég törölni az idegen domainre mutató sort?

A konkrét hivatkozás eltávolítása mellett a beillesztés eredetét, a további betöltéseket és az érintett hozzáféréseket is fel kell tárni. Ellenkező esetben a vizsgálat az eseménysor egy részét hagyja nyitva.

A következő rész: SEO-spam és a keresőtalálatok manipulálása

A következő cikkben a SEO-spam kerül sorra: az engedély nélkül létrehozott aloldalak, idegen hivatkozások és módosított tartalmak. Megnézzük, hogyan különíthető el az oldal aktuális állapota a keresőben látható információktól, és mi tartozik a helyreállításhoz.

Források

Forrásellenőrzés: 2026. október 24. A példák kitalált szemléltető esetek. A vizsgálati táblázatok és a helyreállítás sorrendje szerkesztett javaslatok; konkrét weboldalra vonatkozó diagnózist nem állítanak.

1. Google Search Central: Spam policies – hacked content and sneaky redirects.
2. MDN: Redirections in HTTP.
3. Apache HTTP Server: Redirecting and Remapping with mod_rewrite.
4. PHP: header().
5. MDN: Location.replace().
6. OWASP: Cross Site Scripting Prevention.
7. OWASP: Third Party JavaScript Management.
8. OWASP: Unvalidated Redirects and Forwards.
9. MDN: Referrer-Policy.
10. MDN: HTTP caching.
11. Chrome Extensions: Content scripts.
12. MDN: Service Worker API.
13. Chrome DevTools: Debug Progressive Web Apps.
14. Chrome DevTools: Network features reference.
15. WordPress: wp_redirect().
16. WordPress: wp_enqueue_script().
17. WordPress: Hardening WordPress.
18. Joomla: Common Vulnerabilities.
19. OWASP: Content Security Policy.

Ha gyanús, hogy weboldalad vírusos vagy feltört, segítünk a helyreállításban !