OWASP-szemlélet és egy webalkalmazás biztonsági áttekintése

Célok

A lecke végére ismered az OWASP Top 10:2025 tíz kategóriáját és azt, mire használható (és mire nem), végig tudsz vezetni egy kérést a bizalmi határokon, és fel tudod ismerni, hogy a biztonság felelőssége több szereplő között oszlik meg.

Miért kell egy ellenőrző keret?

Az előző leckék egy-egy támadáscsaládot mutattak be. Egy valódi alkalmazás felülvizsgálatakor viszont nem azt kérdezzük, melyik támadást ismerjük, hanem azt, mi felejtődhetett el. Az OWASP nyílt szakmai közösség, amely útmutatókkal és kockázati összefoglalókkal segíti a webalkalmazások biztonságos tervezését. A listái nem helyettesítik a saját rendszer fenyegetési modelljét (8.1), de jó ellenőrző keretet adnak: milyen hibacsaládokra kell gondolni?

Az OWASP Top 10:2025

Az OWASP Top 10 a webalkalmazások gyakori, fontos biztonsági kockázati kategóriáit rendszerezi. A 2025-ös kiadás tíz kategóriája:

Azonosító	Kategória	Hol találkoztunk vele?
A01	Broken Access Control (hibás hozzáférés-ellenőrzés)	7.4: jogosultság; 8.1
A02	Security Misconfiguration (biztonsági hibás beállítás)	4.3: HTTPS/HSTS, 8.2: CORS
A03	Software Supply Chain Failures (szoftverellátási lánc hibái)	–
A04	Cryptographic Failures (kriptográfiai hibák)	4.3, 7.3, 8.6
A05	Injection (injekció)	8.3, 8.5
A06	Insecure Design (nem biztonságos tervezés)	8.1
A07	Authentication Failures (hitelesítési hibák)	7.4, 8.6
A08	Software or Data Integrity Failures (szoftver- vagy adatintegritási hibák)	–
A09	Security Logging and Alerting Failures (naplózási és riasztási hibák)	10.5
A10	Mishandling of Exceptional Conditions (kivételes helyzetek hibás kezelése)	10.2

A kategóriák és sorrend kiadásonként változhatnak. A lista nem tíz kipipálható teszt: egyetlen kategórián belül is több eltérő hiba és védelmi döntés lehet. Az angol nevek az OWASP oldalán szereplő hivatalos nevek, a magyar elnevezések a tananyag fordításai.

Az OWASP Cheat Sheet Series (spórolós útmutatók) célzott, részletes útmutatót ad például a jelszótároláshoz (8.6), az SQL-injekció megelőzéséhez (8.5) vagy a munkamenetekhez. Használatuknál a konkrét technológiát és az aktuális dokumentációt kell figyelembe venni. Egy általános lista nem helyettesíti a megértett adatfolyamot.

Egy hibás jelentkezési folyamat elemzése

Képzeljünk el egy kurzusjelentkezési API-t. A böngésző a kérésben küldi a kurzus- és hallgatóazonosítót; a szerver csak azt vizsgálja, hogy létezik-e bejelentkezett munkamenet, majd a két azonosítót összefűzve SQL-be illeszti. A felület a kurzus megjegyzését ellenőrzés nélkül HTML-ként jeleníti meg. Az oldal HTTPS-en működik.

A HTTPS védi a böngésző és a szerver közötti kapcsolatot (4.3), de négy külön alkalmazási hiba marad:

Hiba	Miért hiba?	Kategória	Javítás
A hallgatoId szabadon megadható	Bármely bejelentkezett felhasználó más nevében jelentkezhet.	A01	Az azonosítót a szerver a munkamenetből veszi (7.4).
Összefűzött SQL	Injekciós kockázat.	A05	Paraméterezett lekérdezés (8.5).
A megjegyzés HTML-ként jelenik meg	XSS.	kimenetkezelés (az XSS besorolása kiadásonként eltérhet)	Kimeneti kódolás, textContent (8.3).
Cookie-alapú munkamenet, nincs szándékellenőrzés	CSRF.	A01/A07 (a kérés szándéka)	CSRF-token, SameSite, Fetch metadata (8.4).

flowchart TD
    A[Kurzusjelentkezési kérés] --> B{Ki küldte?}
    B --> C{Módosíthatja ezt a hallgatót?}
    C --> D{A bemenet adat marad?}
    D --> E{A kérés a felhasználó szándéka?}
    E --> F{A válasz biztonságosan jelenik meg?}

A vizsgálat sorrendje nem rangsor, hanem a kérés útjának követése. Minden csomópontnál azt kérdezzük: melyik fél dönt, milyen adatra támaszkodik, és mi történik, ha az adat támadó által választott. A hallgatóazonosítót célszerű a szerver által ellenőrzött munkamenethez kötni, az adatbázis-műveletet paraméterezni, a megjelenítést szövegbiztosan kezelni, és a műveletet CSRF-védelemmel ellátni.

Felülvizsgálati szempontok

Egy rövid, kérés-alapú ellenőrzőlista (nem teljes):

1. Bemenet: honnan jön, ki állítja, hol ellenőrizzük?
2. Hitelesítés és jogosultság: minden védett műveletnél ellenőrzi-e a szerver? Az erőforrás az illetőé-e?
3. Kimenet: a megjelenített adat a kontextusának megfelelően kódolt?
4. Adatbázis és más értelmezők: paraméterezett-e, legkisebb jogosultsággal fut-e?
5. Munkamenet és cookie: HttpOnly; Secure; SameSite, lejárat, érvénytelenítés?
6. Kapcsolat: HTTPS mindenhol, HSTS, nincs vegyes tartalom (4.3)?
7. Böngészőszabályok: CORS és CSP szándékosan szűk (8.2, 8.3)?
8. Titkok és függőségek: hol vannak a titkok? Milyen külső csomagoktól függ az alkalmazás, és frissülnek?
9. Naplózás és riasztás: látszik-e egy támadási kísérlet (10.5)?
10. Hibakezelés: a hibaüzenet nem árul-e el belső részletet (10.2)?

A felelősség több szereplő között oszlik meg

Szereplő	Mit érvényesít?
Böngésző	Same-origin policy, CORS, cookie-szabályok, CSP
Fejlesztő	Az alkalmazás adatfolyama, kimenetkezelés, jogosultság-ellenőrzés, paraméterezés
Üzemeltető	TLS-végpont, frissítések, titkok, naplózás, hozzáférések
Felhasználó	Biztonságos belépési szokások (hosszú jelszó, MFA)

A szerepek összekapcsolódnak, mégis külön felelősséget jelentenek. A felhasználó biztonságos szokásai nem vehetik át a hibás szerveroldali ellenőrzés helyét.

Végigvezetett példa: a Kurzuspont áttekintése

A Kurzuspont áttekintésekor a csapat végigmegy a jelentkezési kérés útján, és minden hibát egy kategóriához és egy leckéhez rendel (a fenti táblázat mintájára). Az eredmény egy javítási lista, nem egy „biztonságos / nem biztonságos” ítélet. A következő felülvizsgálatot új funkció, új függőség vagy architektúra-változás indítja: a biztonság nem egyszeri pecsét.

Gyakori tévhitek

Állítás	Pontosítás
„Az OWASP Top 10 minden lehetséges támadást felsorol.”	Kiemelt kockázati kategóriákat ad, nem teljes fenyegetési modellt.
„Ha a lista tíz eleme zöld, a rendszer biztonságos.”	Az alkalmazás saját adatfolyamait és változásait is vizsgálni kell.
„A böngésző biztonsági szabályai kiváltják a szerver ellenőrzését.”	A szervernek önállóan kell hitelesítenie és engedélyeznie a műveleteket.
„A HTTPS-es oldal biztonságos.”	A kapcsolatot védi, az alkalmazás hibáit nem.
„A biztonsági felülvizsgálat egyszeri feladat.”	Minden változás új kockázatot hozhat.

Röviden

• Az OWASP Top 10:2025 tíz kockázati kategóriát nevez meg, az A01 a hibás hozzáférés-ellenőrzés.
• A lista keretet ad, nem teljes fenyegetési modellt.
• Egy felülvizsgálat a kérés útját követi a bizalmi határokon át.
• A biztonság felelőssége megoszlik a böngésző, a fejlesztő, az üzemeltető és a felhasználó között.

Ellenőrző kérdések

1. Melyik OWASP-kategóriába tartozik, ha egy bejelentkezett felhasználó más azonosítóját írja át a kérésben?
2. Miért nem pótolja a HTTPS az alkalmazásszintű ellenőrzéseket?
3. Mit jelent az, hogy a fenyegetési modell és az OWASP-lista kiegészíti egymást?
4. Mely szereplő felelős a CORS és a cookie-szabályok érvényesítéséért?

Tanulási források

• OWASP Top 10:2025 — a tíz kategória és részletes leírásuk, angolul.
• OWASP Cheat Sheet Series — célzott védelmi útmutatók.