# Penetrációs teszt és sérülékenységi vizsgálat | RootCore LLC

> Etikus hacker-tesztelés weboldalra, webshopra és szerverre: sérülékenységi vizsgálat, konfiguráció-review, részletes jelentés javítási sorrenddel, majd újratesztelés.

Oldal: https://cyber-security.rootcr.com/penetracios-teszt/
Frissítve: 2026-08-20

---

# Penetrációs teszt és sérülékenységi vizsgálat

> **Röviden:** A penetrációs teszt során ugyanazokkal a módszerekkel próbáljuk meg elérni a rendszerét, mint egy támadó — csak engedéllyel, dokumentáltan, és a végén megmondjuk, hogyan sikerült. A vizsgálat eredménye egy priorizált lista: mi kritikus, mi ráér, és melyik javítás mennyit ér. A javítás után újratesztelünk.

## Mi a különbség a sérülékenységi vizsgálat és a pentest között?

| | Sérülékenységi vizsgálat | Penetrációs teszt |
|---|---|---|
| Mit csinál | Ismert hibákat keres, jórészt automatizáltan | Kihasználja, amit talál, és tovább megy |
| Mit mutat meg | Mi *lehet* sebezhető | Meddig lehet valóban eljutni |
| Mennyi idő | Órák–egy nap | Napok |
| Mikor elég | Rendszeres állapotfelmérésre | Éles indulás előtt, incidens után, nagyobb rendszernél |

A legtöbb kkv-nak a kettő kombinációja hozza a legtöbbet: rendszeres vizsgálat, és évente vagy nagyobb változás után egy alaposabb teszt.

## Mit vizsgálunk?

- **Webalkalmazás:** bejelentkezés és munkamenet-kezelés, jogosultságok, űrlapok, fájlfeltöltés, API-végpontok, adatbeszúrásos hibák (SQL injection, XSS), üzleti logikai hibák.
- **Kiszolgáló:** nyitott portok, elavult verziók, gyenge titkosítás, kiszivárgó információ a hibaüzenetekben.
- **Konfiguráció:** biztonsági fejlécek, tanúsítványok, jogosultságok, mentések elérhetősége.
- **Hozzáférés:** alapértelmezett és gyenge jelszavak, felesleges fiókok, elfelejtett fejlesztői felületek.

## Mit kap a végén?

Egy jelentést, amit el lehet olvasni akkor is, ha nem biztonsági szakember:

1. **Vezetői összefoglaló** — mi a helyzet, mi a legnagyobb kockázat, mennyi munka a rendbetétel.
2. **Találatok súlyosság szerint**, mindegyiknél: mit találtunk, hogyan reprodukálható, mi a következménye, hogyan javítható.
3. **Javítási sorrend** — mi az, amit ma kell, mi a heti, mi a negyedéves feladat.
4. **Újratesztelés** a javítás után, írásban igazolva, hogy a lyuk tényleg bezárult.

## Hogyan indul?

A vizsgálat előtt írásban rögzítjük, mit szabad tesztelni és mit nem — cél-URL-ek, IP-tartományok, időablak, kizárt műveletek. Éles rendszernél a terhelést okozó teszteket egyeztetett időpontban futtatjuk. Az ingyenes felmérés ehhez nem kell: azt kívülről, forgalom nélkül végezzük.

## Gyakori kérdések

### Nem árt a tesztelés az éles rendszernek?

A vizsgálat túlnyomó része passzív vagy alacsony hatású. Ami terhelést okozhat, azt előre jelezzük és időzítjük. Az adatmódosító műveleteket éles adaton nem futtatunk, ilyet csak teszt-környezetben vagy külön engedéllyel csinálunk.

### Mennyi idő egy teszt?

Egy tipikus weboldal vagy webshop vizsgálata 3–7 munkanap, a rendszer méretétől és az API-k számától függően. A pontos időt a felmérés után mondjuk meg — előre találgatni nem érdemes.

### Kell hozzá hozzáférést adnom?

A külső (black box) teszthez nem. A jogosultsági hibák feltárásához viszont hasznos egy-egy tesztfiók a különböző szerepkörökből — ilyenkor az látszik, hogy egy sima felhasználó hozzáfér-e olyasmihez, amihez nem kellene.

### Mi történik a talált sérülékenységekkel?

A jelentésen kívül sehol nem jelennek meg, és harmadik félnek nem adjuk át. A jelentést titkosítva küldjük, és kérésre a javítás igazolása után törlünk minden munkapéldányt.

### Ha találtok valamit, ti javítjátok?

Ha kéri, igen — de nem feltétel. A jelentés úgy készül, hogy a saját fejlesztője is dolgozni tudjon belőle. Ha a javítást mi végezzük, a [szerverbiztonsági](/szerver-biztonsag/) és a [WAF-oldali](/waf-konfiguracio/) munkát is ugyanabban a keretben tudjuk elvégezni.