A statikus oldalak biztonságáról
Biztonságosabb-e egy SSG platform a hagyományos CMS környezetekhez képest és ha igen, mennyivel?
Miért készítünk statikus lapokból weboldalakat? Mert gyorsan betöltődnek és egy publikus szerveren egyszerűen tárolhatóak. Ezen kívül még biztonságosak is, hiszen nincsen szerver oldali alkalmazás, amit támadni lehetne. Ez utóbbi kijelentés a HTML állományokra ugyan igaz lehet, de a teljes platformra már nem biztos.
Az SSG platform alatt most azt a kiterjedt architektúrát értjük, amely a publikálás és üzemeltetés teljes feladatkörét megvalósítja. A platform alatt történik a webtartalmak rögzítése, szerkesztése, valamint a statikus lapok generálása és a létrejött weboldal elhelyezése, futtatása. Tehát nem csak a statikus oldalakat és nem csak a statikus oldalgenerátort, hanem magát az egész architektúrát tekintjük egy lehetséges támadás célpontjának.
Kinek és miért állna érdekében pont az általunk készített weboldalt törni?
Először is nem csak kinek, hanem minek. Az interneten keringő rosszindulatú botoknak, amelyek exploit arzenállal felfegyverkezve, válogatás nélkül keresik megfertőzhető áldozataikat. Ha kellően értékes, vagy kellően nagy látogatottságú webhelyet sikerül kialakítanunk, hamar a blackhat hackerek célkeresztjében is találhatjuk magunkat. Egy sérülékeny weboldallal pedig többféle módon is vissza lehet élni:
- El lehet lopni az adatbázisának tartalmát. Sokszor még a tulajdonosok sincsenek tisztában azzal, milyen érzékeny személyes és üzleti adatokat is tárolnak backend oldalon.
- Extrém esetben fel lehet törni vele a szervert és el lehet jutni rajta keresztül további alkalmazások adataihoz is, másoknak is károkat okozva.
- Kompromittálni lehet a tartalmát.
- Elérhetetlenné lehet tenni a webhely szolgáltatásait és felületeit, akár hosszabb távú működési kiesést is okozva.
- Vírusokat lehet terjeszteni rajta, amivel nem csak a látogatók számítógépeit lehet megfertőzni, de az internetes keresők adatbázisából is hamar töröltetni tudjuk az oldalt.
- Egy világ méretű, távolról irányítható botnet részéve tudjuk tenni a honlapot, vagy magát a hosztoló szervert. Ezzel erőforrásainkat akaratunk ellenére máris rosszindulatú, külső erők szolgálatába taszítottuk.
Talán nem igényel mélyebb indoklást, hogy nem jó dolog olyan honlapokat készíteni és birtokolni, amelyek kiszolgáltatottak és nem kellően védettek az internet sötét erőivel szemben.
A webalkalmazások ellen indított támadások ma már a leggyakoribb kiberbűnözési formát jelentik (2016 Verizon Data Breach Investigations Report), amit még ma sem vesz mindig minden fejlesztő és üzemeltető komolyan. A többiek számára az OWASP Top 10 sebezhetőségről szóló jelentése kiváló kiindulási pontot jelenthet a kockázatok megértéséhez és a csökkentés lehetőségeinek megismeréséhez.
Az Open Web Application Security Project (OWASP) egy non-profit szervezet, amely fókuszában a web alkalmazások biztonsági kérdései és azok tárgyilagos és gyakorlati megközelítésű megoldásai állnak. Az OWASP Top 10 pedig a sérülékenységek egy széles körben elfogadott toplistája, azokkal a biztonsági kockázatokkal, amelyeket leggyakrabban használnak ki a támadók, többek között adatok ellopáshoz, adatok megváltoztatásához, illetve további alkalmazások megfertőzéséhez.
A toplista első három eleme alapján próbálunk a bevezetőben feltett kérdésre választ adni.
A1 — Injection
Injekciós hiba, amikor lehetővé válik, hogy a támadó olyan, rendszerint SQL, OS és LDAP parancsokat és lekérdezéseket tud futtatni egy szerveren, amelyhez eredendően nem ad lehetőséget az alkalmazás felülete.
A rosszindulatú parancsokat általában egy nem megfelelően védett publikus webfelületen keresztül lehet “betrükközni” a szerverre. Ez a legnépszerűbb támadási forma mindenképpen dinamikus szerver oldali modulokat igényel, amelyek kódértelmező és kódfuttató funkcióval rendelkeznek, és ezeken keresztül kerülhetnek végrehajtásra támadó célú parancsok. Amennyiben statikus lapokat tárolunk a szerveren, teljes egészében hiányzik az a webalkalmazás réteg, amely az injekció elsődleges célpontja lehet. Vagyis első ránézésre a kockázatok minimalizálásában elértük a maximumot, azaz a nullát. Vagy mégsem?
A statikus oldalgenerátor érintettsége
A lapok megjelenítéséhez ugyan nem használunk web alkalmazásokat, de a statikus lapokat is előállítjuk valahol és valamivel. Rendszerint egy alkalmazással. Abban az esetben, ha ez egy publikus címen elérhető, ezen keresztül nem csak maga az alkalmazás, de közvetve a honlapot hosztoló kiszolgáló(k) is támadhatóvá válhat(nak). Kellő odafigyeléssel azonban a kockázatok továbbra is alacsony szinten tarthatóak. A statikus oldalgeneráló alkalmazást mindenképpen lássuk el kellően erős védelemmel:
- Rendszeresen és folyamatosan monitorozzuk a működését és a kódokat is.
- Rendszeresen és folyamatosan tartsuk karban és frissítsük a kódokat.
- A generátor és a publikus honlap(ok) tárterületei közötti adatkapcsolatot titkos, védett és folyamatosan felügyelt csatornán valósítsuk meg.
- Ha lehetőségünk van rá, helyezzük a generátor alkalmazást tűzfal mögé.
Amennyiben az architektúra egyetlen központi statikus oldalgenerátorra épít, azaz egyetlen alkalmazás állítja elő több honlap statikus állományát, akkor viszonylag kis ráfordítással is fenn tudunk tartani egy erős védelmi szintet.
Felhasznált API-k érintettsége
A statikus oldalakon előforduló dinamikus funkciókat beágyazott böngésző oldali szkriptekkel tudjuk megvalósítani. Természetesen ezek rendszerint olyan API felületekhez kapcsolódnak, amelyeket dinamikus, szerver oldali webalkalmazással szolgálnak ki, melyek sérülékenyek lehetnek. Ugyanakkor, mivel mind a védett statikus oldalgenerátor, mind pedig a publikus állományok szerverétől hermetikusan elszigeteltek, még közvetve sem lehet őket injekcióval támadni.
A2 — Broken Authentication and Session Management
Olyan sérülékenységek, amelyek hibás hitelesítési és munkamenet-kezelési funkciókat használnak ki. A támadók a nem megfelelően kezelt kulcsok segítségével munkameneteket lophatnak vagy téríthetnek el, ezzel más, hitelesített felhasználók folyamataihoz nyernek illetéktelen hozzáférést.
Mivel a statikus oldalakon nem kezelünk munkameneteket, ennek a támadási formának sincs relevanciája a publikus szerver oldalán. Az architektúra ezen eleme a második legnépszerűbb támadási formával szemben is teljesen védett.
A statikus oldalgenerátor érintettsége
Hasonlóan az injekciós hibához, a statikus lapokat előállító alkalmazás már ki van téve ennek a támadási formának. A szükséges védelmi intézkedések ugyanakkor ebben az esetben is ugyanazok, mint korábban: gondoskodnunk kell a legerősebb de még racionális elérési korlátozásokról és az alkalmazások folyamatos frissen tartásáról.
Felhasznált API-k érintettsége
Amennyiben privát munkamenetet is kezelő, beágyazott frontend oldali komponenseket is illesztünk az oldalakba, az API funkciókat megvalósító szerver természetesen támadhatóvá válik munkamenet oldalról. Az API mögötti backend rendszer támadásával pedig közvetve a statikus oldalunkat is ellátjuk egy olyan sérülékenységgel, amely annál erősebb, minél gyengébb a beillesztett, rendszerint harmadik féltől származó alkalmazás védelme. Ha kizárólag olyan dinamikus komponensekkel dolgozunk, amely folyamatos üzemeltetését és fejlesztését egy kellően megbízható és magas technológiai felkészültségű szervezet biztosítja, mindent megtettünk annak érdekében, hogy oldalaink sérülékenységét a lehetőségekhez mérten minimalizáljuk.
A3 — Cross-Site Scripting (XSS)
A tárolt XSS támadás alapja, hogy böngésző oldali szkript értelmezőkbent (pl. JavaScript, VBScript, Active-C HTML vagy Flash, stb.) idegen kódokat tudnak futtatni . Ennek során adatokat, sütiket lophatnak el, illetve olyan kéréseket generálnak, amelyek további kártékony programokat futtatnak a végfelhasználónál.
A Cross-Site Scripting alapú támadás tehát első körben a látogató böngészőjének megfertőzésével indul és alapvető feltétele egy olyan web oldal, amelyre előzőleg el tudták helyezni a támadáshoz szükséges rosszindulatú kódokat. Az idegen kódok elhelyezésére általában három lehetőség kínálkozik:
- Injekció alapú támadással
- Kliens oldali állomány átvitelre szolgáló alkalmazások megfertőzésével
- Az ezekhez használt távoli kapcsolatok feltörésével
Egy SSG platform publikus szerverén:
- Az injekció alapú támadás lehetősége a statikus állományok miatt szinte kizárt
- Mivel nem használunk kliens oldalon megfertőzhető állománykezelő alkalmazást, ezért ezzel kapcsolatban sem merül fel kockázat.
- Az SSG szerver egy igen biztonságos csatornán kommunikál a statikus tárhely(ekk)el, ennek feltörése jóval komplexebb feladat, mint pl. egy hagyományos FTP kapcsolaté.
A statikus oldalgenerátor érintettsége
Az XSS támadások számára a statikus oldalgenerátor alkalmazás jelenti az egyik lehetőséget, hogy kompromittált kódokat helyezhessenek el a weboldalon. Amennyiben egy központi, felhő alapú alkalmazást használunk a lapok generálására és frissítésére, jóval egyszerűbb ennek a központi elemnek a védelmét megszervezni, mint több, sokszor magára hagyott CMS alkalmazás biztonságát szavatolni.
Felhasznált API-k érintettsége
A Cross-Site Scripting módszerrel szemben a böngésző oldali, külső API-t használó programok komoly sérülékenységet jelenthetnek. Kivitelezőként nagy a felelősségünk abban, hogy mindig olyan komponensekkel dolgozzunk, amely folyamatos üzemeltetését és fejlesztését egy kellően megbízható és magas technológiai felkészültségű szervezet biztosítja. Ebben az esetben ugyanakkor mi mindent megtettünk annak érdekében, hogy a támadások kockázatát minimalizáljuk.
Eredményhirdetés
Annak érdekében, hogy számszakilag is ki tudjuk mutatni valahogyan az architektúrákhoz kapcsolódó kockázatokat, az egyes komponensek sérülékenységét pontoztuk. Az erős védelmet az 1-es, a magas kockázatot 3-as sérülékenységi mutatóval jelöltük.
Az összehasonlításban a “hagyományos mosópor” szerepét egy ritkán frissített és nyílt forráskódú Wordpress vagy Joomla motorral hajtott CMS jelenti. Egy általános, üzleti célú honlapot vettünk alapul és külön értékeltük az adminisztrációs felületének és külön a publikus web lapjainak biztonsági kockázatait. Az eredmények:
A1 — Injection: SSG admin [1], publikus felületek [0]
A1 — Injection: CMS admin [2], publikus felületek [3]A2 — Sessions: SSG admin [1], publikus felületek [0]
A2 — Sessions: CMS admin [2], publikus felületek [3]A3 —XSS: SSG admin [0], publikus felületek [1]
A3 —XSS: CMS admin [0], publikus felületek [3]
A fenti értékelés természetesen valamekkora általánosítást és némi szubjektivitást is tartalmaz, ugyanakkor ezek mellett is jelentős különbség mutatható ki egy megfelelően telepített és üzemeltetett SSG platform javára.
