Bevált gyakorlatok a biztonságos API-k létrehozásához

írta: Rakesh Talanki és Vidheer Gadikota

Az API (alkalmazásprogramozási felület) tervezői és fejlesztői általában megértik a tervezési alapelvek betartásának fontosságát az interfész megvalósítása során. Senki sem akarja megtervezni vagy megvalósítani egy rossz API-t!

Ennek ellenére néha kísértés keres gyorsbillentyűket az agresszív sprint-ütemtervek eléréséhez, a célba jutáshoz és az API telepítéséhez. Ezek a parancsikonok súlyos, nem biztonságos API-kat jelentenek.

A fejlesztőknek ne felejtsék el viselni az API-hackerek kalapját a telepítés előtt. Ha egy fejlesztő elmulasztja azonosítani az API biztonsági réseit, akkor az API nyílt átjáróvá válhat a rosszindulatú tevékenységekhez.

Az API sérülékenységeinek azonosítása és megoldása

Az API működhet a szolgáltató mellett vagy annak ellenére, attól függően, hogy a szolgáltató megértette és végrehajtotta API felhasználói igényeit. Ha egy vállalat hihetetlenül biztonságos API-t épít fel, akkor nagyon nehéz lesz a használata. Finom egyensúlyt kell találni az API célja és a könnyű fogyasztás között. Ebben a cikkben a Google Apigee-csapat részeként végzett munkánk során felfedezzük azokat az API-sérülékenységeket, amelyekkel szembesülünk, ideértve azt is, hogy ezeket a biztonsági réseket hogyan lehet megelőzni.

Az injekciók

Az API-k a vállalkozások számára a digitális világkapcsolathoz való átjárók. Sajnos vannak olyan rosszindulatú felhasználók, akik arra törekszenek, hogy hozzáférést kapjanak a vállalkozások háttérrendszereihez azáltal, hogy nem szándékolt parancsokat vagy kifejezéseket adnak be az API-khoz elérhető, törléshez, frissítéshez, vagy akár tetszőleges adatok létrehozásához.

Például 2014 októberében a Drupal bejelentette az SQL befecskendezésének biztonsági rését, amely hozzáférést biztosít a támadókhoz adatbázisokhoz, kódokhoz és fájlkönyvtárakhoz. A támadás annyira súlyos volt, hogy a támadók esetleg minden adatot lemásoltak az ügyfelek webhelyeiről. Az injektálási fenyegetések számos típusa létezik, de a leggyakoribb az SQL Injection, a RegEx Injection és az XML Injection. Többször is láttuk, hogy az API-k fenyegetésvédelem nélkül indulnak, ez nem ritka.

API-k hitelesítés nélkül

A hitelesítésen keresztül a rosszindulatú fenyegetések elleni védelem nélkül felépített API olyan API-tervezési hibát jelent, amely veszélyeztetheti a szervezet adatbázisát. A megfelelő hitelesítés figyelmen kívül hagyása - még akkor is, ha a szállítási réteg titkosítását (TLS) használják - problémákat okozhat. Egy érvényes mobilszámmal az API-kérelemben például bárki megszerezheti személyes e-mail címeit és eszközazonosító adatait. Ezért kritikus az iparági szabványokon alapuló erős hitelesítési és engedélyezési mechanizmusok, például az OAuth / OpenID Connect, a TLS-sel együtt.

Érzékeny adatok szabadban

Általában a műveleti csoportok és más belső csapatok hozzáférhetnek nyomkövetési eszközökhöz a hibakereséshez, amelyek tiszta képet nyújthatnak az API hasznos teherinformációiról. Ideális esetben a PCI-kártyatulajdonos adatait (CHD) és a személyes egészségügyi adatokat (PHI) akkor titkosítják, amikor az adatokat az adatok felhasználásáig elfogják, bár ez nem mindig van így.

Az API biztonságával kapcsolatos növekvő aggodalmak mellett az érzékeny és bizalmas adatok titkosításának prioritást kell élveznie. Például 2016 júniusában egy http proxy sebezhetőséget tettek közzé, amely többféle lehetőséget adott a támadóknak a kimenő kérés kiválasztására egy kiválasztott szerverre, a kérelemből származó érzékeny információk rögzítésére és a belső adatokkal kapcsolatos információk megszerzésére. A TLS használatán túl fontos az API forgalom védelme az érzékeny adatok titkosításával, az adatok maszkolásával a nyomkövetéshez / naplózáshoz, valamint a tokenizálás használatával a kártya adataihoz.

Replay támadások

A vállalati építészek számára komoly aggodalomra ad okot az úgynevezett tranzakció-visszajátszás. Sok esetben, még ha megbízhatatlan kérelmet is benyújtanak és elutasítanak, az API udvariasan engedélyezheti a - potenciálisan rosszindulatú - felhasználó számára, hogy megpróbálja újra.

A támadók kihasználják ezt az elmulasztott bizalmat azzal, hogy megpróbálják lejátszani vagy visszajátszani a jogos felhasználói kérelmet (bizonyos esetekben brute force technikákkal), amíg sikeresek nem lesznek. 2016-ban a hackerek lejátszási támadással jutottak be a Github-fiókokba azáltal, hogy újrafelhasználták az e-mail címeket és jelszavakat más veszélyeztetett online szolgáltatásoktól, és megpróbálták őket a Github-fiókokon.

Az ellenintézkedések közé tartozik a fojtószelep-kérelmek sebességkorlátozó politikája, olyan kifinomult eszközök használata, mint például az Apigee Sense, az API-kérelmek forgalmának elemzésére, és a nem kívánt bot-kérelmeket reprezentáló minták azonosítása. A stymie visszajátszási támadások kiegészítő biztonsági intézkedései a következők:

  • HMAC, amely időbélyeggel rendelkezik, hogy a tranzakció érvényességét egy meghatározott időtartamra korlátozza
  • két tényezős hitelesítés
  • rövid távú hozzáférési token engedélyezése az OAuth használatával

Váratlan növekedés az API használatában

Mindig bonyolult az API használatának becslése. Jó példa erre az alkalmazás, amely röviden bemutatta a National Weather Service API-t. Ennek az adott API-nak nem volt semmiféle forgalmi túlfeszültség-megakadályozó vagy fojtószelep-mechanizmusa, ezért a forgalom váratlan növekedése közvetlenül érintette a hátteret.

A bevált gyakorlat az, hogy letartóztassák a tüskeforgalmat vagy az alkalmazásonkénti felhasználási kvótát, hogy ez ne érintse a háttérképet. Ez könnyen megvalósítható egy kifinomult API-kezelő platformon keresztül, olyan politikákkal, mint a kvóta és a tüske letartóztatása.

Kulcsok az URI-ban

Bizonyos esetekben az API kulcsok hitelesítésre és engedélyezésre történő megvalósítása elég jó. A kulcs elküldése az egységes erőforrás-azonosító (URI) részeként azonban a kulcsot veszélyeztetheti. Mint az IETF RFC 6819-ben kifejtettük, mivel az URI-adatok megjelenhetnek a böngészőben vagy a rendszernaplóban, lehetséges, hogy egy másik felhasználó megnézheti az URI-t a böngésző előzményeiből, ami az API-kulcsokat, jelszavakat és az érzékeny dátumot az API URI-kban könnyen elérhetővé teszi.

Biztonságosabb az API kulcsok küldése az üzenet engedélyezési fejlécében, amelyet a hálózati elemek nem naplóznak. Ökölszabályként javasolt a HTTP POST módszer használata hasznos teherrel, amely érzékeny információkat tartalmaz.

Verem nyom

Számos API-fejlesztő kényelmessé teszi a 200 felhasználást az összes sikerkérelemhez, a 404-et az összes hibához, az 500-at bizonyos belső szerverhibákhoz, és néhány szélsőséges esetben a 200-at egy hibaüzenettel a testben, a részletes verem nyomkövetés mellett. A verem nyomkövetése információszivárgássá válhat egy rosszindulatú felhasználó számára, ha a tervezési vagy építészeti megvalósításokat csomagnevek, osztálynevek, keretnevek, verziók, kiszolgálónevek és SQL lekérdezések formájában tárja fel.

A támadók kihasználhatják ezt az információt formázott URL-kérelmek benyújtásával, ahogyan ezt a Cisco-példa magyarázza. Jó gyakorlat egy „kiegyensúlyozott” hibaobjektum visszaadása a megfelelő HTTP állapotkóddal, minimálisan előírt hibaüzenettel (üzenetekkel) és „nincs veremnyomozással” hibaüzenetek során. Ez javítja a hibakezelést, és megvédi az API megvalósításának részleteit a támadóktól. Az API átjáró segítségével a háttér-hibaüzeneteket szabványos üzenetekké alakíthatjuk úgy, hogy az összes hibaüzenet hasonló legyen; ez kiküszöböli a háttér-kód szerkezetének feltárását is.

Tartsa biztonságban az API-kat

Amint azt a cikkben áttekintettük, számos potenciális veszélyt el lehet kerülni, ha átgondoljuk az API-tervezést és létrehozunk olyan irányítási politikákat, amelyek alkalmazhatók a vállalkozás egészén. Fontos, hogy az API-kat megvédjük a rosszindulatú üzenetek tartalmától: érzékeny titkosított adatokhoz kell hozzáférni és el kell maszkolni a futást, és meg kell védeni a háttér-szolgáltatásokat a közvetlen hozzáféréstől. Az API biztonsági hibájának jelentős következményei lehetnek - de a megfelelő előrejelzés és menedzsment segítségével a vállalkozások sokkal biztonságosabbá tehetik magukat.

[Szeretne többet megtudni az API biztonságáról? Töltse le a legújabb e-könyvének másolatát, az API termékmeghatározáson belül: biztonságos API-k létrehozása és kezelése.]