Vírus, féreg, trójai vagy malware? Mi fertőzheti meg a weboldaladat?

(A weboldalakat veszélyeztető kártékony kódokat, automatizált visszaéléseket és támadási módszereket bemutató cikksorozatunk 1. része)

„Vírusos lett a weboldalam.” Egy idegen átirányítás, egy tárhelyszolgáltatói riasztás vagy egy gyanús programfájl láttán kézenfekvő így leírni a problémát. A pontos diagnózis azonban ennél több kérdést igényel. Kártékony program került a tárhelyre? Egy bővítmény tartalmaz rejtett funkciót? A látogató böngészőjében fut idegen kód? Esetleg egy program önállóan próbál újabb rendszerekre továbbterjedni?

A malware, vírus, féreg és trójai összefüggő, de különböző fogalmak. Ebben a cikkben megmutatjuk, mit jelentenek, hogyan kapcsolódnak a weboldalakhoz, és milyen következtetést lehet levonni egy-egy észlelt jelből. Külön kitérünk a WordPress- és Joomla-oldalakra, valamint a kivizsgálás és a helyreállítás alapjaira.

Rövid válasz: mi a különbség?

A malware a kártékony szoftverek gyűjtőneve. A vírus más programokhoz vagy fájlokhoz kapcsolódva terjeszti önmagát. A féreg önállóan másolja és terjeszti saját kódját. A trójai ártalmatlannak vagy hasznosnak látszó program, amely rejtett, rosszindulatú funkciót tartalmaz. Ezek a NIST fogalommeghatározásain alapuló különbségek. [1–4]

Fogalom	Mit emel ki a megnevezés?	Mi alapján azonosítható?
Malware	A szoftver kártékony rendeltetését	A működése és célja alapján
Vírus	A más programot vagy fájlt megfertőző önmásolást	Az önmásolási mechanizmus alapján
Féreg	Az önálló önmásolást és továbbterjedést	A program terjedési működése alapján
Trójai	A látszólagos és a rejtett funkció különbségét	A program megtévesztő működése alapján

A táblázat nem teljes malware-katalógus. Azt mutatja meg, hogy a megnevezések eltérő tulajdonságokra irányítják a figyelmet.

Mit jelent a malware egy weboldalon?

A malware az angol malicious software kifejezésből származik. A kártékony működés érintheti az adatok bizalmasságát, sértetlenségét és a szolgáltatás rendelkezésre állását. A program például adatot szerezhet meg vagy jogosulatlan műveleteket végezhet. [1]

Webes környezetben a kód helye és végrehajtásának helye külön kérdés. Egy szerverre feltöltött webshell a webkiszolgálón futva adhat hozzáférést a támadónak. Egy külső JavaScript viszont a látogató böngészőjében hajtódik végre. A két eset kivizsgálása eltérő nyomokat és ellenőrzéseket igényel. [5][6]

Szemléltető, kitalált példa: egy honlap a megszokott módon megjelenik, de az egyik betöltött szkript az űrlapba írt adatokat idegen címre továbbítja. Ebben a példában a kárt az adatküldés okozza. Az értékeléshez azt kell feltárni, honnan érkezik a szkript, mi indítja el, és pontosan milyen adatot kezel.

Technikai magyarázat: Egy külső szolgáltatótól betöltött JavaScript kompromittálódása akkor is érintheti a látogatót, ha a saját tárhelyen lévő fájlok nem változtak meg. Az OWASP ezért a külső szkripteket külön biztonsági függőségként kezeli. [6]

Vírus: az önmásolás a döntő tulajdonság

A vírus meghatározó jellemzője, hogy más programokat vagy fájlokat módosítva helyezi el saját másolatát. Aktiválódásához a fertőzött gazdaprogram végrehajtása szükséges. A NIST definícióiban a terjedési mechanizmus központi szerepet kap. [2]

Ezért egy módosított weboldalfájl önmagában még nem bizonyít vírusműködést. A fájlt módosíthatta egy támadó, egy távolról vezérelt eszköz vagy egy másik program is. A vírus megnevezéshez az önmásoló működésre is bizonyíték kell.

Kitalált példa: egy támadó ugyanazt az átirányító kódrészletet három PHP-fájlba írja. A három módosításból még nem derül ki, hogy a kód képes-e önállóan további fájlokat megfertőzni. Ehhez a program működését kell elemezni.

Tulajdonosként természetesen elmondhatod, hogy „vírusos a weboldal”. A szakmai vizsgálatban viszont a „három fájlban jogosulatlan kódot találtunk” pontosabb kiindulópont, mint egy még nem igazolt típusnév.

Féreg: önállóan továbbterjedő program

A féreg önálló programként másolja és terjeszti önmagát. A NIST meghatározásai szerint hálózati mechanizmusokat is használhat más rendszerek elérésére, és terjedéséhez nem feltétlenül szükséges felhasználói beavatkozás. [3]

Webes környezetben a féregszerű működés megértéséhez a program teljes tevékenységét kell vizsgálni. A kérdés az, hogy a már elindult példány megpróbál-e további rendszereket elérni és azokra saját másolatot juttatni.

Kitalált példa: egy sérülékeny kiszolgálón elindult program újabb célpontokat keres, ugyanazt a hibát próbálja kihasználni, majd a következő sikeresen elért gépen is elindítja önmagát. Ez a példa az önálló továbbterjedést szemlélteti.

Ettől különbözik az a helyzet, amikor egy támadó a saját infrastruktúrájáról egymás után sok weboldalt támad meg. A tömeges automatizálás önmagában még nem igazolja, hogy a célpontokon féreg működik. Az elhatároláshoz az önmásolás és a továbbterjedés útját kell feltárni.

Technikai magyarázat: A féreg és az automatizált támadóeszköz megkülönböztetésénél azt keressük, hogy az újonnan kompromittált rendszer maga is a terjedés részévé válik-e. A nagy számú kérés vagy a sok érintett weboldal önmagában nem írja le ezt a mechanizmust.

Trójai: amikor a hasznos funkció mögött más is történik

A trójai látszólag elfogadható feladatot lát el, közben rejtett, rosszindulatú funkciót is tartalmaz. A klasszikus meghatározás szerint önmagát nem másoló program. A vírushoz és féreghez képest itt a megtévesztő működés a meghatározó. [4]

Kitalált weboldalas példa: egy „ingyenes prémium sablon” valóban biztosítja az ígért megjelenést, de a telepítőcsomag egy rejtett adminisztrátori hozzáférést létrehozó kódot is futtat. A működő látványterv ebben az esetben nem cáfolja a rejtett káros funkciót.

Az ilyen helyzetek megértéséhez fontos a szoftver eredete. Az OWASP szoftverellátási láncról szóló útmutatója az összetevők megbízhatóságát és a beszerzési, fejlesztési, illetve kiadási folyamatok biztonságát is tárgyalja. [7]

Egy program eredetére vonatkozó kétely ugyanakkor nem azonos a fertőzés bizonyítékával. Az elemzés feladata a konkrét rejtett működés feltárása. Egy hibás bővítmény, egy sérülékeny bővítmény és egy szándékosan kártékony csomag különböző eset; a helyreállítás és a felelősség megítélése szempontjából is számít a különbség.

Miért nem elég egyetlen fertőzésnév?

A malware megnevezés a kártékony jelleget, a vírus és féreg a terjedést, a trójai a megtévesztést emeli ki. Más elnevezések a feladatot írják le. A webshell például a támadó webes hozzáférésének és műveletvégzésének eszköze lehet. [1–5]

Szemléltető példa: egy módosított bővítmény a látható funkciója mellett webshellt helyez el. A csomag megtévesztő működését a trójai jelleggel, az elhelyezett hozzáférési eszközt pedig a webshell megnevezéssel írhatjuk le. Két külön kérdésre adunk választ: mit rejtett a telepített program, és milyen eszközt hozott létre?

A pontos leíráshoz ezért legalább ezeket érdemes rögzíteni:

• melyik összetevőben találták a kódot;
• milyen műveleteket végez;
• milyen jogosultsággal fut;
• másolja vagy terjeszti-e önmagát;
• milyen további változásokat okozott.

Ez a szemlélet a sorozat további részeiben is segít: az átirányítás, az adatlopás és a SEO-spam más szempontot ír le, mint a kód terjedési mechanizmusa.

Milyen jelek indokolnak vizsgálatot?

A Google a feltört weboldalak tartalmai között idegen kód beillesztését, meglévő tartalom módosítását, új oldalak létrehozását és jogosulatlan átirányítást is bemutat. Ezek fontos észlelési pontok. [8]

Vizsgálatot indokolhat például:

• olyan aloldal vagy hivatkozás, amelyet a tulajdonos nem hozott létre;
• váratlan átirányítás;
• ismeretlen szkript megjelenése a betöltött oldalon;
• az eredeti csomagtól eltérő programfájl;
• ismeretlen hozzáférés vagy adminisztrátori művelet.

A megfigyelésből még nem következik automatikusan a malware típusa. A naplók a belépési, jogosultsági és alkalmazásesemények összekapcsolásában segíthetnek. A vizsgálat során az észlelt jelenséget és az abból levont következtetést külön kell kezelni. [9]

Technikai magyarázat: Egy fájleltérés nem feltétlenül kártékony: lehet szándékos helyi módosítás is. Egy egyező fájl pedig csak az ellenőrzés által lefedett állományról mond valamit. Az eredményt mindig a vizsgálat hatókörével együtt kell értékelni. [10][11]

WordPress: mit lehet ellenőrizni?

A WordPress hivatalos útmutatója a megbízható beszerzési forrásokat, a hozzáféréseket, a fájljogosultságokat és az üzemeltető számítógépének biztonságát is tárgyalja. A weboldal vizsgálata ezért az alaprendszer mellett a bővítményekre, sablonokra és a kapcsolódó környezetre is kiterjedhet. [12]

Fejlesztői vagy üzemeltetői környezetben a WP-CLI az alaprendszer fájljait a WordPress.org ellenőrzőösszegeivel tudja összehasonlítani. A bővítményekhez külön ellenőrzőparancs tartozik. [10][11]

Technikai magyarázat – ellenőrzőösszegek: A wp core verify-checksums az alaprendszer fájljainak ellenőrzésére szolgál. A wp plugin verify-checksums a bővítményfájlokat hasonlítja a WordPress.org által biztosított adatokhoz. Ha egy összetevőhöz nincs használható ellenőrzőösszeg, abból nem állapítható meg sem a tisztasága, sem a fertőzöttsége. A két parancs eredménye önmagában nem minősíti a teljes weboldalt, az adatbázist vagy a külső integrációkat. [10][11]

Szerkesztői szempontból ezt érdemes megjegyezni: a „WordPress-vírus” megnevezés még nem azonosít sem egy konkrét programot, sem a bejutás módját. A CMS neve a környezetet írja le; a kártékony működést külön kell megállapítani.

Joomla: sérülékeny bővítmény vagy kártékony csomag?

A Joomla hivatalos fejlesztői dokumentációja külön foglalkozik az XSS-sel, az SQL-injectionnel, a korlátozatlan fájlfeltöltéssel és a CSRF-fel. Ezek sérülékenységi, illetve támadási kategóriák; nem malware-családok. [13]

Egy feltöltési hiba például lehetővé teheti veszélyes fájl elhelyezését és bizonyos körülmények között kódfuttatását. Ilyenkor az eredeti hiba és az azon keresztül elhelyezett program külön vizsgálati tárgy. [13]

Kitalált összehasonlítás: egy jóhiszeműen készített komponens hibásan kezeli a feltöltést, és a támadó ezen keresztül programot helyez el. Másik esetben maga a telepített komponens tartalmaz szándékos hátsó kaput. Mindkettő veszélyes lehet, de csak a második példában része eleve a kártékony működés a telepített csomagnak.

Joomla-oldal vizsgálatánál ezért az érintett komponens, modul, plugin vagy sablon azonosítása után a tényleges működést és a hozzáféréseket is értékelni kell. A rendszer megnevezéséből még nem következik a diagnózis.

Mi a teendő, ha kártékony kód gyanúja merül fel?

A malware-incidensek kezelésében az észlelés és elemzés, a károk behatárolása, az eltávolítás és a helyreállítás külön feladat. A NIST malware-kezelési útmutatója ezt a megközelítést részletesen tárgyalja; az útmutató asztali és hordozható gépekre készült, ezért a konkrét weboldalas lépéseket a tárhelykörnyezethez kell igazítani. [14]

Az alábbi sorrend szerkesztett, általános kiindulópont; az intézkedések sürgőssége az eseménytől függ:

1. Rögzítsd a jelenséget. Pontos URL, időpont, riasztás és a tapasztalt működés legyen feljegyezve.
2. Őrizd meg a vizsgálathoz szükséges adatokat. A gyanús állományok és naplók megőrzése segíthet az eseménysor feltárásában. A fertőzött állapot másolatát elkülönítve kell kezelni.
3. Határozd meg az érintettséget. Mely fájlok, adatok, fiókok és környezetek kerülhettek veszélybe?
4. Korlátozd a folyamatban lévő károkozást. Ennek módját a működéshez és a rendelkezésre álló hozzáférésekhez kell választani.
5. Távolítsd el a kártékony összetevőket, és kezeld a bejutás útját. A két feladatot külön is ellenőrizni kell.
6. Ellenőrizd a helyreállított állapotot, majd figyeld a működést. A megmaradt bizonytalanságokat is rögzítsd.

Ez a lista nem helyettesíti az adott incidens vizsgálatát. A webshell, a módosított telepítő és a böngészőben futó idegen szkript eltérő beavatkozást igényelhet.

Miért nem elég egy frissítés vagy egy tiszta találati lista?

Egy sérülékenység javítása és egy korábban elhelyezett kártékony program eltávolítása külön feladat. A webshell például önálló hozzáférési eszközként szolgálhat a webkiszolgálón. [5]

Hasonlóképpen külön kell értékelni, mit ellenőrzött a vizsgálóeszköz. Egy alaprendszer-ellenőrzés eredményét nem lehet automatikusan az összes bővítményre, az adatbázisra vagy a külső szolgáltatásokra kiterjeszteni. A WP-CLI parancsainak dokumentációja is konkrét fájlcsoportokra határozza meg az ellenőrzést. [10][11]

A helyreállítás értékelésénél ezért a „nem talált hibát” állítás mellé oda kell tenni: mivel, mikor és pontosan mit vizsgáltak? Ez ad használható információt a további döntésekhez.

Hogyan csökkenthető a kockázat?

A WordPress biztonsági útmutatója a biztonságot kockázatcsökkentésként kezeli. A megbízható forrásból származó szoftverek, a karbantartás, az indokolt jogosultságok és a mentések egyaránt részei ennek. [12]

A szoftverellátási lánc oldaláról az összetevők eredete és a függőségek ismerete lényeges. A külső JavaScriptek esetében pedig azt is tudni kell, hogy melyik szolgáltató milyen kódot futtathat a látogatók böngészőjében. [6][7]

Tulajdonosként hasznos felkészülés, ha rendelkezésre áll az összetevők és hozzáférések nyilvántartása, ismert a mentések helye, és egy riasztás esetén egyértelmű, ki végzi a kivizsgálást. Az intézkedéseket az oldal működéséhez és az ott kezelt adatokhoz érdemes igazítani.

A következő rész: hátsó kapuk és webshell-ek

A malware típusa segít leírni a működést, de a tulajdonos következő kérdése gyakran az: hogyan juthat vissza a támadó? A sorozat következő részében ezért a hátsó kapukat és webshell-eket vizsgáljuk meg részletesen: mire használhatók, milyen nyomokat hagyhatnak, és miért fontos a teljes hozzáférési lánc feltárása.

Források

A példák kitalált szemléltető esetek, nem dokumentált ügyfélincidensek. A cikk rendszerezése és a gyakorlati sorrend szerkesztett összefoglaló. Forrásellenőrzés: 2026. október 19.

1. NIST: Malware.
2. NIST: Virus.
3. NIST: Worm.
4. NIST: Trojan horse.
5. MITRE ATT&CK: Web Shell – T1505.003.
6. OWASP: Third Party JavaScript Management.
7. OWASP: Software Supply Chain Security.
8. Google Search Central: Spam policies – hacked content.
9. OWASP: Logging.
10. WordPress: wp core verify-checksums.
11. WordPress: wp plugin verify-checksums.
12. WordPress: Hardening WordPress.
13. Joomla: Common Vulnerabilities.
14. NIST SP 800-83 Rev. 1 (2013): Guide to Malware Incident Prevention and Handling for Desktops and Laptops. Az általános incidenskezelési megközelítéshez; nem weboldalspecifikus útmutató.

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