Rosszindulatú botok a weboldaladon: ismeretlen címekre érkeznek kérések, sorozatosan próbálják a belépést, vagy reklámszövegek jelennek meg az űrlapban. Máskor csak annyi látszik, hogy nő a szerver terhelése, miközben nem érkezik több valódi érdeklődés.
Az automatizált forgalom sokféle célt szolgálhat. A bot szoftveresen hajt végre internetes feladatokat; lehet hasznos keresőrobot, ellenőrző eszköz vagy visszaélésre használt program is. Az automatizálás ténye önmagában nem jelenti azt, hogy feltörték a weboldalt. [1]
Cikksorozatunk hetedik részében a rosszindulatú botokat és automatizált visszaéléseket vesszük sorra. Megnézzük, mit érdemes keresni a naplókban, hogyan kapcsolódik ehhez az űrlapvédelem, és miért kell a védekezés eredménye mellett a valódi látogatók tapasztalatát is ellenőrizni.
Mi alapján nevezünk egy botot rosszindulatúnak?
A bot megnevezés a végrehajtás módjáról szól. A megítéléshez azt is vizsgálni kell, milyen feladatot végez, milyen hozzáférést használ, és milyen hatást okoz. A keresőrobotok például a weboldalak feltérképezését végzik; más programok ugyanazokat a funkciókat visszaélésre használhatják. [1]
Kitalált példa: egy rendelkezésreállást ellenőrző szolgáltatás rendszeresen lekéri a főoldalt, mert az üzemeltető ezt kérte. Egy másik program ugyanilyen rendszerességgel egy idegen felhasználó fiókjába próbál belépni. Mindkettő automatizált, a rendeltetésük és a szükséges intézkedésük azonban eltér.
Az OWASP külön kiemeli a rendes alkalmazásfunkciókkal végzett automatizált visszaéléseket. Ezek nem minden esetben egy programhiba kihasználására épülnek. [2]
Milyen célból érkezhetnek a botok?
Felderítés és sérülékenység-keresés
A felderítő automatizálás a webalkalmazás részeit, technológiáit vagy lehetséges gyengeségeit próbálhatja azonosítani. Az OWASP osztályozása megkülönbözteti a technológiai jellemzők felismerését, az alkalmazás feltérképezését és a sérülékenység-vizsgálatot. [2]
Kitalált példa: egy honlapon nem használt komponens címére ismétlődő kérések érkeznek. Ez vizsgálandó próbálkozás lehet, de nem bizonyítja, hogy a komponens telepítve van, a hiba kihasználható, vagy a támadó bejutott.
A naplóban szereplő próbálkozást és a sikeres jogosulatlan műveletet külön kell igazolni.
Belépési adatok kipróbálása
A jelszópróbálgatás és a credential stuffing különböző működés. Utóbbinál máshonnan megszerzett felhasználónév–jelszó párokat próbálnak ki. A password spraying kevés, gyakori jelszó sok fiókon történő kipróbálását jelenti. [3]
Ezek automatizálhatók, de a belépési támadások részletes vizsgálata külön témát igényel. Most a fontos különbség az, hogy a próbálkozások száma és a ténylegesen létrejött jogosulatlan belépések száma nem ugyanaz.
Űrlapspam és tömeges fióklétrehozás
Az OWASP az automatizált fenyegetések között a spamet, valamint a későbbi visszaélésre létrehozott tömeges fiókokat is felsorolja. [2]
Kitalált példa: egy bot kapcsolatfelvételi űrlapokat tölt ki reklámszöveggel. Másik esetben regisztrációkat hoz létre, amelyekkel később további műveleteket végezne. A két folyamat közös eszköze lehet az automatizálás, de eltérő műveletet kell korlátozni.
A megelőző részben bemutatott visszaigazolási visszaélés ide is kapcsolódik: egy szabályos értesítőfunkció sokszori kiváltása külön telepített malware nélkül is gondot okozhat.
Tartalom- és adatgyűjtés
A scraping tartalom vagy adatok automatizált kinyerése. A Cloudflare ismertetője a weboldalak szövegeinek és más tartalmainak begyűjtését is ebbe a körbe sorolja. [4]
A vizsgálatban a begyűjtött adatkör, a hozzáférés rendeltetése és a terhelés is számít. Nem minden automatizált tartalomlekérés azonos egy biztonsági betöréssel, és egy nyilvános oldal elérése sem írja le a későbbi felhasználást.
Kitalált példa: egy program végigjárja egy katalógus lapjait és ismételten letölti az adatokat. A működés hatásának értékeléséhez a lekérések ütemét, a kiszolgálás költségét és az elért adatokat kell összekapcsolni.
Készletek, foglalások és mérőszámok manipulálása
Az OWASP listájában készletek mesterséges lefoglalása, korlátozottan elérhető termékek tisztességtelen megszerzése és mérőszámok ismételt műveletekkel történő torzítása is szerepel. [2]
Kitalált példa: egy foglalási rendszerben tömeges, be nem fejezett foglalások miatt nem marad szabad időpont. Ebben a példában az üzleti folyamat korlátozása lehet a fő feladat, nem pusztán a főoldal lekéréseinek szűrése.
Mikor válik a forgalom túlterheléssé?
Az automatizált visszaélés terhelést is okozhat, de a kiesés lehet mellékhatás, nem feltétlenül a támadó elsődleges célja. Ezt az OWASP automatizált fenyegetésekről szóló leírása is hangsúlyozza. [2]
A szolgáltatásmegtagadás vizsgálatában az alkalmazás erőforrásigénye is számít. Egy költséges művelet ismétlése más terhelést jelenthet, mint ugyanannyi egyszerű oldalmegnyitás. Az OWASP ezért az alkalmazásszintű erőforrás-korlátokat is tárgyalja. [5]
A „sok kérés érkezett” megállapítás mellé oda kell tenni: milyen kérés, melyik funkcióra, milyen költséggel és milyen eredménnyel? A DDoS részletes működésével a sorozat későbbi része foglalkozik.
Mit árul el a napló, és mit nem?
A hasznos vizsgálati egység az eseménysor. A kérés idejét, útvonalát, eredményét és az alkalmazásban keletkező műveletet érdemes összekapcsolni. Az OWASP naplózási útmutatója a hitelesítési és jogosultsági eseményeket, hibákat és gyanús műveleteket is tárgyalja. [6]
| Megfigyelés | További vizsgálati kérdés |
|---|---|
| Sok kérés egy címre | Milyen műveletet és terhelést váltottak ki? |
| Ismeretlen URL-ekre adott 404 | Felderítés történt, hibás linket követtek, vagy más ok áll mögötte? |
| Ismétlődő belépési kérések | Mit rögzített a hitelesítési napló a sikerességről? |
| Sok űrlapbekérés | Hányat fogadott el az alkalmazás, és milyen hatással? |
| Több forrásból hasonló műveletsor | Van-e igazolható összefüggés a kérések között? |
A táblázat vizsgálati keret. Egy státuszkód vagy mintázat önmagában nem bizonyítja a kérés célját.
Kitalált példa: a belépési oldal sikertelen hitelesítés után is 200 válasszal jelenik meg. Ebben a példában a webszerver státuszkódjából nem állapítható meg a belépés sikere; az alkalmazás eseményét is ellenőrizni kell.
A User-Agent nem hiteles személyazonosság
A kérésben szereplő böngésző- vagy robotnév önmagában nem igazolja az eredetet. A Google külön ellenőrzési módszereket ad a saját robotjainak azonosításához: közzétett IP-tartományok, illetve megfelelő DNS-ellenőrzés is használható. [7]
Technikai magyarázat: A Google által leírt kézi ellenőrzésnél a fordított DNS-feloldás eredményét előre irányuló feloldással is össze kell vetni az eredeti IP-címmel. Egy tetszetős robotnév vagy egy részben hasonló domain nem elég. [7]
Proxy mögött a naplózott IP-t is értelmezni kell
A Cloudflare dokumentációja leírja a továbbított ügyfél-IP-t jelző fejléceket, köztük a CF-Connecting-IP használatát. A szerver felé továbbított kapcsolat és az eredeti látogató címe ezért külön adat lehet. [8]
Az ilyen fejlécet csak a megfelelően beállított, megbízható proxyútvonal részeként szabad értelmezni. A látogatói IP helytelen meghatározása a korlátozások és a vizsgálati következtetések alapját is elronthatja.
Kérésszám, látogatószám és űrlapbeküldés: külön mérőszámok
Egy védelem eredményét ahhoz kell kötni, pontosan milyen eseményt mér. A Turnstile Analytics például a widget működéséhez kapcsolódó statisztikákat mutatja. A tokenellenőrzési nézet a szerver által sikeresen és sikertelenül ellenőrzött tokenekről ad adatot. [9][10]
Ezek a számok önmagukban nem azonosak a sikeresen mentett űrlapokkal. Az üzleti eredményt az alkalmazás saját feldolgozási adataival kell összekapcsolni.
Kitalált példa: egyetlen látogató újratölti az oldalt, később kitölti az űrlapot, majd egy mezőhiba miatt újra beküldi. A különböző mérési pontokon eltérő eseményszám keletkezhet. Ebből önmagában nem lehet több külön emberre vagy több sikeres jelentkezésre következtetni.
Technikai magyarázat: A Cloudflare szerint a sok érvénytelen token oka lehet bottevékenység, lejárt token vagy megvalósítási hiba is. A sikertelen ellenőrzést ezért a hibakóddal és az alkalmazás feldolgozási eredményével együtt kell értékelni. [10]
Hogyan épülhet fel a botvédelem?
A védelem célja az érintett művelet korlátozása és a szabályos használat fenntartása. Az OWASP több réteg együttes alkalmazását javasolja: hálózati vagy peremvédelmet, alkalmazásszintű ellenőrzéseket és az üzleti folyamat szabályait. [11]
Célzott sebesség- és mennyiségi korlátozás
A rate limiting megadott feltételek szerint korlátozza a kérések gyakoriságát. A Cloudflare szabályaiban is az ellenőrzött forgalom, a számlálás és az intézkedés feltételeit kell meghatározni; a funkciók a használt szolgáltatástól függnek. [12]
Az OWASP szerint az IP-cím mellett munkamenethez, fiókhoz vagy konkrét végponthoz kötött korlátok is indokoltak lehetnek. [11]
Kitalált példa: egy belépési műveletre szigorúbb határ vonatkozik, mint a nyilvános cikkek olvasására. A beállítás ellenőrzésénél a jogos ismétléseket és az egymással közös kapcsolatot használó látogatókat is figyelembe kell venni.
A HTTP 429 Too Many Requests válasz a túl sok kérés jelzésére szolgál; Retry-After fejléc is kísérheti. Önmagában ez a válasz sem mondja meg, hogy a kliens rosszindulatú-e. [13]
CAPTCHA és Turnstile: a szerveroldali döntés is szükséges
A Cloudflare dokumentációja kifejezetten előírja a Turnstile-token szerveroldali ellenőrzését. A kliensoldali widget megjelenítése önmagában nem teljes megvalósítás: a feldolgozó végpontnak a Siteverify válaszát is értékelnie kell. [14]
Technikai magyarázat: A Turnstile-token öt percig érvényes és egyszer használható. Az ismételt vagy lejárt token
timeout-or-duplicatehibát eredményezhet. Hosszabb űrlapkitöltésnél és újraküldésnél ezért a token megfelelő megújítását is ellenőrizni kell. [14]
A widget sikeres ellenőrzése és az üzleti szabályok teljesülése külön feltétel. Egy beküldésnél továbbra is szükség lehet az adatok, jogosultságok és mennyiségi korlátok ellenőrzésére.
Honeypot és viselkedési jelek
Az OWASP a honeypotot is lehetséges ellenőrzésként tárgyalja: egy rendes használatban nem kitöltendő mező viselkedési jelet adhat. A módszert más kontrollokkal együtt kell értékelni. [11]
Szerkesztői javaslat: ne egyetlen merev időhatárból vagy egyetlen mezőből próbáld megállapítani, ki a valódi látogató. A döntés okát érdemes rögzíteni, és szabályos tesztekkel ellenőrizni, hogyan működik a védelem automatikus kitöltés, javítás és újraküldés mellett.
Miért nem biztonsági fal a robots.txt?
A robots.txt a feltérképezésre vonatkozó szabályokat közli az azt követő robotokkal. A Google dokumentációja szerint nem alkalmas bizalmas oldalak hozzáférés-védelmére, és nem minden kliens tartja tiszteletben. [15]
Ezért egy tiltott útvonal technikai elérhetőségét külön kell kezelni. Az indexelési vagy feltérképezési szabályzat nem helyettesíti a hitelesítést, jogosultság-ellenőrzést vagy a túlzott forgalom korlátozását.
A szabályos robotok engedélyezését és a káros működés szűrését a weboldal céljaihoz kell igazítani. Egy általános tiltás előtt azt is ellenőrizni kell, mely szükséges szolgáltatások használják az érintett útvonalakat.
WordPress: a védendő műveletet keresd
A WordPress hivatalos útmutatója külön foglalkozik a belépési próbálkozásokkal és a védekezési lehetőségekkel. [16] Egy oldalon azonban a belépés mellett a regisztráció, űrlap, kereső vagy bővítmény által kínált művelet is vizsgálati terület lehet.
A REST API hitelesítési módjai között sütialapú hitelesítés és alkalmazásjelszó is szerepel. A szükséges integrációkat ezért azonosítani kell, mielőtt az API egészét érintő korlátozás készül. [17]
Kitalált példa: a kapcsolatfelvételi oldalon látszik a botvédelmi widget, de a feldolgozó végpont közvetlen kérést is elfogad ellenőrzés nélkül. A védelem értékeléséhez a felület mellett a tényleges műveletvégzés helyét is ellenőrizni kell.
Joomla: az űrlap és a feldolgozó komponens együtt számít
A Joomla dokumentációja többek között az XSS-, SQL-injection-, fájlfeltöltési és CSRF-kockázatokat külön tárgyalja. Ezek a hibák és az automatizált visszaélés eltérő szempontok: egy bot kihasználhat hibát, de szabályos funkciót is ismételhet káros módon. [18]
Kitalált példa: egy modul megjeleníti az űrlapot, de a beküldést egy komponens végzi. Az ellenőrzésnek arra is ki kell terjednie, hogy a komponens minden érintett beküldési útvonalon végrehajtja-e a szükséges vizsgálatokat.
A szabályos kitöltést és a közvetlenül a feldolgozóhoz érkező kérést is tesztelni kell. A telepített bővítmény neve önmagában nem mutatja meg a teljes védelmi láncot.
A téves elutasítás is mérendő eredmény
Az OWASP botvédelmi útmutatója a válaszstratégiát és a megfigyelést is a védelem részének tekinti. Nem minden helyzetben az azonnali tiltás az egyetlen lehetőség. [11]
Szerkesztett ellenőrzési munkamenet:
- Határozd meg, milyen visszaélést akarsz korlátozni, és hol történik a művelet.
- Rögzíts összehasonlítható adatokat a forgalomról és a tényleges eredményről.
- Válassz az adott művelethez illő kontrollt, és teszteld a rendes használatot.
- Naplózd a döntést, a hibakódot és az alkalmazás feldolgozási eredményét érzékeny adatok felesleges gyűjtése nélkül.
- Ellenőrizd a javítást, újraküldést és a látogató számára megjelenő hibaüzenetet is.
- Az észlelt visszaélés és a téves elutasítás alapján módosíts a szabályokon.
A célzott intézkedés értékeléséhez a naplóbejegyzések és a tényleges szolgáltatási eredmények együtt adnak alapot. A sok blokkolás önmagában nem mutatja meg, hogy a szükséges látogatói műveletek rendben működnek-e.
A következő rész: belépési támadások és megszerzett jelszavak
A következő részben a jelszópróbálgatást, password sprayinget és credential stuffingot vizsgáljuk részletesebben. Megnézzük, milyen mintázatok különböztetik meg ezeket, és hogyan kapcsolódik a fiókvédelemhez a többtényezős hitelesítés és a hozzáférések kezelése.
Források
Forrásellenőrzés: 2026. november 4. A példák kitalált szemléltető esetek. A vizsgálati táblázat és az ellenőrzési munkamenet szerkesztett javaslatok. A konkrét forgalom célját és az intézkedések hatását az adott rendszer adatai alapján kell megállapítani.
- Cloudflare: What is a bot?.
- OWASP: Automated Threats to Web Applications – ontology.
- OWASP: Credential Stuffing Prevention.
- Cloudflare: Content scraping.
- OWASP: Denial of Service.
- OWASP: Logging.
- Google Crawling Infrastructure: Verify requests from Google crawlers and fetchers.
- Cloudflare: HTTP headers.
- Cloudflare: Turnstile Analytics.
- Cloudflare: Turnstile token validation analytics.
- OWASP: Bot Management and Anti-Automation.
- Cloudflare: Rate limiting rules.
- RFC 6585: Additional HTTP Status Codes – 429 Too Many Requests.
- Cloudflare: Turnstile server-side validation.
- Google Search Central: Introduction to robots.txt.
- WordPress: Brute Force Attacks.
- WordPress REST API: Authentication.
- Joomla: Common Vulnerabilities.
Ha gyanús, hogy weboldalad vírusos vagy feltört, segítünk a helyreállításban !