Fenyegetési modell és bizalmi határok

Célok

A lecke végére meg tudsz fogalmazni egy rövid fenyegetési modellt egy webes művelethez (érték, szereplők, képességek, védelmek), fel tudod ismerni a bizalmi határokat, és érted, miért nem helyettesíti egyik védelem a másikat.

Miért nem elég támadásneveket tanulni?

A webbiztonság kiindulópontja nem egy támadásnév megtanulása, hanem annak tisztázása, hogy mit védünk, kitől, és hol lép át egy adat bizalmi határt. Ugyanaz a webalkalmazás más kockázatot hordoz egy nyilvános cikk megjelenítésekor és egy hallgatói jelentkezés módosításakor. Aki csak a támadások neveit ismeri, a következő új támadás előtt tanácstalan; aki a gondolkodásmódot, az új helyzetben is használni tudja.

Mit próbálunk megvédeni?

A Kurzuspontban védendő értékek: a hallgató személyes adata, a jelentkezések helyessége, a bejelentkezett munkamenet és a szolgáltatás elérhetősége. A támadó lehet külső látogató, másik bejelentkezett hallgató, rosszindulatú weboldal vagy egy ellopott fiókot használó személy. A biztonsági kérdés mindig egy konkrét támadói képességhez kötődik: el tud-e olvasni a támadó egy választ, rá tud-e venni egy böngészőt kérés küldésére, el tud-e érni egy szerveroldali műveletet?

A fenyegetési modell (threat model) rövid leírás arról, hogy milyen értékek, szereplők, támadói képességek és védelmi feltételek fontosak. Nem jóslat minden jövőbeli támadásról: segít rangsorolni azokat az ellenőrzéseket, amelyeket az alkalmazás tényleges működése igényel.

A bizalmi határok átlépése

A bizalmi határ (trust boundary) az a pont, ahol az adat vagy a vezérlés egy másik fél, környezet vagy értelmezési szabály felé lép. A felhasználói bemenet nem lesz megbízható attól, hogy a saját alkalmazás űrlapjáról érkezett: a böngészőben futó kód és a hálózati kérés módosítható, az API közvetlenül is hívható (curl-lel, egy szkripttel). A szervernek ezért a módosító műveletnél újra ellenőriznie kell a felhasználót, a jogosultságát és a bemenetet. Az adatbázis felé küldött lekérdezés vagy egy másik felhasználónak megjelenített szöveg szintén új értelmezési környezet.

flowchart LR
    U[Felhasználó vagy támadó] --> B[Böngésző és bemenet]
    B -->|HTTP-kérés: bizalmi határ| S[Alkalmazásszerver]
    S -->|lekérdezés: bizalmi határ| D[(Adatbázis)]
    S -->|HTML és adatok: értelmezési határ| B

A határ nem azt jelenti, hogy a másik fél biztosan rosszindulatú, hanem azt, hogy a fogadó nem hagyatkozhat kizárólag a küldő állítására. A szerver például nem fogadhatja el a kérésben szereplő hallgatoId mezőt annak bizonyítékaként, hogy a hallgató a saját jelentkezését módosítja. Az azonosítót a szerver által ellenőrzött munkamenetből kell venni (7.4).

Egyszerű gondolatmenet egy művelethez

Vegyük a jelentkezést:

1. Érték: a jelentkezések helyessége (senki nem jelentkezhet más nevében, a hely nem lépheti túl a keretet).
2. Művelet: a szerver egy adott hallgatót egy kurzushoz rendel.
3. Szereplők és képességek: egy másik hallgató (tudja módosítani a kérést); egy idegen weboldal (kérést tud indítatni a hallgató böngészőjével); egy hálózati támadó (nyilvános Wi-Fin forgalmat lát).
4. Fenyegetések: más hallgató nevében érkezik kérés; a böngésző egy idegen webhely hatására küldi el a kérést a bejelentkezett cookie-val; a bemenet az adatbázis-utasítás részévé válik.
5. Védelmek: hitelesítés, műveletenkénti jogosultság-ellenőrzés, a kérés eredetének védelme, a bemenet és az adatbázis-művelet helyes kezelése.

Egyetlen védelem nem váltja ki a többit: a titkosított kapcsolat (4.3) nem dönti el, hogy az adott felhasználó jelentkezhet-e a kurzusra; a bejelentkezés sem bizonyítja, hogy a kérés a hallgató szándékából indult.

flowchart TD
    A[Érték: jelentkezések helyessége] --> B[Támadói képességek]
    B --> C[Fenyegetés: más nevében, idegen oldalról, manipulált bemenettel]
    C --> D[Védelmek: hitelesítés, jogosultság, szándék, bemenet-kezelés]
    D --> E[Marad-e rés? Következő határ]

Végigvezetett példa: a Kurzuspont fenyegetési táblázata

Érték	Támadó / képesség	Fenyegetés	Fő védelem	Hol a lecke?
Hallgatók személyes adata	Másik bejelentkezett hallgató	Az azonosító átírásával olvassa más adatát	Szerveroldali jogosultság-ellenőrzés	7.4
Jelentkezések helyessége	Idegen weboldal	A böngészővel kérést indíttat	CSRF-védelem	8.4
Megjelenített hozzászólások	Rosszindulatú hozzászóló	Kódot juttat az oldalba	Kimeneti kódolás	8.3
Adatbázis	Tetszőleges látogató	A bemenet utasítássá válik	Paraméterezett lekérdezés	8.5
Fiókok	Jelszótippelő vagy adathalász	Fiókátvétel	Jelszóvédelem, többfaktoros hitelesítés	8.6
Elérhetőség	Túlterhelés	A rendszer nem válaszol	Kapacitás, korlátozás	10. fejezet

A táblázat egy kurzus szintű vázlat, nem teljes elemzés; a lényege az, hogy minden sor egy érték – képesség – védelem hármas, és minden védelemnek van helye az architektúrában.

Gyakori tévhitek

Állítás	Pontosítás
„Csak a bejelentkezési oldal biztonságérzékeny.”	A személyes adatok olvasása és az állapotváltoztató műveletek is azok.
„A saját űrlapunkról érkező adat megbízható.”	A kérést a kliens vagy más program tetszőlegesen módosíthatja.
„A biztonság egyetlen kapcsoló.”	Több határon külön ellenőrzések kellenek.
„A HTTPS-es oldal biztonságos.”	A szállítást védi, az alkalmazás hibáit nem (4.3).
„A fenyegetési modell hosszú dokumentum.”	Már néhány sornyi „érték – támadó – védelem” is használható.

Röviden

• A fenyegetési modell megnevezi az értékeket, a szereplőket, a képességeket és a védelmeket.
• A bizalmi határon a fogadó fél nem hagyatkozhat a küldő állítására.
• A kliensről érkező adatot a szerveren újra kell ellenőrizni.
• A védelmek egymást kiegészítik, nem helyettesítik.

Ellenőrző kérdések

1. Mi egy fenyegetési modell három fő eleme?
2. Hol van bizalmi határ a Kurzuspont jelentkezési műveletében?
3. Miért nem elég, ha a HTTPS védi a jelentkezés kérését?
4. Miért nem fogadhatjuk el a kérésben megadott hallgatoId mezőt?

Tanulási források

• OWASP Top 10:2025 — a legfontosabb webes kockázati kategóriák, angolul.
• Security on the web (MDN) — a webbiztonság témakörei.