HTTP header és webalkalmazás-biztonság: az alulértékelt védelmi réteg

A webalkalmazás-biztonságról szóló beszélgetések jellemzően a backend logikára, autentikációra, WAF-ra vagy éppen a sérülékenységvizsgálatokra fókuszálnak. Van azonban egy réteg, amely annak ellenére ritkán kerül reflektorfénybe, hogy közvetlen hatással van arra, hogy a böngésző mit kezd a szerver válaszaival. Ez a réteg a HTTP header konfiguráció.

Tény, hogy a megfelelően beállított HTTP biztonsági headerek nem látványos kontrollok, hiszen nem javítanak ki egy SQL injectiont, és nem akadályoznak meg egyetlen logikai hibát sem.  Ugyanakkor minimális implementációs költség mellett képesek jelentősen csökkenteni a kliensoldali támadások sikerességét, ezért nem érdemes figyelmen kívül hagyni őket.

Mi az a HTTP header és miért számít egy webalkalmazás esetében, hogy milyen?

A HTTP kommunikáció során a kliens (tipikusan egy böngésző) és a szerver strukturált üzeneteket cserél. Ezek két fő részből állnak: az egyiket az ún. Headerek, vagyis metaadatok adják, a másikat pedig az ún. body, vagyis a tényleges tartalom.

A HTTP header kulcs-érték párokból áll, és meghatározza, hogyan kell a választ értelmezni vagy kezelni. Megmutatja például, hogy milyen típusú a tartalom, meddig cache-elhető és milyen biztonsági szabályokat kell alkalmazni a feldolgozás során.

A biztonsági headerek ennél egy lépéssel tovább mennek: konkrét viselkedési szabályokat kényszerítenek ki a böngészőn. Ez azonban nem jelenti, hogy a HTTP protokoll további plusz védelmi szoftverként funkcionál. Csak azt, hogy a protokoll natív képességeit tudatosan kihasználva fokozhatjuk webalkalmazásunk biztonságosságát.

Kibervédelmi higiénia: alacsony költség, magas hatás

A HTTP biztonsági headerek tipikusan a kibervédelmi higiénia kategóriájába tartoznak. Vagyis nem igényelnek komplex fejlesztést, a legtöbbször infrastruktúra szinten konfigurálhatók, alkalmazásukkal mégis mérhetően csökkentik a támadási felületet.

A gyakorlatban szinte minden modern webszerver, reverse proxy vagy framework támogatja ezek beállítását. Ha mégsem szerepelnek a rendszerben, az ritkán technológiai korlát, sokkal inkább prioritási vagy tudatossági kérdés.

Milyen támadások ellen nyújtanak védelmet a HTTP protokollok?

A helyesen konfigurált HTTP headerek nem egyetlen konkrét támadást állítanak meg, hanem több támadási vektor hatását csökkentik. Ilyenek például a(z)

• SSL stripping és protokoll downgrade támadások (a titkosított kapcsolat gyengítése);
• cross-site scripting (XSS), amely valójában valamely rosszindulatú script futtatása a böngészőben;
• clickjacking, melynek során a felhasználó manipulálására kerül sor rejtett UI elemekkel;
• MIME sniffing alapú támadások (tartalomtípus félreértelmezése);
• adatszivárgás referrer információn keresztül;
• nem indokolt böngésző API-hozzáférések (kamera, mikrofon stb.);
• cross-origin adat-hozzáférési problémák.

Fontos egyértelműsíteni, hogy ezek a headerek nem patch-ek, mivel nem javítanak ki semmilyen sérülékenységet. Ugyanakkor képesek jelentősen szűkíteni az egyes sérülékenységek esetleges kihasználási lehetőségeit.

A legfontosabb HTTP biztonsági headerek

Penetrációs tesztelés során rendszeresen látjuk, hogy egyébként érettnek gondolt webalkalmazás-környezetekben is hiányos vagy inkonzisztens a header-konfiguráció: más-más a stagingen és a productionben, a reverse proxy és az alkalmazásréteg között pedig teljesen széttartó beállítások működnek.

Ez azért problémás, mert a böngésző nem kontextus alapján dönt, hanem a kapott válasz szerint viselkedik. Azaz ha a policy nincs egyértelműen és következetesen definiálva, akkor a kliensoldali támadási felület lényegében nyitva marad – függetlenül attól, mennyire erős a backend. Az alábbiakban azokat a headereket vesszük végig, amelyek hiánya vagy hibás konfigurációja a leggyakrabban jelenik meg valós támadási forgatókönyvekben.

Strict-Transport-Security (HSTS)

Példa: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Azaz HSTS arra utasítja a böngészőt, hogy kizárólag HTTPS-en kommunikáljon az adott domainnel.

Mit jelent ez a gyakorlatban?

A böngésző megjegyzi, hogy HTTP nem használható. Minden kapcsolat automatikusan HTTPS-re vált, a domain pedig akár a böngészők preload listájába is bekerülhet.

Milyen problémát kezel?

Elsősorban az SSL stripping támadások kezelésében nyújt segítséget. Ezek során ugyanis a támadó megpróbálja a felhasználót HTTP-re visszaterelni, hogy titkosítatlan forgalmat érjen el. A HSTS ugyanakkor ezt egyszerűen kizárja, mivel a a böngésző nem engedi a downgrade-et.

Content-Security-Policy (CSP)

Példa: Content-Security-Policy: default-src ‘self’; object-src ‘none’; frame-ancestors ‘none’;

A CSP az egyik legerősebb kliensoldali kontroll, amely deklaratívan meghatározza, hogy a böngésző honnan tölthet be erőforrásokat: JavaScript-ből, CSS-ből, képekből,  iframe-ekből vagy API-hívásokból.

Mit csinál?

Az a HTTP csak saját domainről enged betöltést, tiltja a plugin alapú objektumokat és megakadályozza az iframe-be ágyazást.

Milyen problémát kezel?

Elsősorban az XSS-támadások hatását csökkenti. Fontos tudni, hogy nem feltétlenül akadályozza meg a sérülékenységet, viszont jelentősen korlátozza a támadó mozgásterét. (Jegyezzük meg: túl szigorú policy → törött frontend. Túl laza policy → minimális védelem.)

X-Content-Type-Options

Példa: X-Content-Type-Options: nosniff

Ez a header megtiltja a böngészőnek, hogy „kitalálja” a tartalom típusát.

Miért fontos?

MIME sniffing esetén a böngésző eltérhet a deklarált Content-Type-tól, és potenciálisan végrehajtható kódként kezelhet egy fájlt. A nosniff ezt a viselkedést tiltja.

Jellemzője a minimális implementáció, a gyakorlatilag mellékhatásmentes működés és az, hogy ez a HTTP biztonsági szempontból gyakorlatilag gyors győzelem.

X-Frame-Options

Példa: X-Frame-Options: DENY vagy X-Frame-Options: SAMEORIGIN

Ez a header szabályozza, hogy az oldal beágyazható-e iframe-be.

Milyen problémát kezel?

Segíti a clickjacking általi támadásokkal szembeni védekezést, melyek során a támadó egy legitim oldalt rejt el a saját UI-ja alatt, és a felhasználót látszólag ártalmatlan kattintásra veszi rá, miközben valójában például egy tranzakció jóváhagyására.

Emlékeztető:  A modern megközelítés inkább a CSP frame-ancestors direktívája, de az X-Frame-Options továbbra is egyszerű és hatékony baseline védelem.

A HTTP biztonsági headerek hiánya és hibás konfigurációja rendszerszintű kockázatot jelent

Pentesztek során meglepően konzisztens mintázat rajzolódik ki: a HTTP biztonsági headerek vagy teljesen hiányoznak, vagy érdemi védelem nélkül vannak jelen. Gyakori, hogy default konfigurációk futnak éles környezetben, vagy a Content-Security-Policy formálisan létezik, de valójában mindent enged. Így pedig inkább nyújt hamis biztonságérzetet, mint valódi kontrollt.

A probléma nem az, hogy a HTTP protokollok beállítása komplex technikai látásmódot igényel. Mivel a feladat ellátásához nincs szükség több hónapos fejlesztésre, vagy architekturális újratervezésre, ez sem okozhat gondot. 

Csakhogy míg a szervezet azon gondolkodik, kié a felelősség a konfigurációért, mikor kerül sor a beállításokra, és egyáltalán prioritás-e a HTTP-protokollok kialakítása, a sérülékenységek továbbra is lehetőséget adnak az exploitokra.

Ami igazán érdekes az, hogy ezek a hiányosságok gyakran olyan rendszerekben jelennek meg, ahol egyébként komoly erőforrásokat fordítottak biztonságra. Van WAF, MFA és van audit, a böngésző viselkedése azonban mégnincs kontroll alatt.

A HTTP header kötelező alap

A HTTP biztonsági headerek nem helyettesítik a biztonságos fejlesztést, a kódminőséget vagy a rendszeres sérülékenységvizsgálatot, de egy olyan kontrollréteget adnak a webalkalmazáshoz, amely közvetlenül befolyásolja a kliensoldali viselkedést. Megfelelő konfiguráció mellett képesek csökkenteni a támadási felületet, korlátozni a sikeres exploitok hatását, és jelentősen megnehezíteni a tipikus webes támadási technikák érvényesülését.

A bevezetésük ráadásul ritkán igényel jelentős erőforrást: legtöbbször infrastruktúra- vagy konfigurációs szinten kezelhetők, így gyorsan és hatékonyan implementálhatók. Éppen ezért nem haladó biztonsági funkciónak, sokkal inkább alapelvárásnak tekinthetők. 

Hiányuk persze nem feltétlenül jelent azonnali kompromittálódást, de indokolatlanul alacsonyan tartja a támadási küszöböt – és ezt a támadók pontosan tudják. Mert ha egy támadó szemével nézzük: miért keresne komplex exploitot, ha a kliensoldali védelem eleve nincs érvényesítve?

Ti mikor ellenőriztétek utoljára webalkalmazásotok HTTP header konfigurációját? Ha biztosak vagytok abban, hogy minden környezetben konzisztensen működik, nincs tennivalótok. De ha segítségre van szükségetek, itt vagyunk.