API turvatestimine: ligipääsud, andmed ja äriloogika

Autentimine ja autoriseerimine ei ole sama

Autentimine kontrollib, kes päringu teeb, näiteks sessiooni või tokeni alusel. Autoriseerimine kontrollib, kas see kasutaja tohib konkreetset objekti näha või toimingut teha. Kehtiv sisselogimine ei anna õigust teise kliendi arvele ega administraatori funktsioonile. Mõlemad piirid peavad kehtima serveris; brauseris peidetud nupp ei ole piisav kaitse.

Mida API pentest hindab?

OWASP API Security Top 10 (2023) koondab levinud riskikategooriaid, mitte kohustuslikku testipaketti ega garantiid, et igaüks neist ühes töös läbi kontrollitakse. Ulatuse järgi võib hindamine vaadata näiteks:

• Objekti- ja funktsioonipõhine autoriseerimine: kas kasutaja saab üksnes lubatud objektide ja toiminguteni (BOLA/IDOR, rollipiirangud)?
• Autentimine ja väljade nähtavus: kas identiteeti kontrollitakse piisavalt ning vastus või muutmispäring ei ava ega muuda liigseid omadusi?
• Ressursipiirangud ja ärivood: kas kallid või korduvad päringud on asjakohaselt piiratud ning kas tegevuste järjekorda või ärireegleid saab kuritarvitada?
• Inventar ja konfiguratsioon: kas teada on kasutusel olevad API versioonid ja lõpp-punktid, ning kas rakenduse seadistus tekitab tarbetut riski?

OWASP juhend ja Top 10 aitavad riske sõnastada. Kontrollide valik sõltub süsteemist, loa piiridest, testkeskkonnast ja tellija küsimusest. Automatiseeritud skannimine üksi ei asenda ligipääsude ega äriloogika kontrolli.

Rollide ja tenantide ligipääsumaatriks

Enne testimist kirjuta üles, millist infot ja toiminguid iga roll vajab. Näide kahe kliendi (tenant) ja kahe rolliga:

Kontrolli sama reeglit päringu eri osades: URL-i objekti-ID, päringu keha, filtrid ja vastuse väljad. Õige tulemus pole tingimata üks kindel HTTP-kood; oluline on, et andmeid ega toimingut ei avaldata ning rakenduse lepingujärgne vastus oleks kooskõlaline.

Ettevalmistuse kontrollnimekiri

• Ulatuse kirjeldus: hostid, API versioonid, testkeskkond, lubatud ajavahemik ja keelatud tegevused.
• API kirjeldus: OpenAPI dokument või Postmani kogu koos märkega, millised lõpp-punktid on kasutusel ja mis on vananenud.
• Testkontod ja rollid: vähemalt vajalikud rollid ning kaks sünteetiliste andmetega tenantit, et ligipääsupiire kontrollida. Ära saada päris kasutajate paroole.
• Oodatud õigused: rolli-/tenantimaatriks, tundlike väljade kirjeldus, tähtsad ärivood ja kavandatud turvakontrollid.
• Koordinatsioon: tehniline kontakt, intsidentide teavitamise viis ning varunduse või taastamise korraldus, kui test seda vajab.

Need sisendid vähendavad valearusaamu, kuid ei tähenda, et test katab automaatselt iga API rada või OWASP kategooria. Katvus kinnitatakse kokkulepitud tööplaanis.

BOLA ja IDOR: mida API pentest kontrollib?

BOLA (Broken Object Level Authorization) tähendab puudulikku objektipõhist ligipääsukontrolli: API ei kontrolli piisavalt, kas päringu tegija tohib viidatud objekti kasutada. IDOR (Insecure Direct Object Reference) kirjeldab viga, kus URL-i või päringu objekti viite muutmine avab lubamatu ligipääsu. Need mõisted kattuvad objektipõhiste õiguste kontrollis; juhuslik või raskesti arvatav ID ei asenda autoriseerimist. Taust: OWASP IDOR-i ennetamise juhend.

Ohutu näide kahe testkontoga

Omaniku loaga testkeskkonnas on sünteetilised kliendid A ja B ning kummalgi testarve. A testkontoga kontrollitakse enda arve vaatamist ning kokkulepitud mahus B testarve viitega päringut. Oodatud tulemus: A ei näe B arve sisu ega saa seda muuta. Kasuta minimaalset arvu päringuid ja ainult näidisandmeid; päris klientide andmete uurimine ei kuulu näitesse.

Raportis märgi mõjutatud otspunkt ja meetod, aeg ja keskkond, rollid, sünteetilised objektid, oodatud ning tegelik tulemus, saladustest puhastatud päringu/vastuse tõend ja kordustesti tulemus. Maskeeri tokenid, paroolid ja isikuandmed. Olulise leiu vaatab üle inimene, et välistada valehäire ning hinnata tegelikku mõju.

Testi ainult kirjalikult lubatud ulatuses. Paroolide massproovimine, koormus- ja mahutestid võivad teenust häirida; tootmises vajavad need eraldi selgesõnalist luba ja piiranguid. Ära testi kolmandate osapoolte süsteeme, mida luba ei hõlma.

Kuidas ostjana sobiv test tellida?

Kirjelda, millist otsust test aitab teha: näiteks tenantide andmete eraldatus, maksevoo õigused või avaliku API eksponeeritud funktsioonid. Küsi pakkujalt, millised keskkonnad ja rollid kaasatakse, millised meetodid jäävad välja, kuidas leiud valideeritakse ja millise kujuga saad parandamiseks piisava raporti. Hind, ajastus ja kontrolli täpne ulatus tuleb kokku leppida konkreetse süsteemi põhjal – see juhend ei määra fikseeritud paketti.

Kui vajad teenuse kohta teavet, vaata API ja veebirakenduse pentestimise teenust. Laiema turvaseisu jaoks tutvu ka küberauditi sisuga; veebirakenduse testimise käsitlus on eraldi veebirakenduse turvatestimise juhendis.

API turvatestimine tähendab siin sinu süsteemi hindamist. See ei ole sama mis Tehisabilise arendatav turvatööriistade API, mis on eraldi kavandatav teenus ega ole avalik.

Allikad ja edasilugemine

• OWASP API Security Top 10 (2023) kirjeldab kümmet API riskikategooriat; see ei ole ettevõtte sertifikaat ega konkreetse testi katvuse tõend.
• OWASP Web Security Testing Guide v4.2 sissejuhatus rõhutab ulatuse, piirangute, tulemuste taasesituse ja raporti tähtsust.
• NIST SP 800-115 käsitleb tehnilise turvatestimise kavandamist, läbiviimist ja tulemuste käsitlemist; see ei ole sertifikaat.