Beszéljünk az API biztonságról

#api #rest #http #auth

Beszéljünk az API biztonságról

Legyen bármilyen háttér rendszerünk, a biztonság egy olyan kérdés, amit nem érdemes kikerülni. Ebben a bejegyzésben áttekintünk pár lehetőséget, amikkel biztonságosabbá tehetjük API-jainkat.

Frontendet kiszolgáló backend interfészek

Ha Angular vagy React zakatol a frontenden, akkor is érdemes a backend hívások biztonságára gondolni, hogy ne legyenek publikusak azok interfészek amiket nem szeretnénk.

Authentikációhoz kötött interfészek

Egy adminisztrációs felületnél a legjobb módszer, ha authentikációhoz kötjük az interfészek hozzáférését. Ilyenkor indíthatunk egy session-t a szerver oldalon, és követhetjük vele a kliens aktivitását.

Így vázlatosan a következő folyamat valósul meg:

  1. Auth elküldése a login interfészre
  2. Sikeres auth esetén a válaszban egy tokent kapunk vissza
  3. Ezt a token-t pedig továbbküldjük az összes többi lekérdezéssel

Auth nélküli frontend rendszerek

Ilyen rendszereknél érdemes legalább egy kevés CSRF védelemmel ellátni az oldalt, ami gyakorlatilag egy anonim token kiosztás. A lényeg az, hogy tudjuk azonosítani a klienst, és ha gyanús lenne a viselkedése, akkor le tudjuk tiltani a hozzáférését.

Backendek közötti kommunikáció

Gyakori eset, hogy különböző rendszerek kommunikálnak egymással és használják egymás interfészeit. Ilyenkor ha nem publikus API-ról van szó, akkor valami úton-módon a hoszt rendszernek be kell tudnia azonosítania a kliens rendszert, hogy biztosítani tudja a hozzáféréshez engedélyezett szolgáltatásokat.

Az alább felsorolt módszerek egymagukban és egymással kombinálva is előfordulhatnak.

IP Whitelist

Viszonylag egyszerű módszer, amely segítségével az API-t csak egy bizonyos IP címről vagy tartományból lehet elérni. Ilyenkor ha más IP-címről érkezik kérés az API irányába, akkor az azonnal el lesz utasítva.

Ezt érdemes már közvetlen a webszerver oldalán kezelni. (Apache, Nginx1, Express2)

HTTP Basic Auth

A legegyszerűbb módja annak, hogy egy felhasználónév és jelszó kombinációval levédjünk egy interfészt. Szerver oldalon a WWW-Authenticate: Basic realm="Titkos API" header-el kényszeríthetjük ki az authentikációt és annak hiányában 401 Unauthorized üzenetet adhatunk vissza.

Az authentikációt pedig kliens oldalról a Authorization: Basic XXX headerrel tudjuk indtani, ahol az XXX az a felhasználónév és jelszó kettősponttal elválasztva és Base64-el encodeolva.

De egyszerűen hívható a legtöbb böngésző címsorából is a következő módon: https://felhasználónév:jelszó@apioldalam.hu/api

Általában ilyen védelem esetén minden kéréshez meg kell adni a felhasználónevet és a jelszót.

A következő linken példát találhattok ennek PHP alatt történő használatára: PHP.net - HTTP authentication with PHP

Token Kulcs

Viszonylag elegánsabb módszer, ami egy központilag kiosztott tokenre épít. Legjobb példa erre az OAuth2 specifikációja, ahol egy központi jogosultságkezelő kezeli a kioszott tokeneket és azok lejáratát.

A folyamat lényege, hogy a kliens oldalon használt tokenek szerver oldalon visszafejtve komplex jogosultság szerkezetet takarhatnak. Az azonosítás pedig nem az API kulcsokkal közvetlen történik, hanem a kiosztott token hordoz minden olyan információt, amire szerver oldalon szükség lehet a kliens azonosításához.

A tokenek megszerzése egyszerű authentikációval kezdődik, ahol meg kell adni egy redirect URL-t. (Egyes esetekben már az account létrehozásakor meg kell adni egy fix Redirect URL-t.) Sikeres authentikáció után a kiosztott token a megadott URL-re kerül kiosztásra, ami általában egy redirect a megadott URL-re ahol is a GET-ben megtalálhatjuk a tokenünk.

Az összes további request a hoszt szerver felé ezzel a tokennel kerül továbbításra.

Header Auth

Itt gyakorlatilag beindulhat a képzeletünk, ugyanis a szerver bármilyen headert megkövetelhet ahhoz, hogy engedélyezze a rendszerhez való hozzáférést.

A kedvenc megoldásom amivel mostanában találkoztam, az arra épít, hogy a kiosztott API kulcsot és egy, a kliens szerver oldalon generált aláírást kell továbbítani a headerben a hoszt szerver felé. Az aláírás generálása pedig a hozzáférés által kiosztott api kulcs, titkos kulcs és timestamp hármas hash-elt eredménye.

Összefoglaló

Természetesen sok más lehetőségünk is van. Minél kreatívabban használjuk ezeket, annál nehezebb dolga lesz annak aki jogosulatlanul akar hozzáférni rendszereinkhez.

További fontos apróságok:

  1. Sose felejtsük el a HTTPS-t, hiszen ennek engedélyezésével máris nehezebbé tettük a kommunikáció visszafejtését.
  2. Figyeljük a kérés/perc számlálót vagy iktassunk be request limitet az egyes accountokhoz. Ne engedjük, hogy valaki véletlen le-DOS-olja a live szerverünk.
  3. Cache-eljük a válaszokat ahol lehet. Senki sem szereti a lassú rendszereket.

További tartalmak