REST-API-de kaitsmine PHP-s

Lühidalt: API turvalisuse jaoks PHP-s loevad eelkõige viis punkti: ainult HTTPS, autentimine igal mitteavalikul lõpp-punktil, õiguse kontroll iga üksiku objekti jaoks, rangelt piiratud meetod, sisutüüp ja päringu suurus ning napid veateated ilma sisemiste üksikasjadeta. Lisaks päringute piiramine ja turvaküsimustega seotud sündmuste protokoll. PHP interpretaatori enda aukude, nagu PHP2Shell, vastu see ei aita; selleks on vaja PHP uuendust.

Liides veebisaidi taga

Paljud ettevõtted kontrollisid nädalal pärast 21. oktoobrit 2026 oma veebisaite. Nende taga olevad liidesed olid nimekirjas harvemini. Samas toimuvad just seal tundlikud protsessid: kliendiportaali rakendus toob arveid, kaubahaldussüsteem kirjutab laoseisud poodi, partner teatab tellimustest veebikonksuga. Sageli ehitati need API-d kiiresti, ühe ainsa eesmärgi jaoks, ja pärast ei vaadatud neid enam kunagi.

API-l ei ole liidest, mis vigu nähtavaks teeks. Puuduv õiguse kontroll ei jää igapäevaselt kellelegi silma, kuni kõik kliendid päriavad ainult seda, mida nad peavad. Ründaja proovib seevastu just seda, mida ette nähtud ei ole.

Esimene samm on seetõttu inventuur. Millised lõpp-punktid üldse olemas on? Sageli leidub vanu versioone, nagu /api/v1/, mida pärast üleminekut /v2/-le kunagi välja ei lülitatud, arenduse testlõpp-punkte või avalikult kättesaadav liidesekirjeldus, mis loetleb sisemisi funktsioone. Iga lõpp-punkt, mida enam ei vajata, tuleks välja lülitada. Igal, mis jääb, peab olema vastutaja.

API turvalisus PHP-s: põhireeglid

OWASP REST Security Cheat Sheet võtab kokku end tõestanud reeglid. PHP-projektide jaoks saab need tõlkida lühikeseks nimekirjaks:

1. Ainult HTTPS. Tokeneid ja ligipääsuandmeid ei tohi kunagi krüpteerimata edastada.
2. Iga lõpp-punkt kontrollib ise. Autentimine võib toimuda tsentraalselt, otsus juurdepääsu üle langetatakse lõpp-punktis.
3. Õigus objekti kaupa. Mitte ainult „on sisse logitud“, vaid „tohib just seda kirjet“.
4. Määrake lubatud meetodid. Mis ei ole selgesõnaliselt lubatud, lükatakse tagasi vastusega 405.
5. Kontrollige sisutüüpi ja suurust. Vale tüüp annab 415, liiga suured päringud 413.
6. Valideerige sisendid. Tüüp, pikkus, vorming ja väärtuste vahemik, serveris.
7. Ei mingeid saladusi URL-idesse. Tokenid ja võtmed kuuluvad päisesse, mitte päringustringi.
8. Napid vead. Ei mingeid stacktrace'e, teid ega SQL-teateid kliendile.
9. Päringute piiramine. Liiga paljudele päringutele vastatakse 429-ga.
10. Varjake haldusliidesed. Mitte avalikult kättesaadavad või ainult tugeva sisselogimisega.

Objektiõigus: sagedaseim viga

Näide teeb probleemi käegakatsutavaks. Lõpp-punkt annab arveid aadressil /api/rechnungen/{id}. Kontrollitakse, kas kehtiv token on olemas. Ei kontrollita, kas arve kuulub tokeni kliendile. Kes tõstab oma arvenumbrit ühe võrra, näeb naabri oma.

Lahendus on lihtne ja tuleb sellest hoolimata igas kohas ellu viia: päring ise piirab õigustatud alale.

<?php
// Lubada ainult meetod GET
if ($_SERVER['REQUEST_METHOD'] !== 'GET') {
    http_response_code(405);
    header('Allow: GET');
    exit;
}

$kundeId = $auth->kundeId();          // kontrollitud tokenist
$id = filter_var($routeId, FILTER_VALIDATE_INT);
if ($id === false) {
    http_response_code(400);
    exit;
}

// Õigus on päringus endas: ainult oma arved
$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);           // mitte reeta, kas ID on olemas
    exit;
}

header('Content-Type: application/json');
echo json_encode($rechnung, JSON_THROW_ON_ERROR);

Kohatäitjatega päring kaitseb samal ajal SQL-injection'i eest, vt SQL-injection'i vältimine PHP-s. Kuidas PHP päringuandmeid, nagu meetod, päised ja keha, kättesaadavaks teeb, selgitab Superglobals: $_GET, $_POST, $_FILES ja kaasosalised.

Tokenite õige kontrollimine

Paljud API-d töötavad JSON Web Tokenitega. OWASP Cheat Sheet nimetab selleks selged reeglid: tokenid peavad olema allkirjastatud, allkirjastamata tokenid lükatakse tagasi ja kontrolli algoritm määratakse serveris, mitte ei võeta tokenist. Väljaandja, sihtrühm ja aegumisaeg kuuluvad samuti kontrolli juurde. Kasutage selleks hooldatavat teeki oma teostuste asemel.

Oma tokenid, näiteks veebikonksude või ühekordsete linkide jaoks, peavad pärinema krüptograafiliselt turvalisest juhuslikkuse generaatorist ja neid tuleb võrrelda konstantse ajaga. Kuidas see PHP-s käib, näitab Turvalised juhuarvud ja tokenid PHP-s.

Piiride seadmine: suurus, tüüp ja tempo

API peaks vastu võtma ainult seda, mida ta ootab. See algab sisutüübist: lõpp-punkt, mis töötleb JSON-i, lükkab kõik muu tagasi. Päringu maksimaalset suurust piirate mitmel tasandil, veebiserveris ja PHP-s valikuga post_max_size. See piir kuulub ka üleminekumeetmete hulka, mille php.net PHP2Shelli kohta nimetas. Kuidas seda mõistlikult valida, kirjeldab post_max_size ja upload_max_filesize mõistlik piiramine.

Päringute piiramine kaitseb tunnuste läbiproovimise ja ülekoormuse eest. Seda saab ellu viia veebiserveris, ülesvoolu proksis või rakenduses. Oluline on, et piirid kehtiksid võtme või kasutaja, mitte ainult IP-aadressi kohta.

API-de puhul, mida kutsutakse otse brauserist, lisandub CORS, see tähendab reeglid, millised võõrad veebisaidid tohivad päringuid esitada. Seadke need päised ainult siis, kui sellised päringud on tõesti ette nähtud, ja nimetage lubatud päritolud eraldi, selle asemel et lubada igat päritolu. Kohatäide, mis lubab kõik veebisaidid, on sisselogimisega lõpp-punktide puhul peaaegu alati viga.

Lõpuks protokoll: ebaõnnestunud sisselogimised, tagasi lükatud tokenid ja keelatud ligipääsud kuuluvad logisse, tokenid ise mitte. Ilma nende kirjeteta jääb rünnak API vastu nähtamatuks.

Kuidas PHP SOS konkreetselt aitab?

• Me kaardistame kõik teie PHP-süsteemide liidesed, ka unustatud ja sisemised, ning kontrollime, millised on avalikult kättesaadavad.
• Me loeme õiguste loogikat ja testime sihipäraselt, kas võõraid kirjeid saab pärida.
• Me seame suuruse, tüübi ja tempo piirid veebiserveris ja PHP-s ning kooskõlastame need teie klientidega.
• Põhjaliku väljastpoolt kontrolli jaoks ühendame selle turvaaudiiti ja läbitungimistestiga.

Kokkuvõte: API on nii turvaline kui tema hooletuim lõpp-punkt. Kes kontrollib õigusi objekti kaupa, seab selged piirid ja hoiab vead napid, sulgeb sagedasemad augud, kaua enne kui keegi neid sihipäraselt otsib.

Korduma kippuvad küsimused

Allikad

• OWASP: REST Security Cheat Sheet
• OWASP Top 10
• PHP käsiraamat
• php.net: turvateated