Zavarovanje API REST v PHP

Na kratko: Za varnost API v PHP štejejo predvsem pet točk: samo HTTPS, overjanje pri vsaki nejavni končni točki, preverjanje pooblastil za vsak posamezen objekt, stroge omejitve za metodo, tip vsebine in velikost zahteve ter kratka sporočila o napakah brez notranjih podrobnosti. K temu pridejo omejevanje hitrosti in dnevnik varnostno pomembnih dogodkov. Proti ranljivostim v samem interpreterju PHP, kot je PHP2Shell, to ne pomaga; za to je potrebna posodobitev PHP.

Vmesnik za spletno stranjo

Mnoga podjetja so v tednu po 21. 10. 2026 pregledala svoje spletne strani. Vmesniki za njimi so bili redkeje na seznamu. Pa ravno tam tečejo občutljivi postopki: aplikacija portala za stranke prevzema račune, sistem za upravljanje blaga zapisuje zaloge v spletno trgovino, partner prek webhooka sporoča naročila. Ti API-ji so bili pogosto hitro zgrajeni, za en sam namen, in nato nikoli več pogledani.

API nima vmesnika, ki bi napake naredil vidne. Manjkajoče preverjanje pooblastil v vsakdanu nihče ne opazi, dokler vsi odjemalci poizvedujejo samo po tem, po čemer morajo. Napadalec pa preizkusi natanko tisto, kar ni predvideno.

Prvi korak je zato popis. Katere končne točke sploh obstajajo? Pogosto se najdejo stare različice, kot je /api/v1/, ki po prehodu na /v2/ niso bile nikoli izklopljene, testne končne točke iz razvoja ali javno dosegljiv opis vmesnika, ki našteva notranje funkcije. Vsako končno točko, ki ni več potrebna, je treba izklopiti. Vsaka, ki ostane, potrebuje odgovorno osebo.

Varnost API v PHP: osnovna pravila

OWASP REST Security Cheat Sheet povzema preverjena pravila. Za projekte PHP jih je mogoče prevesti v kratek seznam:

1. Samo HTTPS. Žetoni in dostopni podatki se nikoli ne smejo prenašati nešifrirani.
2. Vsaka končna točka preverja sama. Overjanje se lahko izvede osrednje, odločitev o dostopu pa pade pri končni točki.
3. Pooblastilo po objektu. Ne samo „je prijavljen“, ampak „sme natanko ta zapis“.
4. Določite dovoljene metode. Kar ni izrecno dovoljeno, se zavrne z 405.
5. Preverite tip vsebine in velikost. Napačen tip da 415, prevelike zahteve 413.
6. Preverjajte vnose. Tip, dolžina, oblika in obseg vrednosti, na strežniku.
7. Brez skrivnosti v URL-jih. Žetoni in ključi sodijo v glave, ne v niz poizvedbe.
8. Kratke napake. Brez sledi sklada (stack trace), poti ali sporočil SQL odjemalcu.
9. Omejevanje hitrosti. Na preveč zahtev se odgovori s 429.
10. Zaščitite upravljalske končne točke. Ne javno dosegljive ali samo z močno prijavo.

Pooblastilo za objekt: najpogostejša napaka

Primer naredi težavo otipljivo. Končna točka vrača račune pod /api/rechnungen/{id}. Preverja se, ali je veljaven žeton. Ne preverja se, ali račun pripada stranki žetona. Kdor svojo številko računa poveča za ena, vidi sosedov račun.

Rešitev je preprosta in jo je vseeno treba izvesti na vsakem mestu: poizvedba sama omeji na upravičeno območje.

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

$kundeId = $auth->kundeId();          // iz preverjenega žetona
$id = filter_var($routeId, FILTER_VALIDATE_INT);
if ($id === false) {
    http_response_code(400);
    exit;
}

// Pooblastilo je v poizvedbi: samo lastni računi
$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);           // ne izdajte, ali ID obstaja
    exit;
}

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

Poizvedba z nadomestnimi znaki hkrati ščiti pred SQL injection, glejte Preprečevanje SQL injection v PHP. Kako PHP daje na voljo podatke zahteve, kot so metoda, glave in telo, pojasnjuje Superglobals: $_GET, $_POST, $_FILES in drugi.

Pravilno preverjanje žetonov

Mnogi API-ji delajo z žetoni JSON Web Token. OWASP Cheat Sheet za to navaja jasna pravila: žetoni morajo biti podpisani, nepodpisani žetoni se zavrnejo, algoritem za preverjanje pa se določi na strežniku in se ne prevzame iz žetona. K preverjanju sodijo tudi izdajatelj, ciljna skupina in čas poteka. Za to uporabite vzdrževano knjižnico namesto lastnih izvedb.

Lastni žetoni, na primer za webhooke ali enkratne povezave, morajo izvirati iz kriptografsko varnega generatorja naključnih števil in se primerjati v konstantnem času. Kako to storite v PHP, kaže Varna naključna števila in žetoni v PHP.

Postavite meje: velikost, tip in hitrost

API naj sprejme samo to, kar pričakuje. To se začne pri tipu vsebine: končna točka, ki obdeluje JSON, zavrne vse drugo. Največjo velikost zahteve omejite na več ravneh, v spletnem strežniku in v PHP prek post_max_size. Ta meja sodi tudi med prehodne ukrepe, ki jih je php.net navedel ob PHP2Shell. Kako jo smiselno izberete, opisuje Smiselna omejitev post_max_size in upload_max_filesize.

Omejevanje hitrosti ščiti pred preizkušanjem oznak in pred preobremenitvijo. Mogoče ga je izvesti v spletnem strežniku, v predhodnem proxyju ali v aplikaciji. Pomembno je, da meje veljajo po ključu ali uporabniku in ne samo po naslovu IP.

Za API-je, ki se kličejo neposredno iz brskalnika, pride zraven CORS, torej pravila, katere tuje spletne strani smejo pošiljati zahteve. Te glave nastavite samo, če so taki klici res predvideni, in dovoljene izvore navedite posamično, namesto da bi dovolili vsak izvor. Nadomestni znak, ki dovoli vse spletne strani, je pri končnih točkah s prijavo skoraj vedno napaka.

Nazadnje dnevnik: neuspele prijave, zavrnjeni žetoni in zavrnjeni dostopi sodijo v dnevnik, žetoni sami ne. Brez teh vnosov napad na API ostane nevidan.

Kako konkretno pomaga PHP SOS?

• Zajamemo vse vmesnike vaših sistemov PHP, tudi pozabljene in notranje, in preverimo, kateri so javno dosegljivi.
• Preberemo logiko pooblastil in ciljno preizkusimo, ali je mogoče pridobiti tuje zapise.
• Meje za velikost, tip in hitrost postavimo v spletnem strežniku in PHP ter jih uskladimo z vašimi odjemalci.
• Za celovit pregled od zunaj to združimo z varnostnim pregledom in penetracijskim testom.

Sklep: API je tako varen kot njegova najbolj malomarna končna točka. Kdor preverja pooblastila po objektu, postavi jasne meje in napake ohrani kratke, zapre najpogostejše vrzeli, dolgo preden jih kdo ciljno išče.

Pogosta vprašanja

Viri

• OWASP: REST Security Cheat Sheet
• OWASP Top 10
• Priročnik PHP
• php.net: varnostna obvestila