Weboldal-biztonsági ellenőrzőlista: 20 dolog, amit azonnal ellenőrizni kell

A kibertámadások már nem kizárólag a Fortune 500-as vállalatok és kormányzati szervek célpontjai. A Verizon Data Breach Investigations Reportja szerint 2025-ben az összes rögzített adatbiztonsági incidens 43%-a kis- és középvállalkozásokat érintett. A támadók tudják, hogy a kisebb szervezetek gyakran nem rendelkeznek dedikált biztonsági csapattal, így könnyű célpontot jelentenek az éjjel-nappal az internetet pásztázó automatizált exploit készletek számára. Egyetlen feltört kapcsolatfelvételi űrlap vagy elavult bővítmény felfedheti az ügyféladatokat, ronthatja a keresőoptimalizációs helyezéseit, és olyan szabályozási bírságokat vonhat maga után, amelyek messze meghaladják a megelőzés költségét.

A GRADAX-nál első kézből láttuk a következményeket. Egy regionális e-kereskedelmi áruházat üzemeltető ügyfél azután keresett meg minket, hogy a fizetési oldalára egy hitelkártya-adatlopó került, amely tizenegy napig észrevétlenül működött. Az anyagi kár jelentős volt, de a hírnévkár súlyosabb, a visszatérő vásárlók aránya 38%-kal esett a nyilvánosságra hozatalt követő negyedévben. Ez az eset egy olyan elvet kristályosított ki, amelyet most minden projektre alkalmazunk: a biztonság infrastruktúra, nem utólagos gondolat.

Ez az ellenőrzőlista összefoglalja azt a húsz leghatékonyabb biztonsági intézkedést, amelyet hosting- és webfejlesztési projektjeink során alkalmazunk. Nincs szüksége hatjegyű biztonsági költségvetésre ezek végrehajtásához. A legtöbb egyetlen délután alatt elvégezhető, és együtt kiküszöbölik a valós fenyegetéseket jelentő támadási vektorok túlnyomó többségét. Akár saját szervereket kezel, akár menedzselt hosting szolgáltatóra támaszkodik, ezek az ellenőrzések Önre is vonatkoznak.

Weboldala minden egyes oldalának HTTPS-en keresztül kell betöltődnie érvényes SSL-tanúsítvánnyal. Ez 2026-ban megkérdőjelezhetetlen. A böngészők a HTTP-oldalakat nem biztonságosként jelölik meg, a keresőmotorok rangsorolási hátrányba helyezik őket, és a titkosítás nélkül továbbított adatok, bejelentkezési adatok, űrlapbeküldések, fizetési adatok, bárki által elfoghatók ugyanazon a hálózaton. A Let's Encrypt ingyenes tanúsítványai megszüntették a költséget kifogásként, így nincs ok a halogatásra.

A tanúsítvány telepítésén túl ellenőrizze, hogy a szerver kikényszeríti-e a HTTPS-t az összes HTTP-kérés 301-es átirányítással történő átirányításával. Ellenőrizze, hogy a HSTS (HTTP Strict Transport Security) fejléc be van-e állítva legalább egyéves max-age értékkel, és tartalmazza-e az includeSubDomains direktívát. Ez azt jelzi a böngészőknek, hogy mindig HTTPS-en keresztül csatlakozzanak, még akkor is, ha a felhasználó a protokoll előtag nélkül írja be az URL-t. Javasoljuk továbbá, hogy adja hozzá domainjét a böngészőgyártók által karbantartott HSTS preload listához, amely közvetlenül a Chrome-ba, Firefoxba és Safariba építi be a HTTPS-követelményt.

A gyakori buktatók közé tartoznak a vegyes tartalom figyelmeztetések, amikor egy oldal HTTPS-en töltődik be, de HTTP-n keresztül hivatkozik képekre, szkriptekre vagy stíluslapokra. Futtasson bejárást olyan eszközzel, mint a Screaming Frog, vagy használja a böngésző fejlesztői konzolját a vegyes tartalom problémák azonosításához. Minden erőforrásnak, betűtípusoknak, analitikai szkripteknek, beágyazott iframe-eknek, API-végpontoknak, HTTPS URL-eket kell használnia. Egyetlen HTTP-erőforrás eltüntetheti a lakatot és alááshatja a látogatók bizalmát.

Az elavult szoftver a web egyetlen leginkább kihasznált támadási vektora. A WordPress mag, a bővítmények, a témák, a szerver operációs rendszerek, a PHP futtatókörnyezetek, az adatbázis-motorok, a verem minden rétege rendszeresen kap biztonsági javításokat, és minden javítatlan komponens egy dokumentált sebezhetőség, amelyet a támadók kész eszközökkel kihasználhatnak. Az Equifax adatszivárgást, amely 147 millió rekordot érintett, egyetlen javítatlan Apache Struts függőség okozta. A méret nem előfeltétele a katasztrófának.

Fegyelmezett frissítési ütemtervet javasolunk: kritikus biztonsági javítások a kiadástól számított 24 órán belül, minden egyéb frissítés hét napon belül. WordPress oldalak esetén legalább az automatikus kisebb és biztonsági frissítéseket engedélyezze. Egyedi alkalmazások esetén integrálja a függőségvizsgálatot a telepítési folyamatába, az olyan eszközök, mint a Dependabot, Snyk vagy Renovate, még a termelésbe kerülés előtt jelzik a sebezhető csomagokat. Ha a mi menedzselt hostingunkon fut, az operációs rendszer és futtatókörnyezet javításokat automatikusan kezeljük, de az alkalmazásszintű függőségek az Ön felelőssége maradnak.

Tesztelje a frissítéseket egy staging környezetben, mielőtt éles környezetben alkalmazná őket. Láttunk már jó szándékú biztonsági javításokat, amelyek tönkretették a fizetési átjárókat, kapcsolatfelvételi űrlapokat és hitelesítési folyamatokat, mert egy bővítményfrissítés inkompatibilitást okozott. Egy ötperces staging teszt megelőzhet egy ötórás éles rendszer kiesést. Ha a hosting szolgáltatója nem kínál egy kattintással elérhető staging környezetet, az önmagában is elég ok arra, hogy fontolóra vegye a váltást egy olyan szolgáltatóra, amely igen.

A jelszavak továbbra is a leggyengébb láncszemet jelentik a legtöbb biztonsági láncban. A credential stuffing támadások, amikor a támadók más adatszivárgásokból kiszivárgott felhasználónév-jelszó kombinációkat tesztelnek, a bejelentkezéssel kapcsolatos támadások több mint 60%-át teszik ki. Ha a WordPress adminisztrátor jelszava „company2024” vagy az adatbázis root jelszava „password123”, gyakorlatilag nyitva hagyja a bejárati ajtót. Minden fióknak, amely hozzáfér a weboldal-infrastruktúrájához, egyedi, legalább tizenhat karakteres jelszót kell használnia, amelyet jelszókezelő generál.

A többtényezős hitelesítés (MFA) a leghatékonyabb védelem a jogosulatlan hozzáférés ellen. Még ha egy támadó adathalászat vagy adatszivárgás révén meg is szerez egy érvényes jelszót, a második tényező nélkül nem tud bejelentkezni. Tárhelyplatformunkon minden admin fiókon kikényszerítjük az MFA-t, és erősen javasoljuk ügyfeleinknek, hogy tegyék ugyanezt a CMS-ük, domainregisztrátoruk, DNS-szolgáltatójuk, e-mail fiókjuk és minden olyan SaaS-eszköz esetében, amely hozzáfér az éles adatokhoz. Az olyan hitelesítő alkalmazások, mint az Authy, vagy a hardverkulcsok, mint a YubiKey, sokkal biztonságosabbak, mint az SMS-alapú kódok, amelyek sebezhetők a SIM-kártyacsere támadásokkal szemben.

Korlátozza a bejelentkezési kísérletek számát zárolás vagy CAPTCHA-kihívás indítása előtt. Öt sikertelen kísérlet tíz percen belül tizenöt percre zárja a fiókot, vagy emberi ellenőrzést igényel. Ez az egyszerű intézkedés azonnal megállítja a brute-force támadásokat. Negyedévente vizsgálja felül az adminisztrátor felhasználói listáját is: távolítsa el a volt alkalmazottak, szerződő partnerek és olyan ügynökségek fiókjait, amelyekkel már nem dolgozik. Minden aktív fiók egy támadási felület.

A biztonsági mentések jelentik az utolsó védelmi vonalat, amikor minden más kudarcot vall. A zsarolóvírus titkosítja a fájlokat, egy rosszindulatú bővítmény törli az adatbázist, egy fejlesztő véletlenül törli az éles feltöltési mappát, megbízható, tesztelt biztonsági mentés nélkül ezek bármelyike végleges adatvesztést jelenthet. A kérdés nem az, hogy szüksége van-e biztonsági mentésekre, hanem hogy a jelenlegi biztonsági mentési stratégiája valóban megmentené-e egy válság esetén.

Kövesse a 3-2-1 szabályt: tartson legalább három másolatot az adatairól két különböző adathordozón, és az egyik példányt tárolja külső helyen. Weboldalak esetében ez automatizált napi biztonsági mentéseket jelent ugyanazon a szerveren (a gyors visszaállítás érdekében), amelyek replikálódnak egy külön szerverre vagy felhőtárhelyre (a redundancia érdekében), valamint archiválásra kerülnek egy földrajzilag távoli helyre (a katasztrófa utáni helyreállítás érdekében). Mentési és helyreállítási infrastruktúránk harminc napig napi pillanatképeket, három hónapig heti pillanatképeket, egy évig pedig havi pillanatképeket őriz meg.

A legkritikusabb és leggyakrabban elhanyagolt lépés a biztonsági mentések tesztelése. Egy olyan mentés, amelyet soha nem állítottak vissza, nem bízható meg. Ütemezzen negyedéves visszaállítási gyakorlatot, amely során a legutóbbi mentésből indít egy staging környezetet, és ellenőrzi, hogy az oldal megfelelően betöltődik-e, az adatbázis sértetlen-e, a felhasználói feltöltések megvannak-e, és minden funkció működik-e. Találkoztunk olyan ügyfelekkel, akiknek a mentési feladatai hónapokig csendben meghiúsultak, mert elfogyott a lemezterület, vagy lejártak a hitelesítő adatok. Ezt egy gyakorlat során fedezze fel, ne egy incidens közben.

A webalkalmazás-tűzfal (WAF) a weboldala és az internet között helyezkedik el, szűrve a bejövő forgalmat, hogy blokkolja az ismert támadási mintákat, mielőtt azok elérnék az alkalmazását. Megállítja az SQL-injektációs kísérleteket, a cross-site scripting hasznos terheket, a könyvtárbejárási támadásokat és több tucat más kihasználási technikát, amelyeket az automatizált szkenerek folyamatosan keresnek. WAF nélkül az alkalmazáskódja az egyetlen védelmi vonal, és egyetlen figyelmen kívül hagyott beviteli mező is lehet a behatolás belépési pontja.

Párosítsa a WAF-ot rendszeres kártevőkereséssel. A szerveroldali szkenerek, mint a ClamAV, a Maldet vagy a Sucuri és Wordfence kereskedelmi megoldásai, átvizsgálják a fájlrendszerét ismert rosszindulatú aláírások, gyanús fájlmódosítások és backdoor szkriptek után kutatva, amelyeket a támadók a tartós hozzáférés érdekében helyeznek el. Ütemezze a vizsgálatokat naponta, és állítson be riasztásokat minden észlelésre. Javasoljuk továbbá a fájlintegritás-figyelést, amely a kritikus fájlok ellenőrzőösszegét (checksum) követi nyomon. A WordPress alapfájljai, konfigurációs fájlok és szerver binárisok figyelése azonnal riaszt, ha bármely fájl váratlanul megváltozik.

Hálózati szinten állítsa be a szerver tűzfalát úgy, hogy csak azokat a portokat és protokollokat engedélyezze, amelyekre az alkalmazásának valóban szüksége van. Egy tipikus webszervernek a 443-as portot (HTTPS), a 80-as portot (HTTP, csak átirányításhoz) és az SSH-portot kell nyitva tartania. Minden mást, adatbázis-portokat, adminisztrációs paneleket, fejlesztőeszközöket, blokkolni kell a nyilvános hozzáféréstől, és csak VPN-en vagy SSH-alagúton keresztül szabad elérni. Ez az egyszerű megerősítési lépés a támadások egész kategóriáit szünteti meg, amelyek a kiexponált szolgáltatásokra támaszkodnak.

A legkisebb jogosultság elve az információs biztonság egyik legrégebbi szabálya, mégis rendszeresen megsértik. Minden felhasználónak, szolgáltatásfióknak és API-kulcsnak a funkciója ellátásához szükséges minimális jogosultságokkal kell rendelkeznie, semmi többel. Egy tartalomszerkesztőnek nincs szüksége bővítmények telepítésére. Egy staging környezetnek nincs szüksége éles adatbázis-hitelesítő adatokra. Egy harmadik féltől származó analitikai szkriptnek nincs szüksége írási hozzáférésre a DOM-hoz.

Legalább negyedévente vizsgálja felül a WordPress felhasználói szerepköröket, a tárhelykezelő panelhez való hozzáférést és a szerver SSH-kulcsait. Távolítsa el vagy csökkentse minden olyan fiók jogosultságait, amely több jogosultsággal rendelkezik, mint amennyire szüksége van. Fejlesztőcsapatok esetében használjon szerepkör-alapú hozzáférés-vezérlést névvel ellátott fiókokkal, de soha ne osszon meg egyetlen adminisztrátori hitelesítő adatot több ember között. A megosztott fiókok lehetetlenné teszik annak nyomon követését, hogy ki hajtott végre egy változtatást, ami kritikus fontosságú az incidensvizsgálat során, és amelyet a legtöbb megfelelőségi keretrendszer, köztük a GDPR és a PCI DSS megkövetel.

Az API-kulcsok és a szolgáltatási hitelesítő adatok ugyanilyen alapos vizsgálatot érdemelnek. Cserélje le őket legalább évente, és azonnal, miután bármely hozzáféréssel rendelkező csapattag elhagyja a szervezetet. Tárolja őket környezeti változókban vagy egy secrets managerben, soha ne a verziókövetésbe feltöltött forráskódban vagy konfigurációs fájlokban. Egyetlen kiszivárgott API-kulcs egy nyilvános GitHub-tárolóban percek alatt felfedezhető és kihasználható, az automatizált botok folyamatosan keresik az ilyeneket.

A biztonsági megfigyelés a védekezést passzív akadályokból aktív észlelési rendszerré alakítja. Állítson be központosított naplózást, amely rögzíti a bejelentkezési kísérleteket, a fájlváltozásokat, a jogosultságmódosításokat, a hibaarányokat és a kimenő hálózati kapcsolatokat. Táplálja ezeket a naplókat egy megfigyelési platformba, amely korrelációs szabályokat és anomáliadetektálást alkalmaz. A sikertelen bejelentkezési kísérletek hirtelen megugrása egyetlen IP-tartományból, egy váratlan új PHP-fájl a feltöltési könyvtárában vagy egy szokatlan kimenő kapcsolat egy külföldi szerverhez, ezek a behatolást megelőző korai figyelmeztető jelek.

Ugyanilyen fontos, hogy legyen incidenskezelési terve, mielőtt szüksége lenne rá. Dokumentálja azokat a lépéseket, amelyeket a csapata követni fog, amikor behatolást észlelnek: kit értesítenek, hogyan izolálják az érintett rendszert, hol őrzik meg a kriminalisztikai bizonyítékokat, hogyan tájékoztatják az ügyfeleket, és mikor kell a bűnüldöző szerveket vagy a szabályozókat értesíteni. Gyakorolja ezt a tervet legalább évente kétszer. Tapasztalataink szerint azok a szervezetek, amelyek tesztelt incidenskezelési tervvel rendelkeznek, 60%-kal gyorsabban oldják meg a behatolásokat, és jelentősen kisebb pénzügyi és hírnévbeli kárt szenvednek, mint azok, amelyek nyomás alatt improvizálnak.

Ha mindezek kezelése túlnyomasztónak tűnik, ez megerősíti, miért fontos olyan szolgáltatóval dolgozni, amely beépíti a biztonságot az infrastruktúrájába. A GRADAX-nál minden tárhelycsomag alapfunkcióként tartalmazza az automatizált javítást, a napi kártevőkeresést, a WAF-védelmet és a 24/7 megfigyelést. A biztonság nem felár, hanem az alap. Ha jelenlegi szolgáltatója opcionálisként kezeli, vegye fel velünk a kapcsolatot, és megmutatjuk, hogyan néz ki a proaktív biztonság a gyakorlatban.