Röviden: A PHP API-biztonságában főleg öt pont számít: csak HTTPS, hitelesítés minden nem nyilvános végponton, jogosultság-ellenőrzés minden egyes objektumra, szigorú határok a metódusra, a tartalomtípusra és a kérés méretére, valamint rövid hibaüzenetek belső részletek nélkül. Ehhez jön a sebességkorlátozás és a biztonság szempontjából releváns események naplója. A PHP-értelmező magában lévő réseivel szemben, mint a PHP2Shell, ez nem segít; ahhoz a PHP-frissítés kell.
Az interfész a weboldal mögött
Sok vállalat a 2026. október 21. utáni héten ellenőrizte a weboldalait. A mögöttük lévő interfészek ritkábban kerültek a listára. Pedig éppen ott futnak érzékeny folyamatok: az ügyfélportál alkalmazása számlákat tölt le, a vállalatirányítási rendszer készleteket ír a webshopba, egy partner webhookkal jelent megrendeléseket. Ezeket az API-kat gyakran gyorsan építették, egyetlen célra, és utána soha többé nem nézték meg.
Az API-nak nincs felülete, amely láthatóvá tenné a hibákat. Egy hiányzó jogosultság-ellenőrzés a mindennapokban senkinek sem tűnik fel, amíg minden kliens csak azt kérdezi le, amit kell. A támadó ezzel szemben éppen azt próbálja ki, ami nincs előirányozva.
Az első lépés ezért a leltár. Egyáltalán milyen végpontok léteznek? Gyakran találni régi verziókat, mint a /api/v1/, amelyeket a /v2/-re való áttérés után soha nem kapcsoltak ki, a fejlesztésből származó tesztvégpontokat, vagy nyilvánosan lekérhető interfészleírást, amely belső funkciókat sorol fel. Minden végpontot, amelyre már nincs szükség, ki kell kapcsolni. Mindegyiknek, amely marad, felelősre van szüksége.
API-biztonság PHP-ban: az alapszabályok
Az OWASP REST Security Cheat Sheet összefoglalja a bevált szabályokat. A PHP-projektekre ezek egy rövid listára fordíthatók:
- Csak HTTPS. A tokeneket és hozzáférési adatokat soha nem szabad titkosítatlanul átvinni.
- Minden végpont maga ellenőriz. A hitelesítés történhet központilag, a hozzáférésről a végponton döntenek.
- Jogosultság objektumonként. Nem csak „be van jelentkezve”, hanem „pontosan ezt az adatrekordot láthatja”.
- Az engedélyezett metódusok rögzítése. Ami nincs kifejezetten engedélyezve, azt 405-tel elutasítják.
- A tartalomtípus és a méret ellenőrzése. Hibás típus 415-öt ad, túl nagy kérés 413-at.
- A bemenetek validálása. Típus, hossz, formátum és értéktartomány, a szerver oldalán.
- Nincsenek titkok az URL-ekben. A tokenek és kulcsok a fejlécbe valók, nem a lekérdezési stringbe.
- Rövid hibák. Nincs stacktrace, útvonal vagy SQL-üzenet a kliensnek.
- Sebességkorlátozás. A túl sok kérésre 429-cel válaszolnak.
- Az adminisztrációs végpontok elzárása. Nyilvánosan nem elérhetők, vagy csak erős bejelentkezéssel.
Objektumjogosultság: a leggyakoribb hiba
Egy példa kézzelfoghatóvá teszi a problémát. Egy végpont számlákat szolgáltat a /api/rechnungen/{id} alatt. Azt ellenőrzik, hogy érvényes token van-e. Azt nem ellenőrzik, hogy a számla a token ügyfeléhez tartozik-e. Aki a saját számlaszámát eggyel megnöveli, a szomszédét látja.
A megoldás egyszerű, és mégis minden helyen meg kell valósítani: maga a lekérdezés korlátoz a jogosult területre.
<?php
// Csak a GET metódust engedélyezni
if ($_SERVER['REQUEST_METHOD'] !== 'GET') {
http_response_code(405);
header('Allow: GET');
exit;
}
$kundeId = $auth->kundeId(); // az ellenőrzött tokenből
$id = filter_var($routeId, FILTER_VALIDATE_INT);
if ($id === false) {
http_response_code(400);
exit;
}
// A jogosultság a lekérdezésben van: csak a saját számlák
$stmt = $pdo->prepare('SELECT nummer, betrag, datum FROM rechnungen WHERE id = ? AND kunde_id = ?');
$stmt->execute([$id, $kundeId]);
$rechnung = $stmt->fetch(PDO::FETCH_ASSOC);
if (!$rechnung) {
http_response_code(404); // nem elárulni, hogy létezik-e az azonosító
exit;
}
header('Content-Type: application/json');
echo json_encode($rechnung, JSON_THROW_ON_ERROR);
A helyőrzőkkel végzett lekérdezés egyúttal véd az SQL-injection ellen is, lásd SQL-injection megelőzése PHP-ban. Hogy a PHP hogyan teszi elérhetővé a kérésadatokat, például a metódust, a fejléceket és a törzset, azt a Szuperglobálisok: $_GET, $_POST, $_FILES és társaik magyarázza el.
A tokenek helyes ellenőrzése
Sok API JSON Web Tokenekkel dolgozik. Az OWASP Cheat Sheet erre egyértelmű szabályokat nevez meg: a tokeneknek aláírtnak kell lenniük, az aláíratlan tokeneket elutasítják, és az ellenőrzés algoritmusát a szerveren határozzák meg, nem a tokenből veszik át. A kiállító, a célközönség és a lejárati idő szintén az ellenőrzéshez tartozik. Ehhez gondozott könyvtárat használjon saját megvalósítások helyett.
A saját tokeneknek, például a webhookokhoz vagy az egyszeri linkekhez, kriptográfiailag biztonságos véletlenszám-generátorból kell származniuk, és állandó időben kell összehasonlítani őket. Hogy ez PHP-ban hogyan megy, azt a Biztonságos véletlenszámok és tokenek PHP-ban mutatja.
Minden kliensnek és minden partnernek adjon saját kulcsot pontosan azokkal a jogokkal, amelyekre szüksége van. Így egy kiszivárgott kulcs egyedileg letiltható anélkül, hogy az összes többi csatlakozást megszakítaná.
Határok megszabása: méret, típus és tempó
Egy API csak azt fogadja el, amit vár. Ez a tartalomtípussal kezdődik: egy JSON-t feldolgozó végpont minden mást elutasít. A kérés maximális méretét több szinten korlátozza, a webszerverben és a PHP-ban a post_max_size segítségével. Ez a határ a php.net által a PHP2Shellről megnevezett átmeneti intézkedések közé is tartozik. Hogyan választhatja meg értelmesen, azt a A post_max_size és az upload_max_filesize értelmes korlátozása írja le.
A sebességkorlátozás védi az azonosítók végigpróbálgatása és a túlterhelés ellen. Megvalósítható a webszerverben, egy előtét-proxyban vagy az alkalmazásban. Fontos, hogy a határok kulcsonként vagy felhasználónként érvényesek legyenek, és ne csak IP-címenként.
A közvetlenül a böngészőből hívott API-knál a CORS is hozzájön, vagyis az a szabályrendszer, hogy mely idegen weboldalak intézhetnek kéréseket. Csak akkor állítsa be ezeket a fejléceket, ha ilyen hívások valóban elő vannak irányozva, és az engedélyezett eredeteket egyenként nevezze meg ahelyett, hogy minden eredetet megengedne. Egy olyan helyettesítő karakter, amely minden weboldalt engedélyez, a bejelentkezéssel rendelkező végpontoknál szinte mindig hiba.
Végül a napló: a sikertelen bejelentkezések, az elutasított tokenek és a megtagadott hozzáférések a logba tartoznak, maguk a tokenek nem. Ezek a bejegyzések nélkül egy API elleni támadás láthatatlan marad.
Hogyan segít konkrétan a PHP SOS?
- Felmérjük a PHP-rendszerei összes interfészét, az elfelejtetteket és a belsőket is, és ellenőrizzük, melyek érhetők el nyilvánosan.
- Elolvassuk a jogosultsági logikát, és célzottan teszteljük, hogy idegen adatrekordok lekérhetők-e.
- A méret, a típus és a tempó határait a webszerverben és a PHP-ban állítjuk be, és egyeztetjük a klienseivel.
- A kívülről végzett átfogó ellenőrzéshez ezt a biztonsági audittal és penetrációs teszttel kombináljuk.
Összegzés: Egy API annyira biztonságos, mint a legelhanyagoltabb végpontja. Aki objektumonként ellenőrzi a jogosultságokat, egyértelmű határokat szab, és rövidre fogja a hibákat, lezárja a leggyakoribb réseket, jóval azelőtt, hogy valaki célzottan keresné őket.
Gyakori kérdések
Elég az API-kulcs védelemként?
Érzékeny adatokhoz nem. Az API-kulcs többnyire egy alkalmazást azonosít, nem egy felhasználót, és könnyen továbbadják. Az OWASP REST Security Cheat Sheet azt tanácsolja, hogy az API-kulcsot ne használják az érzékeny erőforrások egyedüli védelmeként.
Mi az objektumjogosultság, és miért hiányzik olyan gyakran?
Azt az ellenőrzést jelenti, hogy a bejelentkezett felhasználó pontosan ezt az adatrekordot láthatja vagy módosíthatja-e. Gyakran azért hiányzik, mert a fejlesztők csak azt ellenőrzik, hogy egyáltalán be van-e jelentkezve valaki. Ekkor elég egy azonosítót megváltoztatni az URL-ben ahhoz, hogy idegen adatokat hívjanak le.
Véd a PHP2Shell ellen egy jól védett API?
Nem. A PHP2Shell a PHP-értelmezőben van, és az érintett üzemmódokban azelőtt hat, hogy az Ön kódja egyáltalán futna. Ez ellen csak a PHP-frissítés segít újraindítással. A kérések méretkorlátai ettől még értelmesek, és a php.net átmeneti intézkedései közé is tartoznak.
Milyen állapotkódokat adjon egy API biztonsági hibáknál?
Szokásos a 401 érvényes bejelentkezés nélkül, a 403 hiányzó jogosultságnál, a 405 nem engedélyezett metódusnál, a 413 túl nagy kérésnél, a 415 hibás tartalomtípusnál és a 429 túl sok kérésnél. A válasz maga közben rövid marad, belső részletek nélkül.