API-biztonság: a leggyakoribb hibák

Az API-k biztonsága azért külön téma, mert hiányzik az a védőréteg, amit a felhasználói felület jelent. Egy webalkalmazásnál a felület korlátozza, mit lehet kérni; egy API-nál a kliens bármit küldhet, bármilyen sorrendben.

1. Objektumszintű jogosultság hiánya

A leggyakoribb és legsúlyosabb hiba. Az API ellenőrzi a tokent, de nem ellenőrzi, hogy az adott felhasználó jogosult-e a kért objektumra.

GET /api/orders/8842 visszaadja a rendelést, akkor is, ha az valaki másé. Ez automatizált eszközzel nem található meg, mert a kérés technikailag helyes.

Amit tenni kell: minden objektum-hozzáférésnél szerveroldali jogosultság-ellenőrzés. Ne a kliens által küldött azonosítóban bízzon, hanem a tokenből származó identitásban.

2. Túl sok adat visszaadása

Az API a teljes objektumot visszaadja, a kliens pedig csak egy részét jeleníti meg. A többi ott van a válaszban, és bárki megnézheti.

Tipikus eset: a felhasználói profil végpontja visszaadja a jelszó-hasht, a belső azonosítókat vagy más felhasználók adatait.

Amit tenni kell: a válasz explicit összeállítása, mezőnként. Ne a teljes adatbázis-objektumot sorosítsa.

3. Hiányzó sebesség-korlátozás

Ha nincs korlátozás, egy végpont brute force támadásra, adatgyűjtésre vagy szolgáltatásmegtagadásra használható. A bejelentkezési és a jelszó-visszaállítási végpont a legérzékenyebb.

Amit tenni kell: korlátozás felhasználónként és IP-címenként, eltérő küszöbbel a különböző végpontokon.

4. Tömeges hozzárendelés

Az API elfogadja a kliens által küldött összes mezőt, és beírja az objektumba. A támadó hozzáad egy "role": "admin" mezőt, és megkapja.

Amit tenni kell: engedélyezőlista a módosítható mezőkre. Ami nincs kifejezetten engedélyezve, azt figyelmen kívül kell hagyni.

5. Régi verziók életben tartása

Az /api/v1 mellé jött a v2, de a v1 továbbra is fut, mert néhány kliens még használja. A régi verzióban ott vannak a régi hibák.

Amit tenni kell: verzió-leltár, kivezetési terv, és a nem használt verziók lekapcsolása. A hozzáférési naplóból kiderül, tényleg használja-e még valaki.

Hitelesítés és token

Rövid élettartam. A hozzáférési token élettartama legyen rövid, és frissítő tokennel megújítható. A soha le nem járó token elveszettként is működik.

Hatókör-korlátozás. A token csak arra jogosítson, amire a kliensnek szüksége van, ne mindenre.

Ne az URL-ben. A tokent fejlécben kell küldeni, mert az URL a naplókban és a hivatkozókban is megjelenik.

Visszavonhatóság. Kell egy mód a token azonnali érvénytelenítésére kompromittálódás esetén.

Mit teszteljen

• Objektumszintű jogosultság: más felhasználó azonosítójával próbálkozás
• Funkciószintű jogosultság: alacsony jogú token adminisztratív végponton
• A válaszban visszaadott felesleges mezők
• Korlátozás megléte a hitelesítési végpontokon
• Régi verziók elérhetősége

Az IT biztonsági szolgáltatásaink és a penetrációs tesztelés is kiterjed az API-rétegre.