Röviden: Egy statikus weboldal kész HTML-, CSS- és képfájlokból áll, amelyeket a webszerver csak kiszolgál. Mivel a szerveren nem fut PHP és adatbázis, az olyan rések, mint a PHP2Shell, az SQL-injection vagy a bejuttatott webshellek kockázata nagyrészt kiesik. Egy statikus weboldal biztonságánál ezért más dolgok számítanak: a tárhely, a domain és a build-eszközök védett hozzáférései, a gondozott függőségek és gondosan kiválasztott külső szolgáltatások. Főként olyan weboldalaknak való, amelyeket ritkán módosítanak, és nincs szükségük ügyfélfiókokra.
Miért teszik fel ezt a kérdést éppen most
A PHP2Shell sok vállalkozásnak megmutatta, mennyi minden függ egyetlen komponenstől. Egy tíz oldalas cégweboldal, amelyet negyedévente frissítenek, ugyanazon a PHP-n futott, mint egy nagy webshop, és így ugyanannak a kritikus résnek volt kitéve. A médiajelentések szerint még hatóságok és települések is elővigyázatosságból lekapcsolták a weboldalaikat.
Kézenfekvő a kérdés: kell-e nekünk egyáltalán PHP a szerveren a weboldalunkhoz? Sok kis- és középvállalkozásnál az őszinte válasz: a kiszolgáláshoz gyakran nem. A PHP minden híváskor újra előállítja az oldalt, noha a tartalom hetek óta nem változott. Hogyan zajlik ez műszakilag, azt a Hogyan állítja elő a PHP a weboldalt írja le. Hogy mit jelent maga a rés, azt a Mi a PHP2Shell? magyarázza el.
Hogyan működik egy statikus weboldal
Egy statikus weboldalnál az oldalt nem a látogatáskor, hanem előtte állítják elő. A statikus oldalak generátora, például a Hugo, a Jekyll vagy az Eleventy, szövegeket, képeket és sablonokat vesz, és kész fájlokat épít belőlük. Ezeket a fájlokat egy egyszerű webszerverre vagy egy tartalomszolgáltató hálózatra (Content-Delivery-Network), vagyis elosztott kiszolgáló hálózatra töltik fel.
A szerkesztők számára elé kerülhet egy szerkesztőeszköz, amely fogadja a módosításokat, és elindítja az újraépítést. Részben ehhez úgynevezett headless CMS-t használnak, amely csak a tartalmakat kezeli, és maga nem kell, hogy nyilvánosan elérhető legyen. A látogató ebből semmit sem lát; csak a kész fájlokat kapja.
Statikus weboldal és biztonság összehasonlításban
| Szempont | Dinamikus PHP-s CMS | Statikus weboldal |
|---|---|---|
| Programlogika a nyilvános szerveren | Igen, minden híváskor | Nem |
| Kockázat a PHP-értelmező hibáiból | Igen, mint a PHP2Shellnél | Kiesik a kiszolgáló szerveren |
| Nyilvánosan csatlakoztatott adatbázis | Igen | Nem |
| Tipikus belépési pontok | Bővítmények, admin-bejelentkezés, feltöltések, szerver | A tárhely, a domain, a build-rendszer hozzáférései, külső szolgáltatások |
| Űrlapok, keresés, ügyfélfiók | Beépítve | Csak külső szolgáltatásokon vagy külön funkciókon keresztül |
| Gondozási ráfordítás a szerkesztőknek | Alacsony, megszokott felület | A szerkesztőeszköztől függ |
| Karbantartás | A CMS, a bővítmények és a PHP rendszeres frissítései | A build-eszközök és a függőségek frissítései |
| Alkalmasság | Webshopok, portálok, sok szerkesztő, gyakori módosítások | Cégweboldalak, céloldalak, dokumentáció |
A táblázat megmutatja: a támadási felület eltolódik, nem tűnik el. Egy nyilvánosan elérhető PHP-szerver helyett a tárhelyszolgáltatónál lévő fiókot, a domaint, a build-pipeline-t és adott esetben a szerkesztőeszközt kell védenie.
Mely kockázatok maradnak a statikus weboldalaknál
Először a hozzáférések. Aki átveszi a tárhelyfiókot, a domain-hozzáférést vagy a kód-repositoryt, PHP nélkül is módosíthatja a weboldalt. A kétfaktoros bejelentkezés és a személyes fiókok ezért kötelezők.
Másodszor a függőségek. A generátorok és a sablonok gyakran sok csomagot hoznak magukkal, például az npm-ből. Ezeket naprakészen kell tartani, mert egy kompromittált függőség az építésnél kártékony kódot írhat a kész fájlokba. Hogyan szervezheti ezt, azt a Függőségek naprakészen tartása írja le.
Harmadszor a külső szolgáltatások. Az űrlapszolgáltatások, keresőfunkciók, elemzőeszközök és beágyazott szkriptek a látogatók böngészőjében vagy idegen szervereken futnak. Mindegyik szolgáltatás bizalmi viszony, adatvédelmi szempontból is.
Negyedszer a böngészőoldal. Egy statikus oldalnak is be kell állítania biztonsági fejléceket, például egy Content-Security-Policy-t, amely meghatározza, mely szkripteket szabad betölteni. Az alapokat a Biztonsági fejlécek weboldalakhoz tartalmazza.
Az átállás előtt ellenőrizze, mely funkciókat használja valójában a weboldala. Gyakran kevesebbet, mint gondolná: oldalakat, képeket, egy kapcsolatfelvételi űrlapot. Ilyenkor a statikus weboldalhoz vezető út rövidebb, mint elsőre látszik.
Kinek éri meg az átállás, és kinek nem
Jól megfelel egy statikus weboldal áttekinthető terjedelmű vállalati oldalaknak, kampányok céloldalainak, termékdokumentációknak és karrieroldalaknak. Az átállás különösen akkor éri meg, ha a korábbi weboldal régi PHP-verzión fut, és a verzióváltás amúgy is esedékes lenne.
Kevésbé alkalmas webshopokhoz, ügyfélportálokhoz, foglalási rendszerekhez és sok, naponta publikáló szerkesztővel rendelkező weboldalakhoz. Itt egy dinamikus rendszer marad az értelmes. Segíthet egy vegyes forma: a webshop dinamikus marad és jól keményített, az útmutatókat és a vállalati oldalakat statikusan szolgálják ki.
Egy gyakran alábecsült előny éles helyzetben mutatkozik meg. Mivel a kész fájlokat bármikor újra lehet építeni sablonokból és tartalmakból, egy manipulált weboldal gyorsan visszaállítható egy ismert, tiszta állapotra. Előfeltétel, hogy a tartalmak és a sablonok egy védett repositoryban legyenek, a módosításokat követhetően naplózzák, és senki se szerkessze közvetlenül a fájlokat a szerveren.
Az átálláshoz nem feltétlenül szükséges biztonsági szolgáltató; ezt egy ügynökség vagy egy fejlesztő is elvégezheti. Ha a korábbi weboldal kompromittált volt, a tartalmakat azonban az átvétel előtt ellenőrizni kell. Erre tér ki a Feltörés után CMS-t váltani?.
Hogyan segít konkrétan a PHP SOS?
- Megvizsgáljuk, mely funkciókra van valójában szüksége a weboldalának, és nyíltan megmondjuk, hogy alkalmas-e egy statikus megoldás.
- Átállásnál kétfaktoros bejelentkezéssel és személyes fiókokkal biztosítjuk a tárhely, a domain és a build-rendszer hozzáféréseit.
- Ellenőrizzük a külső szolgáltatásokat, és biztonsági fejléceket állítunk be, hogy az új weboldal a böngészőben is jól védett legyen.
- A megmaradó PHP-rendszerekhez a frissítéseket és a felügyeletet a biztonsági karbantartási szerződés keretében vesszük át.
Összegzés
A statikus weboldal nem csodaszer, de sok vállalati oldalnál a legegyszerűbb módja annak, hogy megszabaduljon a kockázatok egy egész osztályától. Ahol nem fut PHP, ott a PHP2Shell nem tud semmit elérni. A nyert biztonság azonban csak akkor tart, ha a hozzáféréseket, a függőségeket és a külső szolgáltatásokat ugyanolyan komolyan veszik, mint korábban a szervert.
Gyakori kérdések
Fel lehet törni egy statikus weboldalt is?
Igen. A szerveroldali programlogika kiesik, és vele a támadások egy nagy osztálya. Támadhatók maradnak azonban a tárhely, a domain és a build-rendszer hozzáférései, a beépített külső szolgáltatások és az eszközök, amelyekkel az oldalt előállítják.
Lehetnek egy statikus weboldalon kapcsolatfelvételi űrlapok?
Igen, egy külső űrlapszolgáltatáson vagy egy kis, külön üzemeltetett funkción keresztül. Ilyenkor az adatok feldolgozása ennél a szolgáltatásnál van. Beépítése előtt tisztázza az adatvédelmet és az adatfeldolgozást.
Gondozhatják a szerkesztők maguk a statikus weboldalt?
Megfelelő szerkesztői eszközzel igen. Sok megoldás kínál szerkesztőfelületet, amelyből az oldalt utána újragenerálják. Azoknak a csapatoknak, amelyek naponta sok tartalmat módosítanak, egy klasszikus CMS azonban gyakran kényelmesebb.
Megéri az átállás egy webshopnak?
Többnyire nem teljesen. A kosár, az ügyfélfiók és a fizetés szerveroldali logikát igényel. Lehetséges egyes részeket, például útmutatókat vagy vállalati oldalakat statikusan kiszolgálni, és a webshopot külön üzemeltetni.