API-k biztonsági ellenőrzése weboldalához

API ellenőrzés magánügyfeleknek online munkában

Az API ellenőrzés akkor hasznos, ha egy webes rendszer, alkalmazás vagy külső szolgáltatás kapcsolata nem működik elég biztonságosan, vagy nem tudni pontosan, hol vannak benne kockázatok. A magánügyfél ilyenkor nem feltétlenül nagy vállalati auditot keres. Inkább egy olyan online szakember kell neki, aki átnézi a végpontokat, azonosítja a hibákat, és érthető jelentést ad arról, mit kell javítani.

Én azt látom, hogy sok ügyfél csak akkor kezd el API vizsgálattal foglalkozni, amikor már látható a gond. Például furcsa kérés érkezik a rendszerbe, hibásan működik a belépés, túl sok adat látszik egy válaszban, vagy egy fejlesztő jelezte, hogy a jogosultságkezelés nem elég tiszta. Pedig az alkalmazáskapcsolatok átnézése akkor a leghasznosabb, amikor még nincs baj. Egy tapasztalt freelancer nemcsak technikai hibákat keres. Azt is nézi, hogy a logika mennyire érthető, a hozzáférések hogyan vannak kezelve, és a dokumentáció alapján mennyire lehet biztonságosan használni a rendszert.

A Qjob.hu felületén olyan magánszakemberek is elérhetők, akik távolról vállalnak ilyen ellenőrzést. Ez praktikus, mert a munka nagy része dokumentációból, tesztelési hozzáférésből, képernyőmegosztásból és írásos visszajelzésből áll. Nincs szükség személyes találkozóra. Fontosabb, hogy a megbízó pontosan meg tudja adni, milyen API-ról van szó, milyen adatok mozognak benne, milyen jogosultsági szintek vannak, és milyen eredményt vár.

API ellenőrzés fő kockázatai

Az API-k gyakran olyan adatokat mozgatnak, amelyekhez nem minden felhasználónak kellene hozzáférnie. Sokan ott hibáznak, hogy az alkalmazás látható felületét tesztelik, de a háttérben működő végpontokat már nem. Így előfordulhat, hogy egy felhasználó csak a saját adatait látja a képernyőn, de egy módosított kérésben más azonosítóval már más adathoz is hozzáfér. Ez nem látványos hiba. De komoly gond lehet.

Az online szakember általában a hitelesítést, a jogosultságokat, az adatmezők láthatóságát, a kulcsok kezelését, a hibaválaszokat és a túlterhelés elleni védelmet vizsgálja. Az is fontos, hogy a belsőnek gondolt végpontok mennyire védettek. Tapasztalatom szerint sok kisebb projektben az a feltételezés él, hogy amit nem linkelnek nyilvánosan, az nincs veszélyben. Ez téves gondolkodás. Egy API akkor is támadási felület, ha csak fejlesztés közben készült, vagy csak egy mobilalkalmazás használja.

Az API biztonsági vizsgálat nem csak törésteszt lehet. Lehet gyors állapotfelmérés, dokumentációs átnézés, jogosultsági próba, terhelési kockázat ellenőrzése, vagy a fejlesztő által készített javítások újbóli ellenőrzése. Szerintem magánügyfeleknél a legjobb kezdés egy szűkített vizsgálat. Így gyorsan kiderül, van-e nagyobb probléma, és csak utána érdemes mélyebb tesztet kérni.

API audit árak és feladatméret

Az API audit ára főleg attól függ, hány végpontot kell vizsgálni, mennyire összetett a jogosultsági rendszer, van-e dokumentáció, és kell-e részletes javítási terv. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent. Nem azért, mert minden drága szakember jó. Hanem azért, mert a gondos vizsgálat időt igényel. Aki egy bonyolult rendszert pár óra alatt ígér teljesen átnézni, az sokszor csak felszínes listát ad.

Ezek az árak irányadóak. Egy egyszerű kapcsolatnál a vizsgálat olcsóbb lehet, főleg ha a megbízó előre elküldi a végpontlistát és a tesztelési adatokat. Egy összetettebb rendszer viszont több szerepkört és több hibaforgatókönyvet igényel. Ilyenkor a szakembernek nem elég végigkattintani a kéréseket. Gondolkodnia kell támadói szemmel is.

API biztonsági vizsgálat online menete

Az online munka első lépése a rövid egyeztetés. A megbízó leírja, milyen rendszerről van szó, mi a cél, és milyen hozzáférést tud adni. A specialistának szüksége lehet tesztfelhasználókra, próbakulcsokra, dokumentációra, végpontlistára, példakérésekre és információra arról, mi számít érzékeny adatnak. Minél tisztább az induló anyag, annál pontosabb lesz az API ellenőrzés.

Ezután jön a vizsgálat. A szakember általában kézi teszteket és segédeszközöket is használ. Megnézi, hogy a válaszok nem adnak-e ki túl sok információt, a hibakódok nem árulnak-e el belső részleteket, és az azonosítók módosításával nem lehet-e más adatokhoz jutni. Fontos rész a túl széles jogosultságok keresése is. Ha egy egyszerű felhasználó olyan műveletet tud végrehajtani, amely csak adminisztrátornak járna, akkor a hiba nem apró kényelmetlenség.

A végén a megbízó írásos anyagot kap. Ez lehet rövid összefoglaló vagy részletes jelentés. Jó esetben nem csak annyi áll benne, hogy van hiba. Benne van a kockázat szintje, a reprodukálás módja, a javítás iránya, és az is, mit érdemes először rendezni. Volt olyan eset, amikor egy ügyfél azt hitte, a problémát a lassú szerver okozza. A vizsgálat végén kiderült, hogy a gond egy rosszul korlátozott lekérdezés volt, amely sokkal több adatot adott vissza, mint kellett volna. A javítás nem volt hosszú, de a hiba megtalálása célzott ellenőrzést igényelt.

API szakember kiválasztása

API szakember választásánál nem elég azt nézni, hogy valaki általában ért-e a fejlesztéshez. Ehhez a munkához biztonsági szemlélet is kell. Jó jel, ha a freelancer rákérdez a jogosultsági szintekre, a tesztkörnyezetre, az adatvédelemre, a dokumentációra és arra, hogy szabad-e aktívabb próbákat végezni. Ha ezekről nem kérdez, akkor valószínűleg nem látja át a feladat határait.

Szerintem az is fontos, hogy a szakember érthetően írjon. Egy magánügyfélnek sokszor nincs szüksége hosszú, nehezen olvasható technikai anyagra. Kell egy világos lista, amelyből látszik, mi sürgős, mi közepes kockázat, és mi csak javítási javaslat. De a rövidség nem jelenthet felületességet. A jó jelentés konkrét. Tartalmaz példát, érthető magyarázatot és következő lépést.

Érdemes portfóliót vagy korábbi leírást kérni hasonló munkáról. Nem kell bizalmas részleteket látni. Elég, ha a szakember meg tudja mutatni, milyen formában ad át eredményt. Az is jó jel, ha előre rögzíti, mit nem vállal. Például nem végez éles rendszerben erős terhelési próbát külön engedély nélkül. Ez nem óvatosság nélküli munka. Ez szakmai fegyelem.

Gyakori hibák API tesztelés előtt

A leggyakoribb hiba a túl homályos megbízás. A megbízó csak annyit ír, hogy nézze át az API-t, de nem ad végpontlistát, nem mondja el a szerepköröket, és nem jelöli meg, mi számít problémának. Így a szakember sok időt tölt feltérképezéssel, és kevesebb marad valódi vizsgálatra. Ez drágítja a munkát, vagy gyengíti az eredményt.

Másik gyakori gond, hogy nincs tesztkörnyezet. Ha csak az éles rendszer érhető el, akkor óvatosabb vizsgálat kell. Ez néha elég, de nem mindig. Egy online szakember nem akar kárt okozni. Ezért előre tisztázni kell, milyen próbák engedélyezettek, milyen adatok használhatók, és mikor kell azonnal megállni.

Sokan azt is alábecsülik, hogy a javítás után újra kell nézni a hibát. Egy jogosultsági probléma javítása könnyen okozhat új mellékhatást. Ha nincs visszateszt, akkor csak feltételezés marad, hogy a hiba megszűnt. Tapasztalatom szerint a kisebb projektekben éppen ez marad ki leggyakrabban. Pedig a visszateszt sokszor rövidebb és olcsóbb, mint az első vizsgálat.

API ellenőrzés eredménye és átadása

Az API ellenőrzés akkor értékes, ha a megbízó a végén tud dönteni. Nem elég egy hosszú lista ismeretlen szavakkal. Használható eredmény kell. Egy jó átadás tartalmazza a legfontosabb hibákat, a kockázati sorrendet, a javítási javaslatot és azt, hogy melyik hiba milyen következménnyel járhat. Ha a fejlesztő kapja meg az anyagot, akkor technikai részlet is kell. Ha a tulajdonos olvassa először, akkor rövid vezetői összefoglaló is hasznos.

A kommunikáció általában online történik. Lehet üzenetben, hívásban vagy közös dokumentumban. A lényeg az, hogy a megbízó ne csak fájlt kapjon, hanem értse is, mi a teendő. Egy magánszakember előnye pont az lehet, hogy rugalmasabban magyaráz, mint egy nagyobb szolgáltató. De ez csak akkor működik, ha a feladat elején tiszta a határidő, a hozzáférés, az átadás formája és a javítások száma.

Az alkalmazáskapcsolatok ellenőrzése nem látványos szolgáltatás, de sok későbbi problémát megelőzhet. Ha az ügyfél előre elkészíti a rövid leírást, a tesztadatokat és az elvárt eredményt, akkor a munka gyorsabb és pontosabb lesz. És a végén nem csak egy technikai véleményt kap, hanem egy használható képet arról, mennyire biztonságos az API jelenlegi állapota.