Alkalmazásbiztonsági tesztelés: OWASP Top 10, SAST, DAST és SCA Képzés

A01:2025 – Hibás hozzáférési kontroll

A hozzáférési kontroll biztosítja a szabályzat érvényesülését, amelynek eredményeként a felhasználók nem léphetik túl a számukra szánt jogosultságocon. A kudarcok jellemzően nem jogosult információnak meglehet, módosítás vagy megsemmisítéséhez, vagy a felhasználói korlátok túllépéséhez vezetnek.

Gyakorlati szempontok

• Gyakorlati példák a hibás hozzáférési kontrollra

• Biztonságos hozzáférési kontroll és legjobb gyakorlatok

A02:2025 – Biztonsági hibabeállítás

A biztonsági hibabeállítás akkor fordul elő, amikor a rendszert, alkalmazást vagy felhőszolgáltatást a biztonság szempontjából hibásan állítják be, ami sérülékenységet eredményez.

Gyakorlati szempontok

• Valós példapldák a hibabeállításokra

• Lépések a hibabeállítás megelőzésére, beleértve a konfigurációkezelést és az automatizálási eszközöket

A03:2025 – Szoftverellátási lánc kudarc

A szoftverellátási lánc kudarc a szoftver felépítésének, terjesztésének vagy frissítésének folyamatában fellépő zavarok vagy más kompromittálások. Ezeket gyakran a rendszer által függő harmadik féltől származó kódok, eszközök vagy más függőségekben rejlő sérülékenységek vagy rosszindulatú változtatások okozzák.

A04:2025 – Kriptográfiai kudarc

Általánosságban elmondható, hogy az összes átmeneti adatot a transzportrétegen (OSI 4. réteg) titkosítani kell. A korábbi akadályok, mint például a CPU teljesítménye és a privát kulcs/tanúsítvány kezelése, ma már megoldottak: a CPU-k olyan utasításokkal rendelkeznek, amelyek gyorsítják a titkosítást (pl. AES támogatás), és a privát kulcsok és tanúsítványok kezelése egyszerűsödött a LetsEncrypt.org, valamint a nagy felhős szolgáltatók által kínált, szorosan integrált tanúsítványkezelési szolgáltatások révén.

A transzportréteg biztonságának biztosítása mellett fontos meghatározni, hogy mely adatokat kell nyugalomban tárolva titkosítani, és mely adatokat kell plusz titkosítás alá helyezni átmenet közben (az alkalmazási rétegen, OSI 7. réteg).

Például a jelszavak, bankkártyaszámok, egészségügyi rekordok, személyes adatok és üzleti titkok plusz védelmet igényelnek, különösen akkor, ha az adott adatok az adatvédelmi törvények hatálya alá esnek, például az Európai Unió Általános Adatvédelmi Rendelete (GDPR), vagy a PCI Adatbiztonsági Szabvány (PCI DSS) mint szabályozás.

Gyakorlati szempontok

• Részletes elemzés a kriptográfiai kudarcokról, például gyenge titkosítási algoritmusokról vagy helytelen kulcskezelésről

• Erős kriptográfiai mechanizmusok fontossága, biztonságos protokollok (SSL/TLS) és a modern kriptográfia példái a webes biztonságban

A05:2025 – Injekció

Egy injekciós sérülékenység a rendszer egy olyan hibája, amely lehetővé teszi a támadó számára, hogy rosszindulatú kódot vagy parancsokat (például SQL- vagy shell-kódot) beillesszen a program bemeneti mezőibe, és megtéveszze a rendszert úgy, hogy a kódot vagy parancsot a rendszer sajátjának tekintve hajtja végre. Ez komoly következményekhez vezethet.

Gyakorlati szempontok

• Részletes leírás a SQL, NoSQL, OS és LDAP injekcióról

• Enyhítési technikák előkészített nyilatkozatokkal, paraméterezett lekérdezésekkel és a bemenetek escapolásával

A06:2025 – Nem biztonságos tervezés

A nem biztonságos tervezés egy tág kategória, amely különböző gyengeségeket jelöl, és „hiányzó vagy hatástartalanságos kontrolltervezésként” fejeződik ki.

A nem biztonságos tervezés nem a Top Ten többi kockázati kategória forrása. Meg kell különböztetni a nem biztonságos tervezést és a nem biztonságos implementációt. Okos dolog a tervezési hibákat és az implementációs hibákat elkülöníteni, mert más-más gyökerű okokból fakadnak, a fejlesztési folyamat más szakaszaiban jelentkezik, és eltérő javítást igényelnek.

Egy biztonságos tervezésben is lehetnek implementációs hibák, amelyek sérülékenységet eredményeznek, és kihasználhatók lehetnek. Egy nem biztonságos tervezés nem javítható tökéletes implementációval, mert a szükséges biztonsági kontrollokat soha nem hozták létre a specifikus támadások elleni védelemre.

Az a tényező, amely hozzájárul a nem biztonságos tervezéshez, a fejlesztés alatt álló szoftver vagy rendszer sajátos üzleti kockázatelemzésének hiánya, és így a szükséges biztonsági tervezési szint megállapításának elmaradása.

Gyakorlati szempontok

• Ugyanúgy vizsgáljuk meg a tervezési hibákat, amelyek sérülékenységet eredményezhetnek, mint például a helytelen bemeneti validáció

• Alaposan tanulmányozzuk a biztonságos architektúra stratégiáit és a biztonságos tervezési elveket

A07:2025 – Hitelesítési hibák

Ha egy támadó képes megtéveszteni a rendszert, hogy érvénytelen vagy helytelen felhasználót is legitimnek fogadjon el, akkor ez a sérülékenység fennáll.

Gyakorlati szempontok

• Gyakori hitelesítési problémák

• Biztonságos hitelesítési stratégiák, mint például a többfaktoros hitelesítés és a megfelelő munkamenet-kezelés

A08:2025 – Szoftver- vagy adatintegritási hibák

A szoftver- és adatintegritási hibák a kódra és az infrastruktúrára vonatkoznak, amelyek nem védik a rendszert attól, hogy az érvénytelen vagy megbízhatatlan kódot vagy adatot megbízhatónak és érvényesnek kezeli.

Egy példa erre, amikor egy alkalmazás megbízhatatlan forrásokból, adattárokból vagy tartalom-elosztó hálózatokból (CDN) származó bővítményekre, könyvtárakra vagy modulokra támaszkodik.

Egy nem biztonságos CI/CD pipeline, amely nem fogyaszt és nem biztosít szoftverintegritási ellenőrzéseket, felhívhatja a nem jogosult hozzáférés, a nem biztonságos vagy rosszindulatú kód, vagy a rendszer kompromittálásának lehetőségét.

Egy másik példa erre, amikor egy CI/CD megbízhatatlan helyekről húz kódot vagy artefaktumokat, és/vagy nem ellenőrzi őket az előrehaladás előtt (általában aláírás ellenőrzése vagy hasonló mechanizmus révén).

Gyakorlati szempontok

• Fókusz olyan problémákra, mint az megbízhatatlan szoftverfrissítések és az adatkódolás

• Biztonságos frissítési mechanizmusok és adatintegritási ellenőrzések

A09:2025 – Biztonsági naplózás és figyelmeztetés hiánya

Naplózás és monitoring nélkül a támadások és a behatolások nem érezhetők, és figyelmeztetés nélkül nagyon nehéz gyorsan és hatékonyan reagálni egy biztonsági incidens alatt.

A naplózás, a folyamatos monitorozás, a detektálás és a figyelmeztetés hiánya, hogy aktív válaszokat indítson, bármikor előfordul.

Gyakorlati szempontok

• A biztonsággal összefüggő információk naplózásának fontossága és a gyanús aktivitások monitorozása

• Eszközök és gyakorlatok a megfelelő naplózásra és a valós idejű monitorozásra a behatolások korai detektálására

A10:2025 – Kivételes állapotok hibás kezelése

A szoftverben a kivételes állapotok hibás kezelése akkor következik be, amikor a programok nem tudják megakadályozni, észlelni és kezelni a szokatlan és váratlan helyzeteket, ami összeomlásokhoz, váratlan viselkedéshez, és néha sérülékenységekhez vezethet.

Ez az alábbiakból álló három kudarc egyike vagy több:

• Az alkalmazás nem akadályozza meg a szokatlan helyzet bekövetkezését

• Nem azonosítja a helyzetet, ahogy az történik

• Rosszul vagy egyáltalán nem reagál a helyzetre utána

SAST – Sztatikus Alkalmazásbiztonsági Tesztelés

1. Mi a statikus elemzés és mikor érdemes futtatni az SDLC-ben (shift left)

2. Sérülékenységek típusai, amelyeket a SAST detektál, sérülékeny kód vs biztonságos kód

3. A SAST eszközök áttekintése (pl. Semgrep, SonarQube, Checkmarx, a klienstechnológia szerint)

4. Gyakorlati gyakorlat: futtass SAST szkennelést egy szándékosan beépített sérülékenységekkel rendelkező repozitóriumon, értelmezd az eredményeket, triázs a hamis pozitívokat és az igazi sérülékenységeket

DAST – Dinamikus Alkalmazásbiztonsági Tesztelés

1. A SAST és DAST közötti különbség, fekete dobozos tesztelés a futó alkalmazáson

2. A DAST szkennelés menete, böngészés, fuzzer, válasz elemzés

3. A DAST eszközök áttekintése (pl. OWASP ZAP, Burp Suite)

4. Gyakorlati gyakorlat: futtass DAST szkennelést egy sérülékeny tesztalkalmazáson (pl. OWASP Juice Shop), azonosítsd és validáld az eredményeket

SCA – Szoftverösszetétel-elemzés

1. Harmadik féltől származó függőségek és könyvtárak kockázata, örökölt sérülékenységek

2. SBOM, Szoftverösszetétel-lista, mi az és miért fontos

3. A SCA eszközök áttekintése (pl. Dependency Check, Snyk, GitHub Dependabot)

4. Gyakorlati gyakorlat: futtass SCA szkennelést egy valós projekten, azonosítsd a sérülékeny függőségeket, és dolgozz ki egy javítási tervet (frissítés, javítás, enyhítés)