a webes alkalmazásprogramozási interfészek (API-k) biztosítják a modern webes és mobil alkalmazások hátterét. A webes API-hívások az összes webes forgalom több mint 80% – át teszik ki, és a kiberbűnözők egyre inkább az API-kat célozzák meg, így a webes API biztonságának biztosítása kulcsfontosságú. A REST API-k a webszolgáltatások leggyakoribb webes API-típusai. Lássuk, mit tehet a REST API biztonságának biztosítása érdekében.
- mi az a REST API?
- a REST API biztonság két szintje
- biztonságos API-hozzáférés biztosítása
- Kapcsolatbiztonság
- API hozzáférés-vezérlés
- felhasználói jogosultság API-kulcsokkal
- API Client Restrictions
- API-kat felfedő alkalmazások védelme
- érzékeny adatok az API kommunikációban
- tartalomtípus-érvényesítés
- Válaszbiztonsági fejlécek
- Input Validation
- miért fontos a REST API biztonsága?
- A szerzőről
mi az a REST API?
a REST (a REpresentational State Transfer rövidítése) egy Szoftverarchitektúra stílus a webfejlesztéshez, amelyet általában HTTP kommunikációval használnak. A RESTful API-k (vagy egyszerűen REST API-k) olyan alkalmazásprogramozási felületek, amelyek a REST alapelveit követik, lehetővé téve a webes kliensek és szerverek számára, hogy a webes erőforrások széles skálájával lépjenek kapcsolatba. A REST API-k szabványos HTTP-igéket (metódusokat) és állapotkódokat használnak a szabványosítás bizonyos szintjének biztosításához. HTTP URL-eken keresztül érhetők el, és széles körben használják a webes szolgáltatásokhoz.
Megjegyzés: A REST API-k hontalanok, mint maga a HTTP protokoll, ami azt jelenti, hogy nem tárolnak semmilyen információt az aktuális kapcsolatokról vagy munkamenetekről. A RESTful webszolgáltatások lehetővé teszik az erőforrások elérését és manipulálását, míg a munkamenetkezelést az alkalmazásnak kell kezelnie.
a REST API biztonság két szintje
mielőtt belemennénk a technikai részletekbe, egy fontos dolgot meg kell jegyeznünk. A webes API felületet tesz ki egy webes alkalmazásnak, ezért két szinten kell gondolkodnia a biztonságról: hozzáférés az API-hoz, majd hozzáférés az alkalmazáshoz.
API szinten megfelelő hitelesítésre, engedélyezésre, hozzáférési jogosultságokra és így tovább van szükség annak biztosításához, hogy csak az engedélyezett ügyfelek használhassák az interfészt, és csak az engedélyezett műveleteket hajthassák végre. Az alkalmazás szintjén meg kell győződnie arról, hogy az alkalmazás végpontjai (a felület eléréséhez használt URL-ek) nem sérülékenyek a felületen áthaladó vagy azt megkerülő támadásokkal szemben.
lássuk, hogyan biztosíthatja a REST API biztonságát ezen a két szinten. Az API biztonsági bevált gyakorlatok részletes megvitatását lásd az OWASP REST Security Cheat Sheet – ben.
biztonságos API-hozzáférés biztosítása
a legtöbb webes API ki van téve az internetnek, ezért megfelelő biztonsági mechanizmusokra van szükségük a visszaélések megelőzésére, az érzékeny adatok védelmére, valamint annak biztosítására, hogy csak hitelesített és felhatalmazott felhasználók férhessenek hozzá.
Kapcsolatbiztonság
a biztonság magával a HTTP-kapcsolattal kezdődik. A Secure REST API-knak csak HTTPS végpontokat kell biztosítaniuk annak biztosítására, hogy az API-kommunikáció SSL/TLS használatával titkosítva legyen. Ez lehetővé teszi az ügyfelek számára a szolgáltatás hitelesítését, valamint védi az API hitelesítő adatait és a továbbított adatokat.
API hozzáférés-vezérlés
számos webes API csak hitelesített felhasználók számára érhető el, például azért, mert privát, vagy regisztrációt vagy fizetést igényel. Mivel a REST API-k állapotmentesek, a hozzáférés-vezérlést a helyi végpontok kezelik. A leggyakoribb REST API hitelesítési módszerek a következők:
- HTTP alap hitelesítés: a hitelesítő adatokat közvetlenül a HTTP fejlécekben küldik el a Base64 kódolásban, titkosítás nélkül. Ez a legegyszerűbb hitelesítési módszer és a legkönnyebben megvalósítható. Ez a legkevésbé biztonságos is, mivel a bizalmas adatokat egyszerű szövegként továbbítják, ezért csak HTTPS-szel kombinálva szabad használni.
- JSON Web tokenek (JWT): a hitelesítő adatok és egyéb hozzáférési paraméterek JSON adatstruktúraként kerülnek elküldésre. Ezek a hozzáférési tokenek kriptográfiailag aláírhatók, és a REST API-khoz való hozzáférés szabályozásának előnyben részesített módja. Lásd az OWASP JWT Cheat Sheet egy gyors áttekintést JSON Web tokenek, RFC 7519 a teljes specifikáció.
- OAuth: szabványos OAuth 2.0 mechanizmusok használhatók hitelesítésre és hitelesítésre. Az OpenID Connect lehetővé teszi a biztonságos hitelesítést az OAuth 2.0-n keresztül. A Google API-jai például az OAuth 2.0-t használják hitelesítésre és hitelesítésre.
felhasználói jogosultság API-kulcsokkal
az API-kulcsok lehetővé teszik a nyilvános REST-szolgáltatásokhoz való hozzáférés ellenőrzését. A nyilvános webszolgáltatások üzemeltetői API-kulcsokat használhatnak az API-hívások sebességkorlátozásának kikényszerítésére és a szolgáltatásmegtagadási támadások enyhítésére. Bevételszerzésre szánt szolgáltatások esetén a szervezetek API-kulcsokkal biztosíthatnak hozzáférést a megvásárolt hozzáférési terv alapján.
API Client Restrictions
a biztonsági kockázatok minimalizálása érdekében a rest szolgáltatóknak korlátozniuk kell az ügyfelek csatlakoztatását a szolgáltatáshoz szükséges minimális képességekre. Ez a támogatott HTTP-módszerek korlátozásával kezdődik annak biztosítása érdekében, hogy a rosszul konfigurált vagy rosszindulatú ügyfelek ne hajthassanak végre semmilyen műveletet az API specifikáción és az engedélyezett hozzáférési szinten túl. Például, ha az API csak a GET kéréseket engedélyezi, akkor a POST és más kéréstípusokat el kell utasítani a 405-ös válaszkód metódus nem engedélyezett.
API-kat felfedő alkalmazások védelme
miután az ügyfél jogszerű hozzáféréssel rendelkezik, meg kell védenie az alapul szolgáló webalkalmazást a hibás vagy rosszindulatú bemenetektől. A REST API-hívások és-válaszok bizalmas adatokat is tartalmazhatnak, amelyeket ellenőrizni kell.
érzékeny adatok az API kommunikációban
az API-hívások gyakran tartalmaznak hitelesítő adatokat, API-kulcsokat, munkamenet-tokeneket és más érzékeny információkat. Ha közvetlenül az URL-ekben szerepelnek, ezek az adatok tárolhatók a webkiszolgáló naplóiban, és kiszivároghatnak, ha a naplókhoz számítógépes bűnözők férnek hozzá. A bizalmas információk kiszivárgásának elkerülése érdekében a RESTful webszolgáltatásoknak mindig a HTTP kérés fejlécében vagy a kérés törzsében kell elküldeniük (POST and PUT kérésekhez).
tartalomtípus-érvényesítés
folytatva az API-ügyfélkorlátozások témáját, a REST-szolgáltatásoknak pontosan meg kell határozniuk az engedélyezett tartalomtípusokat, és el kell utasítaniuk azokat a kéréseket, amelyek HTTP-fejlécében nem szerepelnek a megfelelő deklarációk. Ez azt jelenti, hogy gondosan meg kell adni az engedélyezett típusokat mind a Content-Type
, mind a Accept
fejlécben, a karakterkészlettel együtt (ahol lehetséges). Ha a szolgáltatás JavaScript-et (vagy más szkriptkódot) tartalmaz, akkor biztosítania kell, hogy a fejlécben a tartalom típusa megegyezzen a kérés törzsével, például application/javascript
. Ez segít megelőzni a fejléc-befecskendezési támadásokat.
Válaszbiztonsági fejlécek
további HTTP biztonsági fejlécek állíthatók be a kérések típusának és hatókörének további korlátozására. Ezek közé tartozik a X-Content-Type-Options: nosniff
a MIME-szippantáson alapuló XSS támadások megelőzése, valamint a X-Frame-Options: deny
a régebbi böngészők kattintási kísérleteinek megakadályozása.
ha a szolgáltatás nem támogatja a tartományok közötti hívásokat, le kell tiltania a CORS-t (cross-origin resource sharing) a válaszfejlécekben. Ha ilyen hívások várhatók, a CORS fejlécének pontosan meg kell határoznia az engedélyezett eredetet.
Input Validation
az API-kat felhasználói beavatkozás nélküli automatikus hozzáférésre tervezték, ezért különösen fontos, hogy minden bemenet érvényes és elvárható legyen. Az API specifikációnak nem megfelelő kéréseket el kell utasítani. A beviteli validációra vonatkozó tipikus bevált gyakorlatokra vonatkozó iránymutatások alkalmazandók:
- kezelje az összes paramétert, objektumot és egyéb bemeneti adatot megbízhatatlannak.
- használja a beépített érvényesítési funkciót, ahol elérhető.
- ellenőrizze a kérés méretét, a tartalom hosszát és típusát.
- használjon erős gépelést az API paraméterekhez (ha támogatott).
- az SQL – befecskendezés megakadályozása érdekében kerülje a lekérdezések kézi felépítését-inkább paraméterezett lekérdezéseket használjon.
- Whitelist paraméterértékek és karakterlánc bemenetek, ahol csak lehetséges.
- jelentkezzen be minden bemeneti érvényesítési hibára a hitelesítő adatok kitöltési kísérleteinek észleléséhez.
miért fontos a REST API biztonsága?
a webes API-k a modern webes és mobil fejlesztés gerincét képezik. Lehetővé teszik az alkalmazások és szolgáltatások számára, hogy hardver-és szoftverplatformokon keresztül kommunikáljanak és adatokat cseréljenek. Míg más API formátumok is még mindig használatban vannak (például SOAP), a REST API-k ma már a domináns típusok, amelyek az összes nyilvános webes API több mint 80% – át teszik ki. A mobil alkalmazások és az IoT eszközök többségének hátterét biztosítják, és lehetővé teszik a rendszerek és alkalmazások közötti egyszerű integrációt.
mivel ugyanazokat a technológiákat használják, mint a webes alkalmazások, a REST API-k sebezhetőek lehetnek ugyanazokkal a támadásokkal szemben. Ugyanakkor az API-kat nem kézi hozzáférésre tervezték, így nehéz lehet tesztelni őket, különösen, ha egyes végpontok és funkciók nincsenek dokumentálva. Az API biztonsági tesztelése pontos automatizált eszközöket igényel a teljes lefedettség biztosítása érdekében. A Netsparker teljes mértékben támogatja a REST API sebezhetőségi vizsgálatát a különböző hitelesítési módszerekkel és az automatikus URL-átírással.
tekintse meg a Netsparker REST API tesztoldalának dokumentációját a teljes technikai részletekért, és olvassa el a REST API-knak a Netsparker biztonsági réseinek kereséséről szóló teljes cikkünket.
A szerzőről
MŰSZAKI Tartalomíró a Netsparker-nél. Informatikai újságíróként és műszaki fordítóként szerzett tapasztalataira támaszkodva mindent megtesz annak érdekében, hogy a Netsparker blogján és webhelyén szélesebb közönséghez juttassa el a webes biztonságot.