Webalkalmazás penetrációs teszt
A webalkalmazások penetrációs tesztje kontrollált támadás az Ön rendszere ellen. Webalkalmazásokban, API-kban és mobilalkalmazásokban keressük a kihasználható hibákat – mielőtt olyasvalaki találná meg őket, aki nem jelenti be magát. Amit most megtalálunk, abból később nem lesz adatszivárgás, bírság vagy elvesztett ügyfél.
Ha rendelkezésre áll, a forráskódot is átnézzük. Kézzel tesztelünk; automatizált eszközt csak ott vetünk be, ahol tényleg gyorsít. A forgatókönyveket az OWASP Top 10 és az OWASP WSTG szerint állítjuk össze, mobilon pedig az OWASP MASVS szerint.
A munka végén vizsgálati jelentést kap: mit találtunk, hogyan reprodukálható, mekkora a kockázat és pontosan mit kell megváltoztatni.
Ők bíznak bennünk
Mi a webalkalmazás penetrációs teszt, és mi ellen véd?
A vizsgálat kontrollált támadás: előre egyeztetett hatókörben, írásos engedéllyel dolgozunk. Nem a szkenner találatait soroljuk fel – amit megtalálunk, azt ki is használjuk, és megmutatjuk, meddig jut el vele egy támadó.
A vizsgálat akkor hozza a legnagyobb hasznot, ha éles indulás előtt vagy nagyobb kiadás után futtatjuk – de akkor is van értelme, ha ügyfél, auditor vagy pályázat kér rá bizonyítékot. Ugyanezt a munkát a piac hol webalkalmazás sérülékenységvizsgálatnak, hol webalkalmazás-tesztelésnek, hol pentesztnek nevezi; az eredmény nem a névtől függ, hanem attól, ki végzi el.
Tapasztalat
Több mint 10 éve dolgozunk offenzív biztonságon: penetrációs teszt, Red Teaming, forráskódvizsgálat. Minden penteszterünknek OSCP-szintű tanúsítványa van.
Átláthatóság
Végig tudja, hol tartunk és mit vizsgálunk éppen. A hatókört és a határidőt az elején rögzítjük, nem menet közben.
Együttműködés
A fejlesztőivel közvetlenül egyeztetünk, nem csak a projektvezetővel. A jelentés alapján másnap el lehet kezdeni a javítást.
Szakmai színvonal
A Haxoris maga is ISO/IEC 27001 szerint tanúsított cég; a tanúsítványt a TÜV SÜD állította ki. A vizsgálat pedig soha nem lép ki az előre egyeztetett hatókörből.
Tesztelési folyamat
Hogyan zajlik a webalkalmazás penetrációs teszt?
A célok és a hatókör rögzítésével kezdünk. Utána jön a felderítés – előbb passzívan, majd aktívan –, és minden gyanús pontot megpróbálunk kihasználni. Amit nem sikerül, az nem kerül a jelentésbe: nem téves találatokat adunk át javításra.
Hatókör és célok
Megállapodunk abban, mely alkalmazás, mely API és mely felhasználói szerepkör tartozik a vizsgálatba.
Felderítés és elemzés
Passzív és aktív teszteket futtatunk, valós támadási utakra összpontosítva.
Kihasználhatóság igazolása
Minden megállapítást a gyakorlatban is kipróbálunk, és reprodukálható bizonyítékot rögzítünk hozzá.
Vizsgálati jelentés
Kockázat szerint sorba rendezett megállapításokat és konkrét javítási lépéseket adunk át.
Hatókör
Milyen alkalmazásokat és API-kat tesztelünk?
A teljes alkalmazást átvizsgáljuk: a böngészőben futó felülettől a mögötte dolgozó API-kig. Mindegyiknek megvan a maga tipikus gyenge pontja, és a teszteket ehhez igazítjuk.
Webalkalmazások
Sorra vesszük a bejelentkezést, a jogosultságokat, az injekciós hibákat, a munkamenet-kezelést és a szerver beállításait.
Mobilalkalmazások
Megnézzük, mit tárol az eszközön, hogyan titkosít és mit enged át a háttérrendszer felé. A mérce az OWASP MASVS.
API-k
A végpontokon a jogosultságokat, az adatkezelést és az üzleti logikát ellenőrizzük. A legtöbb komoly hiba itt bújik meg, a felület mögött.
Asztali alkalmazások
Vastagkliensnél azt nézzük meg, milyen érzékeny adat marad a gépen, milyen jogosultsággal fut az alkalmazás és mit küld a szerver felé.
Forráskódvizsgálat
Statikus elemzéssel és kézi átnézéssel a gyenge validációt és azokat a logikai hibákat találjuk meg, amelyekhez kívülről nem vezet út.
Módszertan
Mit vizsgálunk az OWASP Top 10 alapján?
Az OWASP Top 10 a leggyakoribb webes sebezhetőségek rangsora, nem ellenőrzőlista. A kockázati sorrendet innen vesszük, a tényleges lefedettséget viszont az OWASP WSTG adja: ez mondja meg tesztről tesztre, mit kell kipróbálni egy webalkalmazáson.
A gyakorlatban ez azt jelenti, hogy a jogosultsági hibákat, az injekciókat, a rossz beállításokat és az üzleti logika megkerülhető pontjait egyaránt végigvesszük – az API-kon is, ahol ugyanezek a hibák a felület mögött jóval tovább maradnak észrevétlenül.
Az OWASP nem tanúsítvány, és nem is lehet „megfelelni” neki: nyílt módszertan, amelyet a szakma tart karban. Épp ezért közös nyelv – a fejlesztő és az auditor is érti, mire hivatkozunk a jelentésben.
Összehasonlítás
Penetrációs teszt vagy forráskódvizsgálat?
A kettő nem helyettesíti egymást. A penetrációs teszt a futó alkalmazást támadja meg, a forráskódvizsgálat pedig azt találja meg, ami a kódban rossz – még az élesítés előtt.
| Szempont | Penetrációs teszt | Forráskódvizsgálat |
|---|---|---|
| Fókusz | A futó alkalmazás, a beállításai és az adatai. | A kódban rejlő logikai és biztonsági hibák. |
| Módszertan | Kézi tesztelés valós támadási technikákkal. | Statikus elemzés és kézi kódátnézés. |
| Időzítés | Élesítés után és minden nagyobb változtatáskor. | Még az élesítés előtt, fejlesztés közben. |
| Kimenet | Vizsgálati jelentés a tényleges hatással és a javítási sorrenddel. | Kódszintű megállapítások javítási javaslattal. |
Nem tudja, melyik kombináció kell? Írjon nekünk.
Ügyfélvélemények
Mit mondanak rólunk ügyfeleink
Gyakori kérdések (GYIK)
01 Mennyi ideig tart egy penetrációs teszt?
A hatókörtől függ. Kisebb webalkalmazásnál általában 3–5 nap, összetett rendszernél vagy teljes hálózatnál 1–3 hét. A pontos időigényt és a hatókört az első egyeztetés után írásban rögzítjük.
02 Mennyibe kerül egy webalkalmazás penetrációs tesztje?
A hatókör és az összetettség dönti el. A néhány szerepkörrel működő webalkalmazás lényegesen olcsóbb, mint a több tucat végpontot kiszolgáló API vagy a sok integrációt használó rendszer. Egy tipikus megbízás 5–15 szakértői nap. Egy rövid beszélgetés után, amelyben tisztázzuk a hatókört, fix árajánlatot adunk – ez semmire nem kötelezi.
03 Milyen gyakran kell penetrációs tesztet végezni?
Évente legalább egyszer és minden olyan változás után, amely átalakítja a támadási felületet: új alkalmazás élesítése, felhőbe költözés, nagyobb architektúraváltás. Pénzügyi intézménynél szigorúbb a mérce – az MNB 1/2025. (I. 13.) ajánlása az internet felől elérhető alkalmazásoknál élesítés előtt, minden biztonsági szempontból lényeges változás után, majd legalább évente vár el behatolásvizsgálatot. Ez felügyeleti elvárás, nem jogszabály.
04 Leállhat-e az alkalmazás a teszt alatt?
Nem. Éles rendszeren nem futtatunk olyan tesztet, amely szolgáltatáskiesést okozhat, a kockázatos lépéseket pedig előre egyeztetjük. Ha van külön tesztkörnyezet, ott dolgozunk; ha nincs, a nagyobb terhelésű vizsgálatokat karbantartási ablakba tesszük.
05 Mit kap a munka végén?
Vizsgálati jelentést: vezetői összefoglalót a döntéshozóknak, technikai leírást minden megállapításról, a reprodukálás lépéseit, a kockázati besorolást és a javítási javaslatot. Az eredményeket egy zárókonzultáción vesszük végig a csapatával, a javítások után pedig kérésre újratesztelünk.
