10.1 Security mindset

← 10. DevSec – Security alapok

10.1 Security mindset – miért a fejlesztő az első védelmi vonal

Áttekintés

Amikor valaki azt mondja, „majd a security csapat megoldja" – akkor már elkésett. A biztonsági rések 85%-a nem azért kerül production-ba, mert a támadók zseniálisak, hanem azért, mert egy fejlesztő nem gondolt rá fejlesztés közben. Ez az alfejezet nem arról szól, hogy security expertté válj. Arról szól, hogy megértsd: te vagy az első védelmi vonal – és ez nem teher, hanem lehetőség.

Amit ebben az alfejezetben megtanulsz:

  • Mit jelent a „security mindset" a mindennapi fejlesztési munkában
  • Miért nem elegendő egy dedikált security csapat
  • Mi az a shift-left security és miért csökkenti a költségeket
  • Hogyan gondolkodik egy fejlesztő fenyegetésekről (threat modeling alapok)
  • Milyen konkrét felelőssége van egy junior fejlesztőnek security szempontból

Szükséges előismeret: Alapszintű webalkalmazás-fejlesztési ismeretek (mi a szerver, kliens, adatbázis)

Részletes leírás

A mítosz: „Mi van security csapatunk"

Sok junior fejlesztő úgy gondol a biztonságra, mint egy önálló részlegre: valahol ülnek emberek, akiknek az a dolguk, hogy megvédjék a rendszert. Ez igaz – de téves következtetés levonni belőle, hogy a fejlesztőnek nincs felelőssége.

Gondolj bele: Ha egy épületben tűzoltók dolgoznak, ez nem jelenti azt, hogy a lakóknak nem kell ügyelniük arra, hogy ne gyújtsanak tüzet véletlen helyen. A security csapat a tűzoltók – de te vagy az, aki a kódbázisban dolgozik.

A valóság az, hogy egy security audit rendszerint nem futtatnak le minden egyes PR-on, amit bemergesz. Naponta több tucatnyi változtatás kerülhet production-ba anélkül, hogy egy dedikált security szakember megvizsgálná. Ha te magad nem gondolsz rá, nem is derül ki – egészen addig, amíg ki nem derül.

Shift-left security – a legolcsóbb bug az, amit fejlesztés közben találsz meg

A szoftverfejlesztésben a „left" és „right" kifejezések az idővonalra utalnak: balra van a fejlesztés, jobbra van a production. A shift-left security elve azt mondja ki: minél korábban (balabb) foglalkozol biztonsággal, annál olcsóbb a hiba.

Fejlesztés közben → Code review → QA/testing → Staging → Production
     LEGOLCSÓBB                                              LEGDRÁGÁBB

Konkrét számok a kontextushoz:

  • Fejlesztés közben talált hiba: 1× költség (csak te javítod, 5 perc)
  • Code review-ban talált hiba: ~5× költség (reviewer ideje + újra review)
  • QA-ban talált hiba: ~15× (QA munka + fejlesztői visszarendelés)
  • Production-ban talált hiba: ~100× (incidens kezelés, felhasználói kár, reputáció)

Ez nem becsült szám – számos iparági kutatás alátámasztja (IBM System Sciences Institute). A lényeg: ha fejlesztés közben gondolsz rá, az a legolcsóbb befektetés.

Mi az a threat modeling – alapszinten

A threat modeling egyszerűen azt jelenti, hogy mielőtt kódolsz, átgondolod: mi mehet rosszul?

Nem kell hozzá diagram, nem kell hozzá külön eszköz. Elég négy kérdés:

  1. Mit építünk? – Mi ez a funkció, mi az adatfolyam?
  2. Mi mehet rosszul? – Hogyan lehet ezt visszaélni?
  3. Mit teszünk ellene? – Van-e validáció, jogosultság-ellenőrzés, titkosítás?
  4. Megcsináltuk-e? – Tényleg implementáltuk, nem csak terveztük?

Példa: Egy file upload funkciót implementálsz.

KérdésVálasz
Mit építünk?Felhasználó feltölthet képet a profiljához
Mi mehet rosszul?Rosszindulatú fájlt tölt fel (.php, .exe), túl nagy fájlt tölt fel
Mit teszünk ellene?Fájltípus ellenőrzés (whitelist!), méretkorlát, fájlnév sanitizálás
Megcsináltuk-e?Igen, szerver oldalon is (nem csak kliensoldalon)

Ez a gondolkodási folyamat – nem a pentest, nem az exploit-írás. Ez az, amit egy junior fejlesztőtől elvárnak.

Junior fejlesztő felelőssége és hatóköre

Fontos tisztázni: nem kell security expertté válnod. De van néhány dolog, ami egyértelműen a te felelősséged:

A te hatókörödbe esik:

  • Felhasználói input validálása (mindig, szerver oldalon is)
  • Jelszavak és szenzitív adatok helyes tárolása
  • SQL injection elkerülése (paraméteres lekérdezések)
  • Hibüzenetek nem informálják a támadókat
  • .env fájlok nem kerülnek gitbe
  • Authentication és authorization ellenőrzése új endpoint létrehozásakor

Nem a te hatókörödbe esik (de tudj róla):

  • Penetration testing (pentest)
  • Hálózati szintű védelem (firewall, IDS)
  • Cryptographic library implementálása nulláról
  • Compliance audit (GDPR, ISO 27001)

Ha egy PR-t írsz és nem tudod eldönteni, hogy egy security kérdés a te hatókörödbe esik-e, kérdezd meg. Ez már security mindset: felismerni, mikor kell kérdezni.

A leggyakoribb junior hiba: „Ki törne be ide?"

A legveszélyesebb gondolat a security terén: „ki akarná ezt megtámadni? Ez csak egy kis belső tool."

Néhány valóság:

  • A legtöbb támadás automatizált. Botok nem válogatnak „kis" és „nagy" célpontok között.
  • A belső tool-ok általában kevesebb védelmet kapnak, de ugyanolyan adatokhoz férnek hozzá.
  • Egy kompromittált belső account lehet belépési pont az egész infrastruktúrába.
  • A fejlesztők saját gépei is célpontok (supply chain attack).

Az elv: Egy funkciót mindig úgy implementálj, mintha mindenki meg akarná törni.

Security mindset a napi munkában – 5 szokás

Ezek nem egyszeri feladatok, hanem szokások, amelyeket minden egyes kódíráskor magadévá kell tenned:

1. Input mindig megbízhatatlan Minden, ami a felhasználótól, külső API-tól, URL-ből, form-ból jön – potenciálisan rosszindulatú. Validálj szerver oldalon.

2. Least privilege Csak annyi jogosultság, amennyi szükséges. Az adatbázis user csak azokat a táblákat érje el, amelyekre tényleg szüksége van. Az API token csak azt tehesse, amire való.

3. Hibák ne adjanak információt A felhasználó nem kell tudja, hogy MySQL-t használsz, hogy melyik tábla hiányzik, vagy hogy mi az internal szerver state. Barátságos hibaüzenet a felhasználónak, részletes log csak a te konzolodra.

4. Szenzitív adat nem kerül logba Soha ne logolj jelszót, tokent, hitelkártyaszámot. Még debug módban sem. A log fájlokhoz rendszerint több ember fér hozzá, mint gondolnád.

5. Dependency-ket is figyelj Egy npm csomag, amit használsz, szintén lehet sebezhető. A npm audit / pip-audit / composer audit parancsok erre valók – futtasd őket rendszeresen.

Életszerű példák

Példa 1: A „kis belső admin panel" esete

Egy junior fejlesztő kap egy feladatot: „Csináld meg az admin panelt a felhasználók törléséhez." Gyorsan megírja, működik. De:

  • Az admin panel URL-je /admin – nem védi semmilyen authentikáció
  • A törlés gomb direktben a user ID-t küldi (DELETE /users/42)
  • Nincs CSRF védelem

Valaki (akár egy rosszindulatú link) el tudja küldeni ezt a kérést a admin nevében. Egyetlen felhasználó is véletlenül megnyithat egy manipulált linket és adatot törölhet.

Security mindset: Mielőtt implementálsz egy admin funkciót, kérdezd meg: ki ér hozzá? Hogyan ellenőrzöd, hogy valóban ő az? Mi történik, ha valaki más küldi ezt a kérést?

Példa 2: A „csak logolom" hiba

# Rossz - szenzitív adatot logol
logger.debug(f"User logged in: {user.email}, password: {password}")

# Helyes - csak az azonosítót logolod
logger.debug(f"User logged in: user_id={user.id}")

Ez a kód valószínűleg soha nem kerül production-ba review nélkül... vagy mégis? És ha igen, a logokat olvasó DevOps kolléga most látja az összes felhasználó jelszavát. Security breach, amit egyetlen sorral el lehetett volna kerülni.

Példa 3: Az „ez csak fejlesztési token" sztori

Junior fejlesztő push-ol egy commitot, amiben benne marad egy API kulcs:

// config.js - TILOS gitbe pusholni!
const API_KEY = "sk-prod-abc123xyz...";

GitHub automatikusan scanneli a pusholt kódot, de sok esetben a kulcs néhány percen belül kompromittálódik – automatizált botok figyelik a GitHub pushokat és azonnal megpróbálják felhasználni az API kulcsokat. Ez nem elméleti – ez naponta megtörténik fejlesztőkkel.

Megoldás: .env fájl + .gitignore + titkos adat soha nem kerül kódba. Erről bővebben: 8.2-es alfejezet és 10.5-ös alfejezet.

Példa 4: Shift-left a valóságban

Egy startup csapatában dolgozol. Kapod a feladatot: „Implementálj egy keresési funkciót."

A shift-left nélküli verzió:

  • Gyorsan megírod: SELECT * FROM products WHERE name LIKE '%{user_input}%'
  • Működik, merge-led, production-ba kerül
  • 3 héttel később a security audit SQL injection sebezhetőséget talál
  • Javítás: újra tesztelés, hotfix deploy, az összes érintett endpoint felülvizsgálata

A shift-left verzió:

  • Megírod a paraméteres lekérdezéssel: (lásd 10.3-as alfejezet)
  • Rájössz, hogy ez ugyanannyi idő, ha eleve így csinálod
  • Nincs incidens, nincs hotfix, nincs stressz

Feladatok és tesztek

Gyakorlati feladat

Szituáció: Te vagy a reviewer az alábbi PR-on. A junior fejlesztő implementált egy egyszerű „jelszó-visszaállítás" funkciót. Nézd meg a következő pszeudokódot, és azonosítsd, milyen security szempontból hiányzó elemek vannak, illetve milyen security mindset hibák figyelhetők meg a kódban:

# password_reset.py

def reset_password(request):
    email = request.form['email']
    
    # Ellenőrizzük, van-e ilyen felhasználó
    user = db.query(f"SELECT * FROM users WHERE email = '{email}'")
    
    if user:
        new_password = request.form['new_password']
        
        # Frissítjük a jelszót
        db.query(f"UPDATE users SET password = '{new_password}' WHERE email = '{email}'")
        
        logger.info(f"Password reset for {email}, new password: {new_password}")
        
        return "Jelszó sikeresen megváltoztatva!"
    else:
        return "Nem találtunk felhasználót ezzel az email címmel."

Feladatod: Listázd fel legalább 4 security problémát, és minden problémához írj egy 1-2 mondatos magyarázatot, hogy mi a kockázat!

(Megoldás útmutató: SQL injection, plaintext jelszó tárolás, jelszó logolása, email enumeration lehetőség – ez utóbbi az "else" ág: megmondod a támadónak, hogy az email nem létezik)

Tesztkérdések

1. kérdés: Mi a „shift-left security" elv lényege?

a) A security csapatot korábban kell felvenni a projektbe
b) Biztonsági szempontokat minél korábban kell bevonni a fejlesztési folyamatba
c) A security audit-ot a fejlesztés bal oldalán kell elvégezni
d) A fejlesztőknek security expertekké kell válniuk

(Helyes: b)

2. kérdés: Melyik állítás igaz a junior fejlesztők security felelősségével kapcsolatban?

a) A junior fejlesztőnek nem kell foglalkoznia security-vel, ez a senior dolga
b) A junior fejlesztőnek penetration tesztelést kell végeznie a saját kódján
c) A junior fejlesztőnek alapvető security tudatosságot kell mutatnia (input validáció, szenzitív adatok kezelése)
d) A junior fejlesztő csak akkor felelős, ha dedikált security feladatot kap

(Helyes: c)

3. kérdés: Egy fejlesztő azt mondja: „Ez csak egy belső tool, senki nem fogja megtámadni." Mi a gond ezzel a gondolkodásmóddal?

a) Semmi, belső tool-ok valóban kevésbé veszélyesek
b) A belső tool-ok általában kevesebb védelmet kapnak, de ugyanolyan adatokhoz férhetnek hozzá és belépési pontot jelenthetnek
c) A belső tool-okat a cég tűzfala védi, szóval a fejlesztőnek valóban nem kell foglalkoznia a security-vel
d) Ez helyes gondolkodás, a security erőforrásokat a publikus felületekre kell összpontosítani

(Helyes: b)

4. kérdés: Melyik NEM esik egy junior fejlesztő hatókörébe security szempontból?

a) Felhasználói input validálása
b) Penetration testing elvégzése
c) .env fájlok gitignore-ba tétele
d) Hibüzenetek nem informálják a támadókat

(Helyes: b)

5. kérdés: Mi a threat modeling legegyszerűbb formája?

a) Egy részletes biztonsági audit elvégzése minden deploy előtt
b) Külső security szakértő bevonása a fejlesztési folyamatba
c) Átgondolni fejlesztés közben: mit építünk, mi mehet rosszul, mit teszünk ellene, megcsináltuk-e?
d) OWASP Top 10 lista alkalmazása minden PR-ban

(Helyes: c)

6. kérdés: Mi a helyes megközelítés logolás során?

a) Mindent logolj debug módban, később lehet szűrni
b) Logolj user ID-kat és eseményeket, de soha ne logolj jelszót, tokent, szenzitív adatot
c) A logolás nincs kapcsolatban a security-vel, ez csak debugging eszköz
d) Production-ban ne logolj semmit, hogy ne legyen mire hivatkozni egy audit során

(Helyes: b)

7. kérdés: Melyik szituációban NEM alkalmazandó a „least privilege" elve?

a) Adatbázis felhasználói jogosultságok beállításakor
b) API tokenek scope-jának meghatározásakor
c) Fejlesztői IDE plugin-ok telepítésekor – ez nem security kérdés
d) Microservice-ek közötti kommunikáció engedélyezésekor

(Helyes: c – ez kicsit trükkös: a fejlesztői gép is támadási felület, de ez nem a legközvetlenebb alkalmazása a least privilege elvnek. Ez a kérdés arra keresi a választ, hogy melyik a legkevésbé nyilvánvaló alkalmazási terület.)

8. kérdés: Egy API kulcs véletlenül bekerült egy publikus GitHub repóba. Mi a legfontosabb ELSŐ lépés?

a) Törlöd a commitot git rebase-zel
b) Privátra állítod a repót
c) Azonnal visszavonod/invalidálod az API kulcsot a szolgáltatónál
d) Értesíted a security csapatot és vársz az utasításokra

(Helyes: c – a kulcs törlése a gitből nem elegendő, ha már publikálódott. Az azonnali invalidálás a legfontosabb első lépés, ezután jöhet minden más.)

9. kérdés: Mit jelent az, hogy a hibaüzenetek „nem informálják a támadókat"?

a) A hibaüzenetek ne legyenek túl barátságosak, hogy a felhasználók ne használják ki azokat
b) A felhasználónak látható hibaüzenet ne tartalmazzon rendszer-belső részleteket (DB típus, stack trace, táblaneveket)
c) A hibaüzeneteket teljesen el kell rejteni, a felhasználó ne kapjon semmilyen visszajelzést
d) Csak autentikált felhasználóknak szabad hibaüzeneteket mutatni

(Helyes: b)

10. kérdés: Melyik gondolkodásmód jellemzi a security mindset-et leginkább?

a) „Ha valami működik, nem kell bántani – security javítást majd a security csapat hoz"
b) „Ez a feature úgyis belső, felesleges az extra complexity a security érdekében"
c) „Mielőtt implementálom, átgondolom: ki és hogyan élhet vissza ezzel a funkcióval?"
d) „Tanulmányozom az OWASP Top 10-et és minden lehetséges sebezhetőséget megelőzök"

(Helyes: c – a d) csábítónak tűnik, de a security mindset nem egy checklist, hanem egy gondolkodásmód)

Összefoglalás

A security mindset nem az jelenti, hogy security expertté válj. Azt jelenti, hogy fejlesztés közben aktívan gondolsz a kód biztonsági vonzataira – nem utólag, nem külső kérésre, hanem minden egyes PR-ban.

A legfontosabb öt gondolat, amit vigyél magaddal:

  1. Te vagy az első védelmi vonal – nem a security csapat, nem a tűzfal
  2. A legolcsóbb hiba az, amit fejlesztés közben találsz – shift-left
  3. „Ki törne be ide?" – rossz kérdés. A botok nem válogatnak
  4. Threat modeling nem rocket science – 4 kérdés, minden fejlesztési feladatnál
  5. Security mindset szokás, nem egyszeri feladat – input validáció, least privilege, szenzitív adatok kezelése

A következő alfejezetben konkrét sérülékenység-típusokkal ismerkedünk meg (OWASP Top 10) – azokkal, amelyekkel egy átlagos webfejlesztő a munka során ténylegesen találkozik.

Scroll to Top