Amióta léteznek programok, léteznek API-k. Az API (Application Programming Interface, alkalmazásprogramozói felület) feladata ugyanis az, hogy képesek legyünk anélkül használni egy program(rendszer) szolgáltatásait, hogy magának a programnak a belső működését teljes mélységében ismernünk kellene. Valójában az API nem más, mint egy adott szoftver(rendszer) azon eljárásainak, valamint az eljárások használatának leírása, melyeket más programok igénybe tudnak venni.

Az API határozza meg, hogy az egyes programok hogyan értenek szót egymással: csatlakozófelületet biztosít, melyen keresztül megoszthatják egymással funkcióikat, és adatokat cserélhetnek, szabályozza a programok által küldött/fogadott kérések típusát, az használható adatformátumokat stb. Voltaképpen az API-k teszik lehetővé, hogy szervezetek adatokat osszanak meg ügyfeleikkel és más szervezetekkel.

API-k nélkül nehézkesebbek lenne az elektronikus fizetési tranzakciók lebonyolítása és feldolgozása, csatlakozás egy videokonferenciákhoz, a megosztás funkció használata a közösségi médiában stb. Gyorsítják az alkalmazásfejlesztést, mert a fejlesztőknek kész (szabványos) kapcsolódási felületet adnak más alkalmazásokhoz, így azokat nem kell újra és újra legyártani.

A Gartner egy 2021 végén kiadott előrejelzése (Predicts 2022: APIs Demand Improved Security and Management) szerint a vállalatok olyan tempóban gyártják az API-kat, hogy azt a hálózat- és alkalmazásbiztonsági gyakorlataik nem tudják lekövetni.

Biztonságos vagy olcsó?

Ennek azonban egyenes következménye, hogy az API-k sérülékenységeinek kezelése kiemelten fontos területté vált. Az olyan jellegű generális sérülékenységek ugyanis, mint például a IDOR (Insecure Direct Object References vagy nem biztonságos közvetlen objektumhivatkozások), amelyről a közelmúltban a CISA is kiadott egy riasztást, sok millió felhasználó adatait szolgáltathatja ki kiberbűnözőknek. Nem véletlen, hogy ma már nincs is olyan számba vehető biztonsági megoldásszállító, amely nem kínálna megoldát az API-k biztonsági menedzsmentjéhez – általában webes alkalmazások védelmével összekapcsolva.

Ma alapvetően két megközelítés terjedt el az API-k megvalósítására: a SOAP és a REST.

A SOAP (Simple Object Access Protocol) XML-alapú üzenetküldő protokoll, amelynek beépített biztonsági szabványa (WS-Security) XML-titkosítás, XML-aláírás és SAML-tokenek (Security Assertion Markup Language) segítségével védi a tranzakciókat.

A REST (Representational State Transfer) a HTTP protokollt használja, és SSL-hitelesítéssel védi a kommunikációt. Mivel a REST esetében minden egyes HTTP-kérés tartalmazza az összes szükséges információt (azaz állapotmentes), sem a kliensnek, sem a szervernek nem kell adatokat tárolnia a kérés teljesítéséhez. Míg a SOAP esetében minden egyes kérésnek át kell esnie az elemzési és routing fázison, a REST szabványos HTTP-kéréseket használ, és nem igényli az adatok újracsomagolását. Az Imperva egy elemzésében azonban arra hívja fel a figyelmet, hogy a SOAP használata ugyan nehézkesebb (és költségesebb), mint a REST-é, de átfogóbb biztonságot lehet vele megvalósítani, így a complienace-előírások miatt bizonyos szervezeteknek előnyösebb lehet.

Az API-biztonság legfontosabb kihívásai

A terület felértékelődését mutatja, hogy az OWASP (Open Worldwide Application Security Project) 2019-ben elindította az API Security Projektet, amelyben szakértők széles körének segítségével rögzítette az alkalmazásprogramozói interfészekkel kapcsolatos legfontosabb biztonsági kihívásokat. A miértre a kiadvány első, 2019-es kiadása három választ ad. (1) Az API az alkalmazásvezérelt világban az innováció alapvető eleme, amely minden területen (pénzügyi szektor, kiskereskedelem, közlekedés, IoT, autonóm járművek, intelligens városok stb.) és minden alkalmazástípus (mobil és webes app, SaaS stb.) kritikus részét képezi. (2) Az API-k természetüknél fogva hozzáférést biztosítanak az alkalmazáslogikákhoz és az érzékeny információkhoz (pl. személyazonosításra alkalmas adatok) egyaránt. (3) API-k nélkül lehetetlen a gyors innováció.

És hogy mennyire így van, azt jól jellemzi az az adat, melyet a Palo Alto Networks egy a témával foglalkozó tanulmányában idéz: 2022-be csak a Postman API-menedzsment platform 1,13 milliárd API-hívást regisztrált. (A Postmannek saját bevallása szerint mintegy 25 millió regisztrált felhasználója van, és 75 ezer nyílt API-t kezel, amivel a legnagyobb ilyen jellegű platform.)

Ugyanebben a tanulmányukban a Palo Alto szakértői találóan foglalják össze azt is, hogy miben különbözik az API-központú biztonság a webes alkalmazások biztonságának hagyományos megközelítésétől. Amikor még a szervezetek kizárólag monolit alkalmazásokat használtak, a biztonsághoz elég volt a hálózat határára telepíteni egy webes alkalmazástűzfalat (web application firewall, WAF), amely megszűrte a webes kliensek HTTP-forgalmát.

Csakhogy a világ megváltozott: a dedikált webszervereken futó monolitikus alkalmazások helyét átvették a konténerizált, felhő-natív (jellemzően mikroszolgáltatásokból építkező) alkalmazások, melyek fürtözött gazdaszerver-infrastruktúrán futnak. Az erősen elosztott, felhő-natív mikroszolgáltatás-architektúra lebontotta a hálózatok külső határait. A modern alkalmazásoknak a kapcsolatok széles skáláját kell kezelniük: szabványos webes kéréseket, mobileszközök API-hívásait, felhőeseményeket, de érinti őket az IoT-eszközök telemetriai kommunikációja, a felhőalapú tárolás és még hosszan lehetne sorolni, hogy mi minden. Ha egy mikroszolgáltatás-architektúrára épülő rendszerbe HTTP-kérés érkezik az egyik kliensről, az jellemzően csak a kommunikációs folyamat első lépése, amely aztán több tucat belső API-hívást generál(hat). Ha nem gondoskodunk ezeknek a belső API-hívásoknak az ellenőrzéséről és validálásáról, akkor az API-végpontok gyakorlatilag védtelenek lesznek.

Itt már nem elég a hálózat határánál kiszűrni a veszélyforrásokat. (Fontos azonban megjegyezni: a WAF-ok továbbra is hatékony védelmet nyújtanak például a szabványos webes űrlapokba vagy böngészőkérésekbe ágyazott rosszindulatú felhasználói bemenetekkel szemben.) A belső API-végpontok elkonfigurálásával ugyanis jogosulatlan hozzáférést lehet szerezni az egyes mikroszolgáltatásokhoz. Ezért minden belső és külső API-végpontot folyamatosan kell felügyelni és védeni.

A legsúlyosabb problémák

Az OWASP négy év után idén nyáron frissítette az API-k legfontosabb biztonsági kihívásait elemző listáját. Bár új elemek is kerültek a súlyos kockázatok közé, egy dolog nem változott 2019-hez képest: az API-knál az autorizálás maradt a legnagyobb kihívás, a három legfontosabb kockázat továbbra is ezzel függ össze.

Új elemként megjelent a top 10-es listán az érzékeny üzleti folyamatokhoz való korlátlan hozzáférés. Ez a kockázati tényező az alkalmazások körültekintő megtervezésével és kivitelezésével, valamint a biztonságot szem előtt tartó fejlesztési folyamattal csökkenthető. Mivel az API-k könnyű hozzáférést biztosítanak a botok számára, kulcsfontosságú az érzékeny üzleti folyamatok azonosítása és a megfelelő védelmi intézkedések kiválasztása.

Szintén újdonság a szerveroldali kérés hamisítása (server side request forgery, SSRF). Ez nem új sebezhetőség, de az API-alapú alkalmazások terjedésével gyakoribbá vált, mivel egyes webes szolgáltatások REST API-jain keresztül viszonylag könnyen kihasználható.

Mint az Imperva felhívja a figyelmet, az SSRF mellett vannak további, már ismert támadástípusok is, melyek az API-alapú alkalmazások terjedésével szaporodtak el. Újabban például a kiberbűnözők webes API-k ellen indítanak elosztott szolgáltatásmegtagadásos támadást (DDoS). Úgy terhelnek túl webszervereket, hogy az API-kat árasztják el nagy mennyiségű kéréssel.

A botnet-üzemeltetők is egyre gyakrabban támadják API-kat, mert azokon keresztül közvetlenül el tudnak jutni adott rendszerben érzékeny adatokhoz. Ezeket az automatizált támadásokat ráadásul egyre nehezebb észlelni, állítja a tanulmány, mert a botok mind tökéletesebben imitálják az emberi viselkedést, miközben éjjel-nappal képesek ismételni ugyanazt a feladatot. Az ilyen típusú támadások ellen csak összetett védelmi rendszerekkel (pl. botészlelés és API-védelem kombinálása) lehet védekezni, olvasható a tanulmányban.

Ez a cikk független szerkesztőségi tartalom, mely a Clico Hungary támogatásával készült. Részletek »