Weboldal biztonság: 8 lépés a biztonságos weboldalért

Miért kritikus fontosságú a weboldal biztonság?

A weboldal biztonsági incidensek száma évről évre növekszik, és a kis- és középvállalkozások egyre gyakrabban válnak célponttá. A támadók jól tudják, hogy a KKV-k gyakran nem rendelkeznek dedikált IT-biztonsági csapattal, és a védelmi intézkedéseik is hiányosak lehetnek. Egy sikeres támadás következményei súlyosak: adatvesztés, ügyfélbizalom elvesztése, GDPR-bírságok, bevételkiesés és a márka hírnevének sérülése.

A jó hír az, hogy a weboldalak elleni támadások túlnyomó többsége megelőzhető alapvető biztonsági intézkedésekkel. Ebben a cikkben 8 konkrét lépést mutatunk be, amelyekkel jelentősen növelheti weboldala biztonságát – még akkor is, ha nem rendelkezik mély technikai ismeretekkel.

1. lépés: SSL/HTTPS bevezetése

Az SSL tanúsítvány (Secure Sockets Layer) titkosítja a weboldala és a látogatók közötti adatforgalmat. Ez azt jelenti, hogy ha valaki megpróbálja lehallgatni a kommunikációt – például egy nyilvános Wi-Fi hálózaton –, nem tudja elolvasni az átvitt adatokat (jelszavak, személyes adatok, bankkártya információk).

Az SSL nem luxus, hanem alapvető követelmény. A Google 2014 óta rangsorolási tényezőként kezeli az HTTPS-t, a Chrome böngésző pedig „Nem biztonságos" felirattal jelöli azokat az oldalakat, amelyek nem használják. Ráadásul a GDPR szempontjából is elvárás a személyes adatok titkosított átvitele.

A legtöbb tárhelyszolgáltató ingyenes SSL tanúsítványt biztosít a Let's Encrypt szolgáltatáson keresztül. Ha az Ön tárhelye nem kínálja ezt, fontolja meg a váltást. A Cloudflare szintén ingyenes SSL-t biztosít, és egyúttal CDN és DDoS védelem is jár hozzá.

2. lépés: Erős jelszavak és kétfaktoros hitelesítés (2FA)

A gyenge jelszavak a leggyakoribb belépési pontok a támadók számára. A „jelszo123" vagy a „cegnev2024" típusú jelszavak másodpercek alatt feltörhetők brute force támadással.

Az erős jelszópolitika alapelvei:

• Legalább 12 karakter hosszúság, nagy- és kisbetűk, számok és speciális karakterek keveréke.
• Minden fiókhoz egyedi jelszó – soha ne használja ugyanazt a jelszót több helyen.
• Használjon jelszókezelőt (Bitwarden, 1Password, LastPass), amely generálja és tárolja az erős jelszavakat.
• Rendszeres jelszócsere – legalább félévente változtassa meg a legfontosabb jelszavakat.

A kétfaktoros hitelesítés (2FA) egy további védelmi réteget ad: a jelszón kívül egy második azonosítót is kér (például egy SMS-kódot vagy egy autentikátor alkalmazás által generált kódot). Még ha a jelszó kompromittálódik is, a 2FA nélkül a támadó nem tud belépni. Állítsa be a 2FA-t minden kritikus fióknál: tárhelyszolgáltatás, domain kezelő, CMS admin felület, e-mail fiók.

3. lépés: Rendszeres frissítések

A szoftverfrissítések nem csupán új funkciókról szólnak – a biztonsági javítások a legfontosabb elemük. A támadók aktívan keresik és kihasználják az ismert sebezhetőségeket elavult szoftverekben.

Ha WordPress vagy más CMS-t használ, különösen fontos:

• A CMS core frissítése amint elérhető egy új verzió.
• Minden bővítmény (plugin) és sablon (theme) naprakészen tartása.
• A nem használt bővítmények és sablonok eltávolítása, ne csak deaktiválása.
• A PHP verzió frissítése a szerveren.
• Az operációs rendszer és egyéb szerverszoftverek frissítése.

Állítson be automatikus frissítéseket ahol lehetséges, vagy legalább heti rendszerességgel ellenőrizze a frissítéseket. Fontos: frissítés előtt mindig készítsen biztonsági mentést!

4. lépés: Biztonsági mentési stratégia

A biztonsági mentés (backup) az utolsó védvonal. Ha minden más védelmi intézkedés kudarcot vall, a friss backup lehetővé teszi a gyors helyreállítást.

A hatékony backup stratégia elemei:

• Rendszeres mentés – A mentés gyakorisága az oldal frissítési gyakoriságától függ. Egy aktív webáruház esetén napi mentés szükséges, egy ritkán frissített céges oldalnál heti is elegendő.
• 3-2-1 szabály – Legalább 3 másolat, 2 különböző adathordozón, 1 külső helyen (off-site). Ne csak a tárhelyszolgáltató szerverén tárolja a mentéseket!
• Automatizálás – A manuális mentésre nem lehet számítani. Használjon automatikus mentési megoldást.
• Visszaállítás tesztelése – A backup csak akkor ér valamit, ha működik a visszaállítás. Negyedévente tesztelje a helyreállítási folyamatot.
• Adatbázis és fájlok együtt – Gondoskodjon arról, hogy mind az adatbázis, mind a fájlrendszer mentésre kerüljön.

5. lépés: WAF (Web Application Firewall) bevezetése

A Web Application Firewall (webalkalmazás tűzfal) szűri a weboldalához érkező forgalmat, és blokkolja a gyanús vagy rosszindulatú kéréseket még azelőtt, hogy azok elérnék a szervert.

A WAF védelmet nyújt többek között:

• SQL injection támadások ellen
• Cross-Site Scripting (XSS) támadások ellen
• Brute force (jelszópróbálkozó) támadások ellen
• Rosszindulatú botok ellen
• Ismert sebezhetőségek kihasználási kísérletei ellen

A Cloudflare ingyenes szintje alapszintű WAF védelmet biztosít, ami egy KKV számára kiváló kiindulópont. Komolyabb védelemért érdemes a fizetős szinteket vagy dedikált WAF megoldásokat (Sucuri, Wordfence) fontolóra venni.

6. lépés: DDoS védelem

A DDoS (Distributed Denial of Service) támadás célja, hogy a weboldalt elérhetetlenné tegye azáltal, hogy hatalmas mennyiségű hamis forgalommal árasztja el. Egy sikeres DDoS támadás akár napokra is leállíthatja a weboldalt, ami jelentős bevételkiesést okozhat.

A DDoS elleni védekezés lehetőségei:

• CDN használata – A Cloudflare, Fastly és hasonló CDN szolgáltatók automatikus DDoS védelmet nyújtanak, mivel a forgalmat a saját globális hálózatukon keresztül szűrik.
• Rate limiting – Korlátozza az egy IP-címről érkező kérések számát adott időszakon belül.
• Skálázható infrastruktúra – A felhőalapú tárhelymegoldások (AWS, Google Cloud, Azure) rugalmasan skálázhatók, ami segít ellenállni a forgalomnövekedésnek.

7. lépés: SQL injection és XSS megelőzése

Ezek a támadások a webalkalmazások leggyakoribb sebezhetőségeit célozzák meg.

SQL injection

Az SQL injection során a támadó rosszindulatú SQL kódot juttat be a webalkalmazás adatbázis-lekérdezéseibe, általában űrlapmezőkön vagy URL paramétereken keresztül. Ezzel hozzáférhet az adatbázis tartalmához, módosíthatja vagy törölheti az adatokat.

Megelőzés:

• Használjon paraméteres lekérdezéseket (prepared statements) a nyers SQL lekérdezések helyett.
• Érvényesítse és szanitizálja minden felhasználói inputot – soha ne bízzon meg a böngészőből érkező adatokban.
• Alkalmazza a legkisebb jogosultság elvét az adatbázis felhasználók számára.

Cross-Site Scripting (XSS)

Az XSS támadás során a támadó rosszindulatú JavaScript kódot juttat be a weboldalba, amely a látogatók böngészőjében fut le. Ezzel ellophatja a felhasználók sütikeit, átirányíthatja őket adathalász oldalakra, vagy módosíthatja az oldal tartalmát.

Megelőzés:

• Minden felhasználói input kódolása (encoding) a megjelenítés előtt.
• Content Security Policy (CSP) fejléc beállítása, amely korlátozza, milyen forrásból tölthet be szkripteket a böngésző.
• A HttpOnly és Secure süti attribútumok használata.

8. lépés: Biztonsági fejlécek beállítása

A HTTP biztonsági fejlécek további védelmi rétegeket adnak a weboldalhoz, és beállításuk viszonylag egyszerű:

• Content-Security-Policy (CSP) – Meghatározza, milyen forrásokból tölthet be erőforrásokat a böngésző. Ez az XSS elleni védelem egyik leghatékonyabb eszköze.
• X-Content-Type-Options: nosniff – Megakadályozza, hogy a böngésző megpróbálja kitalálni a fájlok típusát, ami biztonsági kockázatot jelenthet.
• X-Frame-Options: DENY – Megakadályozza, hogy az Ön weboldalát más oldalak beágyazzák iframe-ben (clickjacking elleni védelem).
• Strict-Transport-Security (HSTS) – Utasítja a böngészőt, hogy mindig HTTPS-en keresztül csatlakozzon az oldalhoz.
• Referrer-Policy – Szabályozza, mennyi információt oszt meg a böngésző a hivatkozó oldalról.
• Permissions-Policy – Korlátozza, milyen böngésző API-khoz férhet hozzá az oldal (kamera, mikrofon, geolokáció).

A biztonsági fejlécek állapotát a securityheaders.com oldalon ellenőrizheti ingyenesen.

Monitoring és riasztások

A megelőzés mellett fontos a folyamatos figyelés (monitoring) is, hogy minél hamarabb észlelje a biztonsági incidenseket:

• Uptime monitoring – Értesítést kap, ha a weboldala elérhetetlenné válik (UptimeRobot, Pingdom).
• Fájlintegritás-ellenőrzés – Figyeli, ha a weboldal fájljai módosulnak (Wordfence, Sucuri).
• Bejelentkezési kísérletek naplózása – Értesítés sikertelen bejelentkezési kísérletekről.
• Sebezhetőség-ellenőrzés – Rendszeres automatikus vizsgálat ismert sebezhetőségekre.
• SSL tanúsítvány lejárat figyelése – Értesítés, mielőtt lejárna a tanúsítvány.

Állítson be e-mail vagy SMS értesítéseket a kritikus eseményekre, hogy azonnal reagálhasson.

Incidenskezelési terv

Minden vállalkozásnak érdemes rendelkeznie egy egyszerű incidenskezelési tervvel, amely leírja, mit kell tenni egy biztonsági incidens esetén:

1. Észlelés és értékelés – Határozza meg az incidens természetét és súlyosságát.
2. Elszigetelés – Szükség esetén vegye offline az érintett rendszert a további kár megelőzése érdekében.
3. Helyreállítás – Állítsa vissza a weboldalt az utolsó tiszta biztonsági mentésből.
4. Vizsgálat – Derítse ki, hogyan történt a betörés, és milyen adatok érintettek.
5. Értesítés – A GDPR szerint 72 órán belül értesítenie kell a hatóságot, ha személyes adatok sérültek.
6. Javítás – Szüntesse meg a sebezhetőséget, amelyen keresztül a támadás történt.
7. Dokumentáció – Rögzítse az incidens részleteit és a tanulságokat.

A statikus oldalak biztonsági előnyei

A hagyományos dinamikus weboldalak (WordPress, Joomla) számos támadási felületet nyújtanak: adatbázis, PHP kód, bővítmények, bejelentkezési felület. Ezzel szemben a statikus oldalak – mint amilyeneket az Astro.js keretrendszerrel készítünk – drámaian kisebb támadási felületet biztosítanak:

• Nincs adatbázis – SQL injection lehetetlen.
• Nincs szerver oldali kód futtatás – A támadó nem tud rosszindulatú kódot futtatni a szerveren.
• Nincs bejelentkezési felület – Brute force támadás lehetetlen.
• Nincs bővítményrendszer – Nem kell aggódni a sebezhetővé váló bővítmények miatt.
• Egyszerű CDN-en kiszolgálható – A CDN szolgáltatók beépített DDoS védelmet biztosítanak.

Természetesen a statikus oldalak sem teljesen immunisak – a biztonsági fejlécek, SSL és egyéb intézkedések továbbra is fontosak –, de az alapvető biztonsági szint lényegesen magasabb, mint egy dinamikus CMS esetén.