API (Application Programming Interface = rakendusliides) turvalisuse testimine viitab API-de turvalisuse hindamise ja tagamise protsessile. API-d on liidesed, mis võimaldavad erinevatel tarkvarasüsteemidel üksteisega suhelda ja vastastikku toimida. Nende kaudu saavad rakendused andmeid ja funktsioone jagada, muutes API-d kaasaegse tarkvaraarenduse oluliseks osaks.

API-de turvalisuse testimine hõlmab API-de rakenduste haavatavuste ja nõrkuste hindamist, et vältida võimalikke turvarikkumisi ja kaitsta tundlikke andmeid. Esmane eesmärk on tuvastada ja kõrvaldada turvapuudused, väärkonfiguratsioonid või haavatavused, mida pahatahtlikud osalejad võivad ära kasutada. Põhjalike turvatestide läbiviimisega saavad organisatsioonid parandada oma API-de üldist turvalisust ning minimeerida volitamata juurdepääsu, andmete rikkumise ja muude turvaintsidentide riski.

API-de turvalisuse testimine hõlmab tavaliselt järgmisi valdkondi:

1. Autentimine ja autoriseerimine: kontrollimine, kas API lõpp-punktides on kasutusel õiged autentimismehhanismid, nagu API võtmed, pääsmed või OAuth (“avatud volitamine”), ja tagamine, et juurdepääsu reguleerimisvahendid on volitamata juurdepääsu piiramiseks õigesti rakendatud.
2. Sisendvalideerimine: API-liidesesse sisestatud andmete valideerimine, et vältida levinud turvanõrkusi, nagu süstimisrünnakud (nt SQL-i süstimine, XML-i süstimine) või saidiülesed skriptimisrünnakud (XSS).
3. Krüpteerimine ja andmete terviklikkus: API-de kaudu edastatavate tundlike andmete nõuetekohase krüpteerimise tagamine, kasutades turvalisi protokolle, nagu HTTPS, ja andmete terviklikkuse kinnitamine selliste tehnikate abil nagu sõnumite allkirjastamine või räsimine.
4. Kiiruse piiramine ja edastuse ahendamine: kontrollimine, kas API-d rakendavad õigeid kiiruse piiramise ja ahendamise mehhanisme, et vältida kuritarvitamist või teenusetõkestuse (DoS) rünnakuid.
5. Vigade käsitlemine ja logimine: kontrollimine, et API-de tagastatud veateated ei avaldaks tundlikku teavet ja et turvaintsidentide tuvastamiseks ja uurimiseks on olemas asjakohased logimismehhanismid.
6. Kolmanda osapoole integratsioonid: kolmanda osapoole API-integratsioonide turvalisuse hindamine, et tuvastada võimalikud riskid, mis on seotud andmete või funktsioonide jagamisega välisteenustega.
7. Turvapäised: turvapäiste olemasolu ja tõhususe hindamine API vastustes, nagu sisu turvapoliitika (CSP), allikatevaheline ressursside ühiskasutus (CORS) või HTTP range transporditurve (HSTS).

API turvalisust saab testida erinevate tehnikate abil, sealhulgas käsitsi testimine, automatiseeritud skaneerimisvahendid, läbistustestid ja koodiülevaatused. Organisatsioonid peaksid turvalisust regulaarselt hindama, et tagada API-de turvalisus kogu nende elutsükli vältel ja kohaneda arenevate turvaohtudega.

Põhjalik API-de turvalisuse testimine hõlmab tavaliselt mitut sammu. Konkreetsed sammud võivad olenevalt testimisviisist ja organisatsiooni nõuetest erineda, kuid järgnevalt toome ära API-de turvalisus testimise üldised etapid:

1. Nõuete analüüs: API-de eesmärgist, funktsionaalsusest ja turvanõuetest arusaamine. Testimise ulatuse tuvastamise, sealhulgas lõpp-punktide, autentimismehhanismide ja kaasatud andmetüüpide määratlemine.
2. Ohu modelleerimine: API-le omaste võimalike ohtude ja riskide analüüsimine. Erinevate rünnakuvektorite, nagu süstimisrünnakud, vigane autentimine või andmete paljang, kaalumine. See samm aitab välja valida valdkonnad, mis vajavad testimise ajal rohkem tähelepanu.
3. Testikeskkonna seadistamine: sobiva testikeskkonna loomine, mis võib hõlmata test API-de seadistamist, testserverite seadistamist ning vajalike tööriistade ja testimisraamistike ettevalmistamist.
4. Autentimise ja autoriseerimise testimine: kontrollimine, kuidas API autentimist ja autoriseerimist käsitleb. Erinevate autentimismehhanismide, nagu API võtmed, pääsmed või OAuth kontrollimine, et tagada nende korrektne toimimine ja sobivad juurdepääsukontrollid.
5. Sisendvalideerimise testimine: API sisendi valideerimismehhanismide testimine, et tuvastada ja ennetada levinud turvanõrkusi, nagu süstimisrünnakud (nt SQL-i süstimine, XML-i süstimine) või saidiülesed skriptimise (XSS) rünnakud. Erinevate sisendväärtuste esitamine, sealhulgas kehtivad, kehtetud ja pahatahtlikud andmed, et hinnata, kuidas API neid käsitleb.
6. Krüptimise ja andmete terviklikkuse testimine: API krüpteerimisprotokollide ja andmete terviklikkuse mehhanismide valideerimine. Veendumine, et API kaudu edastatavad tundlikud andmed oleksid turvaliste protokollide (nt HTTPS) abil nõuetekohaselt krüptitud. Andmete terviklikkuse testimine selliste tehnikate abil nagu sõnumite allkirjastamine või räsimine.
7. Vigade käsitlemise ja logimise testimine: hindamine, kuidas API käsitleb vigu ja erandeid. Erinevate veastsenaariumide testimine ja kontrollimine, kas veateateid käsitletakse turvaliselt, ilma tundlikku teavet paljastamata. Veendumine, et turvaintsidentide tuvastamiseks ja uurimiseks on kehtestatud vajalikud logimismehhanismid.
8. Kiiruse piiramise ja edastuse ahendamise testimine: veendumine, et API rakendab õigeid kiiruse piiramise ja ahendamise mehhanisme, et vältida kuritarvitamise või teenusetõkestuse (DoS) rünnakuid. API käitumise testimine suure koormuse või arvukate päringute korral.
9. Kolmanda osapoole integratsiooni testimine: kolmanda osapoole API-integratsioonide turvalisuse hindamine, võttes arvesse võimalikke riske, mis on seotud andmete või funktsioonide jagamisega välisteenustega. Kontrollimine, kas väliste API-dega suhtlemisel on rakendatud sobivaid turvameetmeid.
10. Turvapäiste testimine: API vastuste turvapäiste olemasolu ja tõhususe hindamine. Kontrollimine, kas turvapäised, nagu sisu turvapoliitika (CSP), allikatevaheline ressursside ühiskasutus (CORS) või HSTS (HTTP range transporditurve), on õigesti rakendatud.
11. Haavatavuste skaneerimine ja läbistustestimine: API levinumate turvaaukude ja võimalike nõrkuste tuvastamiseks automatiseeritud skaneerimisvahendite ja käsitsi läbistustestimise tehnikate kasutamine. See samm aitab avastada turvavigu, mis võisid eelmistes sammudes kahe silma vahele jääda.
12. Teatamine ja kõrvaldamine: API turvalisuse testimisel avastatud leidude, haavatavuste ja soovituste dokumenteerimine. Põhjaliku aruande esitamine arendusmeeskonnale või sidusrühmadele. Veendumine, et tuvastatud haavatavused kõrvaldatakse viivitamata sobivate parandusmeetmete abil.

Oluline on märkida, et API-de turvalisuse testimine on iteratiivne protsess ja etapid võivad kattuda või neid võib vajadusel korrata, et tagada API-de turvalisuse seisundi põhjalik hindamine.

Open API skeem ehk avalik rakendusliides, tuntud ka kui Swagger Schema, on standardvorming, mida kasutatakse RESTful API-de kirjeldamiseks. See annab struktureeritud esituse API lõpp-punktidest, päringu/vastuse lastist, parameetritest, päistest, autentimisnõuetest ja muudest olulistest üksikasjadest.

Open API skeem mängib API-de turvalisuse testimisel üliolulist rolli järgmistel põhjustel:

1. Testi katvus: Open API skeem toimib API tervikliku kavandina, dokumenteerides kõik saadaolevad lõpp-punktid, sisendparameetrid, oodatavad vastused ja võimalikud veastsenaariumid. See aitab testijatel tagada, et nad katavad turvatesti ajal API kõiki aspekte, vähendades kriitiliste funktsioonide või turvakontrollide vahelejätmise ohtu.
2. Testi korraldamine: Open API skeemi kasutades saavad testijad API spetsifikatsioonide põhjal automatiseerida testjuhtumite genereerimise protsessi. Testimisraamistikud ja -tööriistad võivad skeemi kasutada, et automaatselt genereerida päringuid, valideerida vastuseid ja kontrollida API dokumenteeritud käitumise järgimist.
3. Sisendi valideerimine: Open API skeem määratleb eeldatavad andmetüübid, vormingud ja sisendparameetrite piirangud. Testijad saavad seda teavet kasutada API sisendikäsitluse kinnitamiseks ja piiritestide läbiviimiseks, tagades, et API käsitleb õigesti erinevaid andmesisendeid, sealhulgas piiripealseid juhtumeid ja pahatahtlikke sisendeid.
4. Väljundi valideerimine: skeem määrab ka API vastuste eeldatava struktuuri ja sisu. Testijad saavad võrrelda testimise käigus saadud tegelikke vastuseid määratletud skeemiga, et API tagastaks oodatud andmed ja käsitleks veastsenaariume õigesti. See aitab kontrollida API väljundi valideerimist, andmete puhastamist ja veakäsitluse mehhanisme.
5. Turvakontrollid: Open API skeem sisaldab teavet autentimismehhanismide, autoriseerimisnõuete ja turvalisusega seotud päiste kohta. Testijad saavad neid andmeid kasutada kinnitamaks, et API rakendab õigeid turvakontrolle, nagu turvalised sideprotokollid (nt HTTPS), autentimis- ja autoriseerimismehhanismid ning turvalisusega seotud HTTP päistest kinnipidamine.
6. Dokumentatsioon ja koostöö: Open API skeem toimib API keskse dokumentatsioonina. See aitab testijatel mõista API võimalusi, nõudeid ja turvakaalutlusi. See hõlbustab ka koostööd testijate, arendajate ja sidusrühmade vahel, pakkudes ühtset võrdluspunkti API käitumise, turvanõuete ja testimisstrateegiate arutamiseks.

Kokkuvõtteks võib öelda, et Open API skeem on API-de turvalisuse testimiseks hädavajalik, kuna see esitab API struktuuri ja käitumise standardiseeritud, masinloetaval kujul. See võimaldab testijatel tagada testi katvuse, automatiseerida testjuhtumite genereerimist, valideerida sisend-/väljundandmeid, kinnitada turvakontrolle ja hõlbustada koostööd kogu testimisprotsessi vältel.

API-de turvalisuse testimise tulemuseks on tavaliselt mitu väljundit, mis dokumenteerivad testimisprotsessi leiud, soovitused ja tulemused. Konkreetsed väljundid võivad erineda olenevalt organisatsiooni nõuetest ja läbiviidud testimise ulatusest. Järgnevalt toome ära on mõned API-de turvalisuse testimise levinumad väljundid:

1. Testiplaan: dokument, mis kirjeldab API-de turvalisuse testimisel kasutatavat lähenemisviisi, ulatust, eesmärke ja metoodikaid. See annab ülevaate testimistegevusest ja on testimisprotsessi juhendiks.
2. Testjuhtumid: API-de turvalisuse testimise käigus teostatud üksikute testjuhtumite üksikasjalik dokumentatsioon. Testjuhtumid kirjeldavad konkreetseid samme, oodatavaid tulemusi ja iga testi eesmärki. Need tagavad turvalisusega seotud stsenaariumide igakülgse katvuse.
3. Testiraport: põhjalik aruanne, mis võtab kokku API-ide turvalisuse testi tulemused, leiud ja soovitused. See sisaldab ülevaadet testimisprotsessist, kokkuvõtet tuvastatud haavatavustest või nõrkustest ning nende võimaliku mõju analüüsi. Aruanne võib sisaldada ka soovitusi paranduste ja tulevaste täienduste kohta.
4. Haavatavuste hindamise aruanne: konkreetne aruanne, mis keskendub API-de turvalisuse testi käigus tuvastatud haavatavustele. See sisaldab iga haavatavuse üksikasjalikku analüüsi, sealhulgas selle mõju, tõsidust ja võimalikke ärakasutamisstsenaariume. Aruanne võib sisaldada ka soovitusi parandus- ja leevendusmeetmeteks.
5. Kontseptsiooni tõendavad rikkumismeetodid: mõnel juhul, eriti käsitsi läbistustestimise ajal, võidakse väljunditele lisada kontseptsiooni tõendavad (PoC) meetodid. Need PoC rikkumised näitavad konkreetsete haavatavuste ärakasutamist, tuues esile võimalikud riskid ja illustreerides tuvastatud turvavigade mõju.
6. Parandussoovitused: rakendatavate soovituste kogum tuvastatud haavatavuste ja nõrkuste kõrvaldamiseks. Need soovitused juhendavad, kuidas maandada riske ja parandada API-de turvalisust. Nendeks võivad olla konkreetsed tehnilised sammud, parimad praktikad või arhitektuurilised muudatused turvalisuse tõstmiseks.
7. Turvatesti esemed: see hõlmab kõiki API turvatesti käigus genereeritud täiendavaid tulemeid, nagu logifailid, ekraanipildid, võrgujäädvustused või konfiguratsioonifailid. Need tulemid pakuvad lisateavet ja tõendeid, mis toetavad leide ja soovitusi.

Oluline on märkida, et API-ide tuvalisuse testide tulemused peaksid olema kohandatud organisatsiooni konkreetsetele vajadustele ja nõuetele. Aruanded ja soovitused tuleks esitada selges ja arusaadavas vormis, mis võimaldab sidusrühmadel mõista tuvastatud riske ja rakendada nende lahendamiseks asjakohaseid meetmeid.

API-ide turvalisuse testimise projekti kestus võib mitme teguri tõttu oluliselt erineda. Konkreetne aeg sõltub API keerukusest, testimise ulatusest, kasutatavast testimisviisist, ressursside saadavusest ja organisatsiooni nõuetest. Järgnevalt toome välja mõned tegurid, mis võivad mõjutada API-de turvalisuse testimise projekti kestust:

1. API keerukus: API enda keerukus mängib testimise pikkuse määramisel olulist rolli. Suure arvu lõpp-punktide, keerukate andmestruktuuride ja keerukate autentimismehhanismidega API-de põhjalikuks testimiseks võib kuluda rohkem aega.
2. Testimise ulatus: testimise ulatus määrab testimistegevuste ulatuse ja sügavuse. Kui projekt hõlmab mitme aspekti (nt sisendi valideerimine, autentimismehhanismid, krüptimine ja kolmandate osapoolte integratsioonid) põhjalikku hindamist, võtab selle teostamine loomulikult kauem aega.
3. Testimisviis: valitud testimisviis võib mõjutada projekti kestust. Käsitsi testimine, kus turvalisuse testijad teevad iga sammu käsitsi, võtab tavaliselt rohkem aega kui  automaatne testimine skaneerimistööriistade või raamistike abil. Valitud lähenemisviis sõltub saadaolevatest ressurssidest, nõutavast testimise tasemest ja organisatsiooni eesmärkidest.
4. Ressursi kättesaadavus: ressursside, sealhulgas turvalisuse testijate ja testimistööriistade kättesaadavus võib mõjutada projekti pikkust. Kvalifitseeritud testijate piiratud kättesaadavus või viivitused vajalike tööriistade hankimisel võivad testimisprotsessi pikendada.
5. Suhtlemine ja koostöö: testimismeeskonna ja arendusmeeskonna vahelise suhtluse ja koostöö tõhusus võib mõjutada projekti üldist kestust. Tõhus koordineerimine tagab projekti sujuva kulu, probleemide õigeaegse lahendamise ja tõhusa tagasiside.
6. Testikeskkonna seadistamine: sobiva testikeskkonna seadistamine, sealhulgas näidis-API või testeksemplaride loomine, serverite konfigureerimine ja vajalike tööriistade ettevalmistamine võib võtta lisaaega. Testikeskkonna keerukus ja valmisolek mõjutab projekti kestust.
7. Aruandlus ja parandused: leidude dokumenteerimiseks, aruannete koostamiseks ja tuvastatud haavatavuste kõrvaldamiseks kuluv aeg võib olenevalt nende tõsidusest ja keerukusest erineda. Oluline on eraldada aruandluseks ja parandusteks piisavalt aega, et tagada tuvastatud probleemide piisav käsitlemine.

Neid tegureid arvesse võttes võib API-ide turvalisuse testimise projekti kestus ulatuda mõnest päevast mitme nädalani või kauemgi. Lihtsamate API-de ja fokusseeritud testimiseesmärkidega väikesemahulised projektid võidakse kiiremini lõpule viia, samas kui suuremad projektid keerukamate API-de ja põhjalike testimisnõuetega võivad võtta kauem aega.

Küsimuste korral on meie meeskond valmis aitama. Võtke meiega ühendust aadressil info@c-yber.com ja me anname endast parima, et teie küsimustele vastata.