262-000177-001 OWASP 10 parimat API turvalisuse tagamiseks
„
Tooteteave
Tehnilised andmed
- Toote nimi: Arendaja juhend 2023. aasta OWASP 10 parima API kohta
Turvalisus - Sisu: API turvalisuse spikker, definitsioonid ja üksikasjalikud juhised
2023. aasta OWASP 10 parima API turvalisuse juhendid
Toote kasutusjuhised
Sissejuhatus API turvalisusse
Arendaja juhend annab põhjalikku teavet teema kohta
2023. aasta OWASP 10 parimat API turvalisuse osas, tuues esile levinud turvalisuse
riskid API-dega rakenduste arendamisel.
API turvalisuse spikker
Spikker loetleb järgmised API turvalisuse kategooriad
riskid:
- Katkise objekti tasemel autoriseerimine
- Katkine autentimine
- Katkise objekti atribuuditaseme autoriseerimine
- Piiramatu ressursitarbimine
- Katkise funktsioonitaseme autoriseerimine
- Piiramatu juurdepääs tundlikele ärivoogudele
- Serveripoolse päringu võltsimine
- Turvalisuse valekonfiguratsioon
- Ebaõige varude haldamine
- API-de ohtlik tarbimine
Arendaja juhend üleview
Juhend käsitleb iga API turvariski kategooriat põhjalikult, pakkudes järgmist.
üksikasjalikud selgitused ja juhised selle kohta, kuidas sellega toime tulla ja seda leevendada
need riskid tõhusalt.
Korduma kippuvad küsimused (KKK)
K: Miks on API turvalisus oluline?
A: API turvalisus on ülioluline, kuna API-d paljastavad sageli tundlikke andmeid
ja rakendusloogikat, muutes need ründajate peamisteks sihtmärkideks.
API-de turvamine on andmelekke vältimiseks hädavajalik.
tagades süsteemi üldise turvalisuse.
K: Kuidas saan rakendada turvalisi API-sid?
A: Turvaliste API-de rakendamiseks järgige parimaid tavasid, näiteks
nõuetekohane autentimine, autoriseerimismehhanismid, sisendi valideerimine,
tundlike andmete krüpteerimine ning regulaarsed turvahinnangud ja
uuendused.
"`
VALGE PABER
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
Sisu
API turvalisuse spikker
5
Definitsioonid
5
API1:2023 – Katkine objektitaseme autoriseerimine
7
API2:2023 – Katkine autentimine
8
API3:2023 – Katkise objekti atribuuditaseme autoriseerimine
9
API4:2023 – piiramatu ressursikasutus
11
API5:2023 – Katkine funktsioonitaseme autoriseerimine
13
API6:2023 – piiramatu juurdepääs tundlikele ärivoogudele
14
API7:2023 – Serveripoolse päringu võltsimine
16
API8:2023 – Turvalisuse valekonfiguratsioon
18
API9:2023 – Ebaõige varude haldamine
19
API10:2023 – API-de ohtlik kasutamine
21
API turvalisuse top 10-st ei piisa!
23
Järeldus
23
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
2/23
Kuna ettevõtted on omaks võtnud pilvepõhise infrastruktuuri ja DevOp-stiilis metoodikad, web Rakenduste programmeerimisliidesed ehk API-d on levinud. Mõned populaarseimad avalikud API-d hõlmavad neid, mis võimaldavad arendajatel juurde pääseda Google'i otsingule, kraapida andmeid TikTokist, jälgida sõidukeid, koguda sporditulemusi ja koguda andmeid populaarsetelt saitidelt piltide allalaadimise kohta.1 2023. aastal moodustas API-ga seotud liiklus 58 protsenti kogu dünaamilisest – vahemällu mittesalvestatavast – liiklusest, mis on tõus võrreldes 54 protsendiga 2021.2. aasta lõpus.XNUMX
API-dest on saanud ka ettevõtterakenduste omavahelise suhtluse ja integratsiooni viis. Ettevõtted kasutavad umbes kahte kolmandikku oma API-dest (64%) oma rakenduste ühendamiseks partneritega, samas kui umbes pooled (51%) on mikroteenuste pääsupunktid. Üldiselt kasutab enam kui kolmveerand ettevõtetest keskmiselt vähemalt 25 API-t rakenduse kohta.3
API-põhise rakendusinfrastruktuuri kasutuselevõtt ei tohiks olla üllatav: ettevõtted, mis võtavad API-sid kasutusele kolmandate osapoolte arendajate ligimeelitamiseks ja ökosüsteemide loomiseks, näevad suuremat kasvu. Need „ümberpööratud ettevõtted” – nn seetõttu, et nad pööravad ümber traditsioonilised kontseptsioonid tehnoloogiate ümber tõkete loomisest ja võimaldavad avatud juurdepääsu teatud võimalustele ja andmetele – kasvasid kahe aasta jooksul ligi 13 protsenti ja 39 aasta jooksul 16 protsenti võrreldes ettevõtetega, kes API-sid ei võtnud kasutusele, selgub Chapmani ülikooli ja Bostoni ülikooli teadlaste 2022. aasta artiklist.4
Mikroteenuste, konteinerdamise ja API-de kasutuselevõtuga kaasneb aga mitmesuguseid riske, näiteks ebaturvalised tarkvarakomponendid, kehv äriloogika ja vigane andmeturve. Üheksa kümnest organisatsioonist (92%) on kogenud vähemalt ühte ebaturvaliste API-dega seotud turvaintsidenti.5 Suurettevõtetel on tavaliselt tuhandeid API-sid ja rünnakud nende süsteemide vastu moodustavad umbes 20 protsenti turvaintsidentidest, samas kui väiksematel ettevõtetel on sadu API-sid, mille väiksem rünnakupind moodustab viis protsenti turvaintsidentidest.6 Marsh McLennani hinnangul ületavad API haavatavuste põhjustatud rikkumiste aastased kahjud kogu maailmas 40 miljardit dollarit.7
1 Arellano, Kelly. 50 populaarseimat API-t. RapidAPI ajaveeb. RapidAPI. Web Lehekülg. 16. märts 2023.
2 Tremante, Michael jt. Rakenduste turbearuanne: 2. aasta teine kvartal. Cloudflare'i ajaveeb. Cloudflare. Ajaveebipostitus. 2023. august 21.
3 Marks, Melinda. API rünnakupinna turvamine. Enterprise Strategy Group. Palo Alto Networksi sponsor. PDF-aruanne, lk 10. 23. mai 2023.
4 Benzell, Seth G. jt. Kuidas API-d loovad kasvu ettevõtte ümberpööramise abil. Sotsiaalteaduste uurimisvõrgustik. Uurimistöö. Läbi vaadatud: 30. detsember 2022.
5 API rünnakupinna turvamine. Enterprise Strategy Group, lk 14. 6 Lemos, Robert. API turvakaod on miljardeid, aga see on keeruline. Varjatud lugemine.
Uudisartikkel. 30. juuni 2022. 7 Marsh McLennan. API ebakindluse maksumuse kvantifitseerimine. Imperva sponsor.
PDF-aruanne. 22. juuni 2022.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
3/23
2023. aasta API turvalisuse 10 parima nimekiri toob esile kümme kõige levinumat ja tõsisemat turvariski, mis tekivad API-sid paljastavate või kasutavate rakenduste arendamisel.
Probleem on nii tõsine, et USA Riiklik Julgeolekuagentuur (NSA) tegi koostööd Austraalia Küberjulgeolekukeskusega (ACSC) ja USA Küberjulgeoleku ja Taristu Turvalisuse Agentuuriga (CISA), et pakkuda juhiseid API turvaprobleemide, eriti kõige levinumate, nn ebaturvaliste otseobjektiviidete (IDOR) haavatavuste kohta.8
Pole üllatav, et kasvavate turvaprobleemide taustal avaldas Open Worldwide Application Security Project (OWASP) oma API turvalisuse top 10 nimekirja värskenduse. Oma esimese 2019. aasta nimekirja värskendades toob 2023. aasta API turvalisuse top 10 nimekiri esile kümme kõige levinumat ja tõsisemat turvariski, mis tekivad API-sid paljastavate või kasutavate rakenduste arendamisel. Sellised probleemid nagu katkine objektitaseme autoriseerimine, mis hõlmab IDOR-i haavatavusi, jäävad eelmisest nimekirjast samaks. Siiski toovad uued kategooriad – või ümberkorraldatud kategooriad – nüüd esile probleeme, mida varem tähelepanuta jäeti, näiteks serveripoolne päringute võltsimine (API7:2023) ja piiramatu juurdepääs tundlikele ärivoogudele (API6:2023).
„Oma olemuselt paljastavad API-d rakenduste loogikat ja tundlikke andmeid, näiteks isikuandmeid (PII), ning seetõttu on API-dest üha enam saanud ründajate sihtmärk,“ teatas OWASP grupp oma teadaandes.9 „Ilma turvaliste API-deta oleks kiire innovatsioon võimatu.“
8 uut küberturvalisuse nõuannet hoiatab Web Rakenduste haavatavused. Riiklik Julgeolekuagentuur. Pressiteade. 27. juuli 2023.
9. Avatud ülemaailmne rakenduste turbeprojekt. OWASP API turvalisuse 10 parimat: Edasi. OWASP.org. Web Lehekülg. 3. juuli 2023.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
4/23
API turvalisuse spikker
OWASP 10 parimat kategooriat 1. Katkine objektitaseme autoriseerimine 2. Katkine autentimine 3. Katkine objektiomaduste tasemel autoriseerimine 4. Piiramatu ressursikasutus 5. Katkine funktsioonitaseme autoriseerimine 6. Piiramatu juurdepääs tundlikele ärivoogudele 7. Serveripoolse päringu võltsimine 8. Turvalisuse valekonfiguratsioon 9. Ebaõige varude haldamine 10. API-de ohtlik tarbimine
Küberturvalisuse lahendus SAST SAST, DAST SAST, DAST SAST, DAST, Secure API Manager SAST DAST DAST SAST, DAST Secure API Manager SCA, SAST
Definitsioonid
API lõpp-punkt – kahe süsteemi vaheline suhtluspunkt, tavaliselt URL konteineri või serveri mikroteenust käitavast osast. Kasutades URL, saab rakendus või arendaja serverilt teavet küsida või API-serveris või mikroteenuses toimingu teha.
API-ga seotud liiklus – Interneti-liiklus, mis koosneb HTTP- või HTTPS-päringust ja millel on XML- või JSON-vastus, mis näitab, et andmeid edastatakse rakendusele, tavaliselt SOAP-i, WSDL-i, REST API või gRPC kaudu (vt allpool).
Dünaamiline rakenduste turvalisuse testimine (DAST) – rakenduse või API-serveri analüüsimise protsess liidese abil, olgu see siis rakenduse kasutajaliides, web esiosa a jaoks web rakendus või URLs API lõpp-punktide jaoks. Musta kasti testimise puhul hindab see lähenemisviis rakendust "väljastpoolt sissepoole", rünnates rakendust samamoodi nagu ründajat, tavaliselt ilma sisemiste protsesside tundmiseta.
Staatiline rakenduste turvalisuse testimine (SAST) – lähenemisviis rakenduste turvalisusele, mis skannib lähtekoodi, binaar- või baitkoodi tuvastatud vigade või haavatavuste mustrite suhtes. Mõnikord nimetatakse seda ka valge kasti testimiseks, SAST kasutab „seestpoolt väljapoole“ lähenemisviisi, mis tuvastab potentsiaalsed haavatavused ja vead, mida väline ründaja võib või ei pruugi ära kasutada. Kerged staatilised tööriistad saavad arendajatele nende IDE-s reaalajas tagasisidet anda.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
5/23
Katkine objektitaseme autoriseerimine on laialt levinud ja kergesti ärakasutatav probleem web rakendused, kuna API-kõned kannavad olekuinfot. Rakendused on haavatavad, kui need lubavad kasutajal API-s identifikaatori määramise teel toiminguid teha, kontrollimata, kas kasutajal on nende toimingute tegemiseks volitused.
SOAP/WSDL – XML-põhine protokoll Web API-d. SOAP ise on protokoll ja WSDL (Web Teenuste definitsioonikeel (Service Definition Language) on vorming, mida kasutatakse teenuste ametlikuks kirjeldamiseks. Suure üldkulu tõttu on see API stiil uute arenduste jaoks ebapopulaarseks muutunud.
PUHKUS–A Web API-stiil, mis hõlmab sõnumite vahetamist otse HTTP kaudu, kasutades HTTP semantikat URLs-id ja tegusõnad ilma täiendavat „ümbrikku“ kasutamata. Sisu kodeeritakse tavaliselt JSON-vormingus, kuigi mõnel juhul on see XML-vormingus.
GraphQL – päringukeel, mis on loodud kasutamiseks API-des (päringute ja vastustega JSON-vormingus) koos serveripoolsete käituskeskkondadega nende päringute täitmiseks. See võimaldab klientidel määratleda vajalike andmete struktuuri ja seejärel need serverilt selles vormingus vastu võtta.
gRPC – API protokoll, mis on REST-ist võimsam. See kasutab HTTP/2 ja jõudluse suurendamise protokolle.tagmis pakub HTTP/1.1 kaudu. Üksikute sõnumite vorming on tavaliselt binaarne ja põhineb ProtoBufil, mis taas loob jõudluse paranemisetages üle REST ja SOAP.
2023. aasta API turvalisuse 10 parimat
Analoogne 2019. aasta API turvalisuse kirje
API1:2023 – Katkine objektitaseme autoriseerimine
API1:2019 – Katkine objektitaseme autoriseerimine
API2:2023 – Katkine autentimine
API2:2019 – Katkine kasutaja autentimine
API3:2023 – Katkise objekti atribuuditaseme autoriseerimine
API3:2019 – liigne andmetega kokkupuude, API6:2019 – massiline määramine
API4:2023 – piiramatu ressursikasutus
API4:2019 – Ressursside puudus ja kiirusepiirang
API5:2023 – Katkine funktsioonitaseme autoriseerimine
API5:2019 – Katkine funktsioonitaseme autoriseerimine
API6:2023 – piiramatu juurdepääs tundlikele ärivoogudele
API7:2023 – Serveripoolse päringu võltsimine
API8:2023 – Turvalisuse valekonfiguratsioon API7:2019 – Turvalisuse valekonfiguratsioon
API9:2023 – Ebaõige varude haldamine
API9:2019 – Ebaõige varade haldamine
API10:2023 – API-de ohtlik kasutamine
API8:2019 – süstimine, API10:2019 – ebapiisav logimine ja jälgimine
Source: https://owasp.org/API-Security/editions/2023/en/0x11-t10/ Source: https://owasp.org/API-Security/editions/2019/en/0x11-t10/
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
6/23
Arendajad ja rakenduste turbemeeskonnad peavad samuti korralikult rakendama võimalusi kasutaja identiteedi kontrollimiseks autentimise kaudu.
API1:2023 – Katkine objektitaseme autoriseerimine
Mis see on?
API-d võimaldavad juurdepääsu teenustele ja andmetele standardiseeritud abil web päringud. Ettevõtted seavad oma infrastruktuuri ja andmed ebaturvalisele otsesele juurdepääsule, kui need varad ei ole hästi kaitstud või kui autoriseerimiskontrollid on halvasti rakendatud või puuduvad. Katkine objektitaseme autoriseerimine – tuntud ka kui ebaturvaline otsene objektiviide (IDOR) – võib kaasa tuua mitmesuguseid riske, alates andmete avalikustamisest kuni konto täieliku ülevõtmiseni.
Mis teeb rakenduse haavatavaks?
See on laialt levinud ja kergesti ärakasutatav probleem web rakendused. Rakendused on haavatavad, kui need lubavad kasutajal API-s identifikaatori määramise teel toiminguid teha, kontrollimata, kas kasutajal on nende toimingute tegemiseks volitus.
EksisampOWASP-i poolt üksikasjalikult kirjeldatud veebipoodide platvorm võiks võimaldada juurdepääsu poeandmetele lihtsa kõne abil:
/shops/{shopName}/revenue_data.json
See on ebaturvaline, kuna iga kasutaja saab poeName'i asendada teise kasutaja poe nimega, saades juurdepääsu andmetele, mida tal ei tohiks olla.
Rünnake endistamples
2021. aastal leidis üks turvauurija, et web-rakendustel ja taustserveritel, mis edastasid andmeid Pelotoni treeningratastele, oli mitu API-lõpp-punkti, mis võimaldasid autentimata kasutajatel privaatsetele andmetele juurde pääseda. 2021. aasta veebruaris rakendas Peloton probleemi osalise paranduse, piirates API-juurdepääsu autentitud kasutajatele, kuid lubades neil kasutajatel siiski juurde pääseda teiste liikmete privaatsetele andmetele. Täielik parandus tuli 2021.10. aasta mais.XNUMX
Kuidas seda arendajana vältida?
Arendajad takistavad ebaturvalist juurdepääsu objektidele, kehtestades ranged kontrollimeetmed, määrates ettearvamatuid kasutajaidentifikaatoreid kontode loendamise vältimiseks ja kontrollides objektitaseme autoriseerimist iga funktsiooni puhul, mis pääseb juurde andmeallikale. Arendajad peaksid sellised kontrollid kapseldama, eriti kui need põhinevad kasutaja sisendil, et välistada võimalus, et tahtmatud vead võivad turvalisust kahjustada. Rakendusturbe ja operatsioonide spetsialistid peaksid nõudma autoriseerimiskontrolle iga taustandmete päringu jaoks.
Kuidas OpenText saab aidata?
OpenText™ staatilise rakenduste turbetestimise (SAST) ja OpenText™ dünaamilise rakenduste turbetestimise (DAST) abil saab tuvastada laia valikut haavatavusi ebaturvaliste otseobjektide viidete (IDOR) kategoorias. IDOR võib hõlmata selliseid haavatavusi nagu kataloogi läbimine, File Laadi üles ja File Kaasamine. Üldisemalt hõlmab IDOR ka haavatavuste klasse, kus identifikaatorid
10 Mastersi, jaanuar. Tour de Peloton: paljastatud kasutajaandmed. Pen Test Partnersi ajaveeb. Pen Test Partners. Web Lehekülg. 5. mai 2021.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
7/23
Arendajad ja rakenduste turbemeeskonnad peavad samuti korralikult rakendama võimalusi kasutaja identiteedi kontrollimiseks autentimise kaudu.
saab muuta läbi URL, Keha või päise manipuleerimine. Süsteem hoiatab arendajaid juhtumite eest, kus kasutaja saab API-päringus andmebaasi või salvestuskonteineri jaoks otse primaarvõtme valida – probleem, mis sageli viib seda tüüpi haavatavusteni. Süsteem hoiatab ka siis, kui eeldatav autoriseerimiskontroll puudub.
API2:2023 – Katkine autentimine
Mis see on?
Autoriseerimiskontrollid piiravad juurdepääsu andmetele konkreetsete rollide või kasutajate põhjal, kuid need piirangud ei ole süsteemide, andmete ja teenuste kaitsmiseks piisavad. Arendajad ja rakenduste turbemeeskonnad peavad ka korralikult rakendama võimalusi kasutaja identiteedi kontrollimiseks autentimise kaudu. Vaatamata autentimise kriitilisele olemusele on komponendid sageli halvasti rakendatud või valesti kasutatud – see on katkise kasutaja autentimise algpõhjused. Katkine kasutaja autentimine võimaldab ründajatel ajutiselt või jäädavalt omastada teiste kasutajate identiteete, kasutades ära ebaturvalisi autentimismärke või kahjustades rakendusvigu.
Mis teeb rakenduse haavatavaks?
See levinud ja kergesti ärakasutatav probleem tekib seetõttu, et autentimine on keeruline protsess, mis võib olla segadusttekitav ja on oma olemuselt avalikkusele avatud. Arendaja vead ja rakenduste valekonfiguratsioonid võivad põhjustada vajalike kontrollide puudumist, mis võimaldab ründajatel autentimist vältida. Arendajad, kes ei rakenda konkreetse lõpp-punkti autentimist või lubavad nõrka autentimismehhanismi, seavad rakendused ohtu mitmesugustele rünnakutele, näiteks volituste täitmisele, märgi kordamisele või paroolide nuhkimisele.
Rünnake endistamples
2023. aasta veebruarist juunini olid mandaatide võltsimise rünnakud suunatud rõivamüüjale Hot Topic, kes teavitas oma kliente tundmatust arvust kontodest, mis olid ohustatud. Ründajad said tundmatutest allikatest kogutud mandaate kasutades juurde pääseda tundlikele isikuandmetele, nagu klientide nimed, e-posti aadressid, tellimuste ajalugu, telefoninumbrid ning sünnikuud ja -päevad.11
2022. aasta veebruaris jättis valesti konfigureeritud pilvesalvestusämber 1 GB tundlikke andmeid e-posti turundusteenusest Beetle Eye ilma paroolikaitse või krüptimiseta. Andmed sisaldasid erinevate turismibüroode ja USA osariikide kogutud kontaktandmeid ja turismiga seotud teavet.12 Valesti konfigureeritud autentimismehhanisme peetakse katkise kasutaja autentimise kategooria variandiks.
Kuidas seda arendajana vältida?
11 Toulas, Bill. Jaemüügikett Hot Topic avalikustab volituste võltsimise rünnakute laine. BleepingComputer. Uudisartikkel. 1. august 2023.
12 Nair, Prajeet. 7 miljoni inimese andmed lekkisid USA turundusplatvormi kaudu. Andmeleke täna. ISMG Network. 11. veebruar 2022.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
8/23
Standardiseerimine on autentimise sõber. DevSecOpsi meeskonnad peaksid rakenduste jaoks looma ühe või piiratud arvu autentimismeetodeid ja tagama, et arendajad rakendavad neid mehhanisme ühtlaselt kõigis mikroteenustes ja API-des.
Standardiseerimine on autentimise sõber. DevSecOpsi meeskonnad peaksid rakenduste jaoks looma ühe või piiratud arvu autentimismeetodeid ja tagama, et arendajad rakendavad mehhanisme ühtlaselt kõigis mikroteenustes ja API-des. Iga autentimise rakendamine peaks olema ümber kujundatud.viewOWASP rakenduste turbekontrolli standardi (ASVS) kontekstis, mis on praegu versioonil 4,13, et tagada juurutamise ja sellega seotud turvakontrollide õigsus. Igasugust kõrvalekallet standardist – eriti igasugust tahtlikku autentimata lõpp-punktide avalikustamist – peaks hindama turvameeskond ja lubama seda ainult tugeva ärinõude täitmiseks.
Kuidas OpenText saab aidata?
OAuth ja JWT on kaks kõige levinumat autentimistüüpi, mida API-de rakendamiseks kasutatakse, ning OpenText Dynamic Application Security Testing kontrollib mõlema standardi nõrku rakendusi rakendustes, samuti valekonfiguratsioone ja haavatavaid mustreid, nagu CSRF ja seansi fikseerimine, mis ilmnevad kohandatud autentimise rakendamisel. OpenTexti dünaamilise rakenduse turbetööriista (DAST) skannimine on suurepärane viis autentimise haavatavuste tuvastamiseks, eriti API-s.
OpenTexti staatilise rakenduse turvatestimine võimaldab laia valikut kontrolle, mis on seotud ka kehva autentimisega. Staatilise analüüsi tööriist hõlmab nii üldiste probleemide (nt mandaadi leke) kui ka API-spetsiifiliste probleemide (nt puuduvad kaitsenõuded JWT tokenites või JWT päistes esinevad nõuded) tuvastamist.
API3:2023 – Katkise objekti atribuuditaseme autoriseerimine
Mis see on?
Katkise objekti atribuudi tasemel autoriseerimine on 2023. aasta OWASP-i loendis uus kategooria, mis ühendab kaks eelmise loendi kategooriat: liigne andmete avalikustamine (API3:2019) ja massiline määramine (API6:2019). Probleemi põhjustab kasutaja autoriseerimise valideerimise puudumine – või kasutaja ebaõige autoriseerimine – objekti atribuudi tasandil. API lõpp-punktid peaksid valideerima, et igal kasutajal on autoriseerimine iga atribuudi jaoks, millele nad üritavad juurde pääseda või mida nad üritavad muuta. Probleemi ärakasutamine võib viia teabe avalikustamiseni või andmete manipuleerimiseni volitamata isikute poolt.
Mis teeb rakenduse haavatavaks?
Levinud ja kergesti ärakasutatav probleem ilmneb siis, kui kasutajal võib olla juurdepääs teatud objekti teatud omadustele, näiteks toa broneerimisele reisirakenduses, kuid mitte teistele, näiteks toa hinnale. Kui kasutaja pääseb objekti omadustele juurde API kaudu, peaks rakendus kontrollima, et kasutaja:
· Peaks olema võimalik pääseda ligi objekti konkreetsele omadusele
13 OWASP rakenduse turbekontrolli standard. OWASP. GitHubi leht. Viimati külastatud: 17. november 2023.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
9/23
Katkise objekti atribuuditaseme autoriseerimine on 2023. aasta OWASP-loendi uus kategooria, mis ühendab kaks eelmise loendi kategooriat: liigne andmete paljastamine (API3:2019) ja massiline määramine (API6:2019).
OpenTextTM staatiline rakenduste turvalisuse testimine aitab andmevoo analüüsi abil vältida nii liigset andmete avalikustamist kui ka massilist määramist. Süsteem tõstab esile palju privaatsete andmete allikaid, näiteks muutujate nimedel või konkreetsetel API-kõnedel põhinevaid, ja tuvastab objektid, mis võimaldavad massilist määramist.
(rikkumisi nimetati varem liigseks andmete avalikuks ...
· Lubatud on muuta objekti konkreetset omadust (mõned rakendused ei kontrolli seda, kuna nad kasutavad raamistikku automaatseks kaardistamiseks) web päringuparameetrid objektiväljadele, probleem, mida tuntakse massmääramisena).
OWASP-i eksemplarisampNäiteks veebipõhine videoplatvorm võimaldab kasutajal muuta video kirjeldust, isegi blokeeritud video puhul, kuid ei tohiks lubada kasutajal muuta omadust „blokeeritud”.
PUT /api/video/update_video
{
„kirjeldus”: „naljakas video kassidest”,
„blokeeritud”: vale
}
Rünnake endistamples
2022. aasta jaanuaris avastas veaotsingute programm Twitteris vea, mis võimaldas kasutajal esitada Twitteri süsteemile oma e-posti aadressi või telefoninumbri, mis seejärel tagastas konto nime, millele teave kuulus.14 Tundmatu ründaja kasutas seda viga miljonite kasutajakontode nimekirja koostamiseks, mis olid seotud telefoninumbrite ja e-posti aadressidega. Lubades kõigil kahte omadust linkida, võimaldas Twitter kogemata pseudonüümseid kasutajaid täpsemalt tuvastada.
Kuidas seda arendajana vältida?
Arendajad peaksid alati rakendama korralikke kontrolle konkreetsete objektide omadustele juurdepääsu või nende muutmise võimaluse üle. Selle asemel, et iga omadusega tagastada üldine andmestruktuur – mis sageli juhtub üldiste meetodite, näiteks to_json() ja to_string() puhul –, peaksid programmeerijad olema tagastatava teabe osas väga täpsed. Täiendava turvameetmena peaksid rakendused rakendama skeemipõhist vastuste valideerimist, mis jõustab turvakontrollid kõigile API-meetodite tagastatud andmetele. Juurdepääs peaks järgima minimaalsete õiguste põhimõtet, lubades juurdepääsu ainult absoluutse vajaduse korral.
Kuidas OpenText saab aidata?
OpenTextTM staatiline rakenduste turvalisuse testimine aitab andmevoo analüüsi abil vältida nii liigset andmete avalikustamist kui ka massilist andmete määramist. Süsteem tõstab esile palju privaatsete andmete allikaid, näiteks muutujate nimedel või konkreetsetel API-kõnedel põhinevaid, ja tuvastab objektid, mis võimaldavad massilist andmete määramist. Kasutajad saavad samuti ise allikaid määratleda, jälgides andmeid programmi kaudu ja kui need satuvad sobimatusse kohta, hoiatades arendajat või operaatorit riski eest.
14 Juhtum, mis mõjutas mõningaid Twitteri kontosid ja privaatset teavet. Twitteri privaatsuskeskus. Twitter. Web Lehekülg. 5. august 2022.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
10/23
Rakendused, mis ei piira päringu rahuldamiseks eraldatud ressursse, võivad olla haavatavad, sealhulgas need, mis ei suuda piirata eraldatavat mälu, ressursside arvu filemuude atribuutide hulgas ligipääsetud protsesside arv või lubatud päringute määr.
Lisaks on OpenText SAST-il teadmised kõige olulisematest JSON-i ja XML-i serialiseerimise ja deserialiseerimise mehhanismidest. Selle abil suudab tööriist tuvastada koodi, mis ei deserialiseeri domeeniülekande objekte (DTO-sid) korralikult, mis võib võimaldada nende atribuutide massilist määramist. Mõningaid teabe avalikustamise ja massilise määramise juhtumeid saab tuvastada ka OpenText Dynamic Application Security Testing abil. Lõpuks saab mõningaid vastumeetmeid rakendada reeglite lisamisega... web rakenduse tulemüür (WAF).
API4:2023 – piiramatu ressursikasutus
Mis see on?
API-d pakuvad palju kasulikke ärifunktsioone. Selleks kasutavad nad arvutusressursse, näiteks andmebaasiservereid, või võivad neil olla juurdepääs füüsilisele komponendile operatiivtehnoloogia kaudu. Kuna süsteemidel on API-kõnedele vastamiseks piiratud ressursid, saavad ründajad spetsiaalselt luua päringuid, et luua stsenaariume, mis põhjustavad ressursside ammendumise, teenuse keelamise või ärikulude suurenemise. Paljudel juhtudel saavad ründajad saata API-päringuid, mis seovad märkimisväärseid ressursse, koormates üle masina või ribalaiuse ressursse ja põhjustades teenuse keelamise rünnaku. Saates korduvaid päringuid erinevatelt IP-aadressidelt või pilveinstansse, saavad ründajad mööda hiilida kaitsemehhanismidest, mis on loodud kahtlaste kasutusnähtude tuvastamiseks.
Mis teeb rakenduse haavatavaks?
API-päringud käivitavad vastuseid. Olenemata sellest, kas need vastused hõlmavad andmebaasile juurdepääsu, sisend-/väljundtoimingute tegemist, arvutuste käivitamist või (üha enam) masinõppemudeli väljundi genereerimist, kasutavad API-d arvutus-, võrgu- ja mäluressursse. Ründaja saab API-päringuid lõpp-punkti saata teenusetõkestusrünnaku (DoS-rünnaku) osana, mis ribalaiuse ülekoormamise asemel – mis on mahulise DoS-rünnaku eesmärk – kurnab hoopis protsessori, mälu ja pilveressursse. Rakendused, mis ei piira päringu rahuldamiseks määratud ressursse, võivad olla haavatavad, sealhulgas need, mis ei suuda piirata eraldatavat mälu ega ressursside arvu. filemuude atribuutide hulgas ligipääsetud protsesside arv või lubatud päringute määr.
Serveri töötlemise API-del peavad olema piirangud, et vältida mälu ja töökoormuste liigset eraldamist, API-käivitatud toimingute liigseid taotlusi või liigseid tasusid kolmanda osapoole teenuse eest ilma kulupiiranguteta.
Levinud rünnak on API lõpp-punktile edastatud argumentide muutmine, näiteks vastuse suuruse suurendamine ja miljonite andmebaasikirjete taotlemine, mitte näiteks esimese kümne:
/api/kasutajad?page=1&size=1000000
Lisaks, kui ründajal on juurdepääs taustteenusele, mis võtab kasutamise eest tasu, saab ressursitarbimise rünnakuid kasutada rakenduse omanikule tasude tekitamiseks. Teine OWASP-i näideample viitab parooli lähtestamise funktsioonile, mis kasutab isiku tuvastamiseks SMS-sõnumit ja millele võidakse ohvri kulude suurendamiseks tuhandeid kordi helistada.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
11/23
Filtreerimine võrgu servas, kasutades sisuedastusvõrke (CDN-e), mis on paaristatud web Rakenduste tulemüürid (WAF-id) võivad vähendada liiklusummutusi, minimeerides samal ajal mõju üksikutele kasutajatele.
POST /sms/saatmine _ lähtestamine _ parool _ kood
Host: willyo.net {
„telefoninumber”: „6501113434” }
Rünnake endistamples
Kuna ressursitarbimise rünnakuid seostatakse sageli jõudluse ja kättesaadavuse probleemidega, kipuvad sihikule võetud ettevõtted neid käsitlema pigem äritegevuse kulude osana kui intsidentidena, millest tuleb teatada, vähendades seeläbi ohu nähtavust. 2022. aastal vähenes rakenduskihi hajutatud teenusetõkestamise (DDoS) rünnakute, mis on API ressursitarbimise rünnakute superrühm, osakaal kõigist rünnakutest, kuid 4. aasta 2022. kvartalis registreeriti siiski 79% rohkem rünnakuid kui eelmise aasta samal kvartalil.15
Ühes 2015. aastal kirjeldatud rünnakus tuvastas arendaja Androidi kliendi, mis võttis korduvalt ühendust tema saidi Web API juhuslikult genereeritud API-võtmetega, mille tulemuseks oli teenusetõkestusrünnak. Arendaja oletas, et Android-seadmetesse installitud pahatahtlik rakendus üritas 64-bitist API-võtit ära arvata.16
Kuidas seda arendajana vältida?
Kiiruspiirangute ja lävede abil saab enamikku ressursitarbimise rünnakuid ohjeldada, kuigi halvasti üles ehitatud kaitsemeetmed võivad mõjutada ka seaduslikku liiklust. Konkreetsed piirangud tuleks kehtestada järgmistele meetmetele:
· Mälu eraldamine
· Protsessid
· Pilveinstanssid
· Üles laaditud file kirjeldused ja file suurus
· Tagastatud kirjed
· Kolmandate osapoolte teenustega tehtud tasuliste tehingute arv
· Kõik sissetulevad parameetrid (nt stringi pikkused, massiivi pikkused jne)
· API interaktsioonide arv kliendi kohta kindla ajaintervallis
Filtreerimine võrgu servas, kasutades sisuedastusvõrke (CDN-e), mis on paaristatud web Rakenduste tulemüürid (WAF-id) võivad vähendada liiklusummutusi, minimeerides samal ajal mõju üksikutele kasutajatele. Rakenduste edastusplatvormid võimaldavad hõlpsat filtreerimist, sealhulgas mälu, protsessorite ja protsesside piiranguid.
15 Yoachimik, Omer. Cloudflare'i DDoS-i ohu aruanne 2022. aasta 4. kvartali kohta. Cloudflare'i ajaveeb. Web Lehekülg. 10. jaanuar 2023.
16 Kuidas peatada häkkimis-/DOS-rünnakut web API. StackOverflow. Web Lehekülg. 15. september 2015.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
12/23
OpenText Dynamic Application Security Testing suudab testida serverite ja API funktsioonide haavatavust teenusetõkestamise rünnaku suhtes ilma teenust mõjutamata. Lisaks saab DAST-skannimise käivitamine keskkonda piisavalt stressitestida, et näidata potentsiaalseid ressursitarbimise nõrkusi.
Kuidas OpenText saab aidata?
OpenText SAST-i ja OpenText Dynamic Application Security Testingu abil saavad DevSecOpsi meeskonnad testida oma koodi ja infrastruktuuri vastupidavust ressursside ammendumise rünnakutele. OpenText SAST suudab tuvastada paljusid piirkondi, kus ründaja saaks rakenduse loogikat kuritarvitada, et tekitada äärmuslikku ressursitarbimist.
Kooditaseme turvalisusest ei piisa selle probleemi lahendamiseks rakenduses. Ressursside ammendumine ja kiiruse piiramine on teenusetõkestusrünnakute spetsiifilised alamsegmendid, mida tuleks käitusajal leevendada. OpenText Dynamic Application Security Testing saab testida servereid ja API funktsioone teenusetõkestusrünnakute haavatavuse suhtes ilma teenust mõjutamata. Lisaks saab DAST-skannimise käivitamine keskkonda piisavalt stressitestida, et näidata potentsiaalseid ressursitarbimise nõrkusi.
API5:2023 – Katkine funktsioonitaseme autoriseerimine
Mis see on?
Kaasaegsel rakendusel on palju erinevaid funktsioone, mis pääsevad ligi andmetele, loovad, töötlevad, kustutavad ja haldavad neid. Mitte iga rakenduse kasutaja ei vaja juurdepääsu igale funktsioonile ega kõigile andmetele ega tohiks seda lubada ka vähimate õiguste põhimõtte alusel. Igal API lõpp-punktil on sihtrühm, mis võib hõlmata anonüümseid, tavalisi mitte-privilegeeritud ja privilegeeritud kasutajaid. Administratiivsed ja haldusfunktsioonid peaksid nõudma privilegeeritud autoriseerimist, kuid neile pääseb mõnikord ligi volitamata kasutajate õigustatud API-kõnede kaudu – see on katkise funktsioonitaseme autoriseerimise algus. Kuna erinevad hierarhiad, rühmad ja rollid loovad juurdepääsukontrollis keerukust, ei pruugi rakenduse funktsioonidel olla sobivaid piiranguid selle kohta, kes neid kutsuda võib.
Mis teeb rakenduse haavatavaks?
Rakendused, mis lubavad teatud funktsioonidel administratiivseid ülesandeid täita, ei pruugi neile funktsioonidele juurdepääsu turvalisel viisil piirata. API-d, mis on otseselt selliste funktsioonidega seotud, avavad need nõrkused ärakasutamisele. Funktsioone, mis ei kasuta rakenduse autentimis- ja autoriseerimismehhanismi, tuleks pidada potentsiaalseteks turvanõrkusteks.
EksisampOWASP-i viidatud näites saab ründaja juurdepääsu API-päringutele kutsutud kasutaja lisamiseks uude mobiilirakendusse, märkides, et kutse sisaldab teavet kutsutava rolli kohta. Nõrkust ära kasutades saadab ründaja uue kutse:
POST /api/kutsed/uus
{
„e-post”: „ründaja@somehost.com”,
„roll”: „administraator”
} See võimaldab neil süsteemis administraatoriõigused saada.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
13/23
DevSecOpsi meeskonnad peaksid välja töötama standardse lähenemisviisi autoriseerimisele ja autentimisele, mis vaikimisi keelab juurdepääsu päringutele, jõustades vaikesätte „keela kõik“.
Rakenduste kontroll ja loogikavood on iga veebiettevõtte süda ning kuna ettevõtted kolivad üha rohkem oma tegevust pilve, võivad need vood ohtu sattuda ja neid ära kasutada. See liigne juurdepääs võib ettevõtet kahjustada.
Rünnake endistamples
2022. aastal teatas Texase kindlustusministeerium avalikkust, et ligi kahe miljoni teksaslase andmed olid avalikustatud töötajate hüvitiste taotluse osa kaudu, mis võimaldas kogemata üldsuse liikmetel juurde pääseda kaitstud andmetele.17 Teises intsidendis 2022. aastal tunnistas Austraalia telekommunikatsioonifirma Optus, et API, mis ei vajanud autentimist ega autoriseerimist, oli avalikustatud kuni 10 miljoni austraallase isiku- ja kontoandmeid. Kuigi Optus nimetas rünnakut „keerukaks“, kirjeldas rünnaku üksikasjadega tuttav turvauurija seda „tühiseks“.18
Kuidas seda arendajana vältida?
DevSecOpsi meeskonnad peaksid kujundama standardse lähenemisviisi autentimisele ja autoriseerimisele, mis vaikimisi takistab juurdepääsu päringutele, jõustades vaikesätte „keela kõik“. Sellest vaikesättest lähtuvalt tuleks rollide/rühmade/kasutajate juurdepääsu määramisel alati rakendada vähimate õiguste põhimõtet. Arendajad peaksid tagama, et autentimine ja autoriseerimine oleksid olemas kõigi asjakohaste HTTP-verbide/meetodite (nt POST, GET, PUT, PATCH, DELETE) jaoks, mis on seotud iga API lõpp-punktiga. Ebaolulised verbid tuleks keelata. Lisaks peaksid arendajad rakendama administratiivse juurdepääsu ja halduse baasklassi, kasutades klassi pärimist, et tagada autoriseerimiskontrollide kontrollimine enne juurdepääsu andmist kasutaja rolli. Kõik kriitilised administratiivsed funktsioonid peaksid õiguste eskaleerimise vältimiseks kasutama autoriseerimismehhanismi.
Kuidas OpenText saab aidata?
Kombineerides OpenText™ Static Application Security Testingu staatilise koodi ja API analüüsi funktsioonid OpenText Dynamic Application Security Testingu (DAST) komplekti käitusaja kontrollidega, saavad DevSecOpsi meeskonnad hinnata oma rakendust vigaste funktsionaalse taseme autoriseerimisprobleemide suhtes ja testida pidevalt tootmiskoodi turvanõrkuste suhtes enne juurutamist. Vigaste objektide funktsioonide autoriseerimisprobleemide tuvastamiseks kasutab OpenText™ Static Application Security Testing reegleid, mis määravad, millal teatud programmeerimiskeeltes ja raamistikes oodatakse autoriseerimiskontrolli ning millal sellise kontrolli puudumine teatatakse.
API6:2023 – piiramatu juurdepääs tundlikele ärivoogudele
Mis see on?
Alates tossurobotidest kuni piletirobotiteni on veebipoodide inventari ründamine API-de kaudu muutunud e-kaubanduse saitide jaoks oluliseks probleemiks. Ärimudeli ja rakenduse loogika mõistmise abil saab ründaja luua API-kõnede seeria, mis võimaldab automaatselt broneerida või osta.
17 Beeferman, Jason. Auditi kohaselt olid 1.8 miljoni teksaslase isikuandmed, kellel olid kindlustusministeeriumi kahjunõuded, aastaid avalikustatud. The Texas Tribune. 17. mai 2022.
18 Taylor, Josh. Optuse andmeleke: kõik, mida me seni juhtunu kohta teame. The Guardian. 28. september 2022.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
14/23
Tundlikele ärivoogudele piiramatu juurdepääsu takistamine seisneb pigem terviklikus rakenduste turvalisuse lähenemisviisis kui konkreetse tehnoloogia leidmises.
inventuuri, takistades seeläbi teistel, õigustatud tarbijatel juurdepääsu ettevõtete toodetele või teenustele. Ründaja saab kasutada iga äriprotsessile juurdepääsu võimaldavat API-t ettevõtte mõjutamiseks ja see kuulub tundlikele ärivoogudele piiramatu juurdepääsu määratluse alla.
Mis teeb rakenduse haavatavaks?
Rakenduste kontroll ja loogikavood on iga veebiettevõtte süda ning kuna ettevõtted kolivad üha rohkem oma tegevust pilve, võivad need vood sattuda ohtu ja neid ära kasutada. See liigne juurdepääs võib ettevõttele kahju tekitada, kui ründajad automatiseerivad toodete ostmist, loovad kommentaaride jätmiseks roboteid ja levitavad...viewvõi automatiseerida kaupade või teenuste reserveerimist.
Kui rakendus pakub lõpp-punkti, millel on juurdepääs ettevõtte ärivoogudele, piiramata juurdepääsu lõpp-punkti taga toimuvatele äritoimingutele, on rakendus haavatav. Kaitsemeetmete hulka kuuluvad juurdepääsukatsete arvu piiramine ühest seadmest sõrmejälgede võtmise abil, tegevuse algatamise tuvastamine inimeselt ja automatiseerimise kaasamise tuvastamine.
Rünnake endistamples
Kui Taylor Swifti piletid Ticketmasteris 2022. aasta novembris müügile tulid, oli 1.5 miljonit klienti eelregistreerunud, kuid üle 14 miljoni päringu – sealhulgas kolm korda rohkem bottide liiklust –...ampmuutis ostulingid ja API-d kohe, kui piletimüük algas. Sait jooksis kokku, takistades paljudel klientidel piletite ostmist.19
Edasimüüjate robotite rünnak meenutas neid, mis rikkusid PlayStation 5 turuletoomise 2020. aasta novembris. Tarneahela probleemid piirasid pakkumist juba enne uusima Sony mängukonsooli turuletoomist, kuid automatiseeritud robotid muutsid saadaolevate seadmete leidmise veelgi raskemaks ja viisid astronoomiliste edasimüügihindadeni. Ühe e-kaubanduse saidi puhul kasvas „lisa ostukorvi” tehingute arv keskmiselt 15,000 27 päringult tunnis enam kui 20 miljonini, kasutades poe API-t toodete otseseks taotlemiseks SKU numbri järgi.XNUMX
Kuidas seda arendajana vältida?
Arendajad peaksid tegema koostööd nii ärioperatsioonide kui ka insenerimeeskondadega, et lahendada ärivoogudele võimaliku pahatahtliku juurdepääsu probleeme. Ärimeeskonnad saavad tuvastada, millised vood on API-de kaudu nähtavad, ja teha ohuanalüüse, et teha kindlaks, kuidas ründajad saaksid neid lõpp-punkte kuritarvitada. Samal ajal peaksid arendajad DevOps meeskonna osana tegema koostööd insenerioperatsioonidega, et luua täiendavaid tehnilisi kaitsemeetmeid, näiteks seadme sõrmejälgede kasutamine automatiseeritud brauseri eksemplaride ülekoormuse vältimiseks ja käitumismustrite tuvastamine, mis eristavad inimeste ja masinate toimijaid.
19 Steele, Billy. Ticketmaster teab, et neil on botiprobleem, aga tahab, et Kongress selle lahendaks. Engadget. Uudisartikkel. 24. jaanuar 2023.
20 Muwandi, Tafara ja Warburton, David. Kuidas botid rikkusid PlayStation 5 turuletoomise miljonite mängijate jaoks. F5 Labsi ajaveeb. F5. Web Lehekülg. 18. märts 2023.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
15/23
Kõige tuntum eksampSSRF-i rünnaku üks juhtum hõlmas endist Amazoni töötajat Web Teenuste (AWS) insener, kes kasutas ära valesti konfigureeritud web rakenduse tulemüüri (WAF), et seejärel kasutada SSRF-i viga andmete kogumiseks finantsgigandi Capital One'i serveri eksemplarist.
Operatsioonide meeskonnad peaksid samuti uuesti läbi vaatamaview kõik API-d, mis on loodud kasutamiseks teiste masinate poolt, näiteks B2B kasutusjuhtudel, ning tagama, et on olemas teatud kaitsemeetmed, mis takistavad ründajatel masinatevahelist interaktsiooni ärakasutamist.
Kuidas OpenText saab aidata?
Haavatavate ja tundlike ärivoogude tabamine sõltub sageli põhitõdede tegemisest. Ettevõtted peavad dokumenteerima ja jälgima kõiki oma toimivaid API-sid ning kindlaks tegema, millised neist paljastavad tundlikke protsesse ja andmeid potentsiaalsetele ründajatele. Rakendusloogikat tuleb analüüsida ka loogikavigade suhtes, mida ründajad saaksid ära kasutada.
Üldiselt seisneb tundlikele ärivoogudele piiramatu juurdepääsu takistamine pigem terviklikus rakenduste turvalisuse lähenemisviisis kui konkreetse tehnoloogia leidmises.
API7:2023 – Serveripoolse päringu võltsimine
Mis see on?
Tagaserverid töötlevad API-lõpp-punktide kaudu tehtud päringuid. Serveripoolne päringute võltsimine (SSRF) on haavatavus, mis võimaldab ründajal panna serveri saatma päringuid enda nimel ja serveri õigustega. Sageli kasutab rünnak serverit välise ründaja ja sisevõrgu vahelise lõhe ületamiseks. Põhilised SSRF-rünnakud toovad kaasa vastuse saatmise ründajale, mis on palju lihtsam stsenaarium kui pimedad SSRF-rünnakud, kus vastust ei tagastata, jättes ründajale kinnituse rünnaku edukuse kohta.
Mis teeb rakenduse haavatavaks?
Serveripoolse päringute võltsimise (SSRF) vead tulenevad sisuliselt kasutaja sisestatud sisendi valideerimise puudumisest. Ründajad suudavad luua päringuid ja lisada URI, mis annab juurdepääsu sihtrakendusele.
Rakenduste arendamise kaasaegsed kontseptsioonid, näiteks webOWASP-i andmetel muudavad konksud ja standardiseeritud rakendusraamistikud SSRF-i levinumaks ja ohtlikumaks.
EksisampOWASP-i tsiteeritud näide on sotsiaalvõrgustik, mis võimaldab kasutajatel üles laadida videoid.file pildid võivad olla SSRF-i suhtes haavatavad, kui server ei valideeri rakendusele saadetud argumente. Selle asemel, et URL osutades pildile, näiteks:
POST /api/profile/laadi üles _ pilt
{
„pilt _ url”: „http://example.com/profile _ pilt.jpg”
}
Ründaja saab saata URI, mis suudab kindlaks teha, kas konkreetne port on avatud, kasutades järgmist API-kõnet:
{ „pilt _ url„: „kohalikhost:8080”
}
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
16/23
Turvalisuse valekonfiguratsioon hõlmab rakenduste seadistamist haavatavate vaikekonfiguratsioonidega, liiga lubava juurdepääsu lubamist tundlikele funktsioonidele ja andmetele ning rakenduse teabe avalikustamist üksikasjalike veateadete kaudu.
Isegi pimeda SSRF-i juhul suudab ründaja vastuse saamiseks kuluvat aega mõõtes kindlaks teha, kas port on avatud.
Rünnake endistamples
Kõige tuntum eksampSSRF-i rünnaku üks juhtum hõlmas endist Amazoni töötajat Web Teenuste (AWS) insener, kes kasutas ära valesti konfigureeritud web rakenduse tulemüüri (WAF), et seejärel kasutada SSRF-i viga andmete kogumiseks finantsgigandi Capital One'i serveri eksemplarist. 2019. aasta juulis toimunud intsidendi tulemusel varastati ligikaudu 100 miljoni USA kodaniku ja kuue miljoni Kanada kodaniku andmed.21 Amazon peab kompromiteerimise allikaks pigem vale konfiguratsiooni kui SSRF-i viga.22
2022. aasta oktoobris teavitas pilveturbefirma Microsofti neljast SSRF-i haavatavusest ettevõtte lipulaeval Azure'i pilveplatvormil. Iga haavatavus mõjutas erinevat Azure'i teenust, sealhulgas Azure'i masinõppe teenust ja Azure'i API haldusteenust.23
Kuidas seda arendajana vältida?
Arendajad peaksid oma koodi kapseldama ressursside hankimise mehhanismid, isoleerides funktsiooni ja lisades kihilisuskaitse, et kontrollida kõiki päringuid. Kuna selliseid funktsioone kasutatakse tavaliselt kaugressursside, mitte sisemiste ressursside hankimiseks, peaksid arendajad konfigureerima kapseldatud funktsioonid nii, et need kasutaksid lubatud kaugressursside loendit ja blokeeriksid sisemistele ressurssidele juurdepääsu katsed. HTTP-suunamine tuleks ressursside hankimise funktsioonide ja kõigi pahatahtliku koodi suhtes parsitud päringute jaoks keelata.
SSRF-i nõrkuste riski ei saa alati täielikult välistada, seega peaksid ettevõtted hoolikalt kaaluma väliste ressursside poole pöördumise riski.
Kuidas OpenText saab aidata?
OpenText Dynamic Application Security Testing võimaldab DevSecOpsi meeskondadel regulaarselt testida serveripoolsete päringute võltsimist. OpenTextTM Dynamic Application Security Testing skannib rakendusserverit konfigureeritud keskkonnas, et kõiki komponente – rakendust, serverit ja võrku – saaks testida, andes dünaamilise analüüsi platvormile põhjaliku ülevaate. view serveripäringute mõjust.
OpenText SAST suudab tuvastada paljusid SSRF-i juhtumeid saasteainete analüüsi abil – näiteksampnäiteks kui rakendus kasutab valideerimata kasutaja sisendit a loomiseks URL mis seejärel tuuakse. Tööriist annab märku piiramatu kasutaja sisendi kasutamisest.
21 Teave Capital One'i küberintsidendi kohta. Capitol One'i nõuanne. Web Lehekülg. Uuendatud 22. aprillil 2022.
22 Ng, Alfred. Amazon ütleb senaatoritele, et nad ei ole Capital One'i rikkumises süüdi. CNET News.com. Uudisteartikkel. 21. november 2019.
23 Shitrit, Lidor Ben. Kuidas Orca leidis neljas erinevas Azure'i teenuses serveripoolse päringute võltsimise (SSRF) haavatavusi. Orca turvablogi. Web Lehekülg. 17. jaanuar 2023.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
17/23
Koodipõhine turvalisus aitab, muutes konfiguratsioonid korratavaks ja andes rakenduste turvalisuse meeskondadele võimaluse määrata konkreetsete rakenduse komponentide jaoks standardsed konfiguratsioonikomplektid.
API8:2023 – Turvalisuse valekonfiguratsioon
Mis see on?
Arendajad konfigureerivad oma rakendusi sageli valesti, jättes arendusvarad tootmisvaradest eraldamata ja eksportides tundlikke andmeid. files–selline konfiguratsioon files–oma avalikesse andmehoidlatesse ja vaikeseadete muutmata jätmine. Turvalisuse valekonfiguratsioon hõlmab rakenduste seadistamist haavatavate vaikeseadetega, liiga lubava juurdepääsu lubamist tundlikele funktsioonidele ja andmetele ning rakenduse teabe avalikustamist üksikasjalike veateadete kaudu.
Mis teeb rakenduse haavatavaks?
Rakenduste vaikekonfiguratsioonid on sageli liiga leebe iseloomuga, neil puudub turvalisuse tugevdamine ja nad jätavad pilvesalvestuse eksemplarid avalikkusele avatuks. Tihtilugu... web Rakenduste aluseks olevad raamistikud sisaldavad hulgaliselt rakenduse funktsioone, mida pole vaja ja mille lisamine vähendab turvalisust.
EksisampOWASP-i poolt üksikasjalikult kirjeldatud sotsiaalvõrgustik, mis pakub otsesõnumite saatmise funktsiooni, peaks kaitsma kasutajate privaatsust, kuid pakub API-päringut konkreetse vestluse hankimiseks, kasutades järgmist näidetampAPI päring:
GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA
API lõpp-punkt ei piira vahemällu salvestatud andmeid, mille tulemusel salvestab server privaatsed vestlused vahemällu. web brauser. Ründajad said brauserist teabe kätte, paljastades ohvri privaatsõnumid.
Rünnake endistamples
2021. aasta mais teatas pilveturbefirma Microsoftile, et vähemalt 47 erinevat klienti ei olnud suutnud oma Microsoft Power Appsi eksemplaride vaikekonfiguratsiooni muuta. Mõjutatud organisatsioonide hulgas olid ettevõtted, näiteks American Airlines ja Microsoft, ning osariikide valitsused, näiteks Indiana ja Marylandi osariigi omad, ning Power Appsi portaalides oli 38 miljonit kirjet potentsiaalselt ohustatud.24
2022. aastal avastas haavatavuste haldamise ettevõte, et Amazonis majutati 12,000 XNUMX pilveinstansi Web 10,500. aasta aruande kohaselt paljastasid Azure'is majutatud teenused ja 2022 25 jätkuvalt Telneti ohtu – kaugjuurdepääsuprotokolli, mida peetakse tänapäeval igasuguse internetipõhise kasutuse jaoks sobimatuks.XNUMX Ebavajalike ja ebaturvaliste funktsioonide kaasamine õõnestab API-de ja rakenduste turvalisust.
24 Upguardi uuring. Kavandatud lahendus: kuidas Microsoft Power Appsi vaikeõigused paljastasid miljoneid. Upgardi uuringute ajaveeb. Web Lehekülg. 23. august 2021.
25 Beardsley, Todd. 2022. aasta pilveteenuste valekonfiguratsioonide aruanne. Rapid7. PDF-aruanne. lk 12. 20. apr 2022.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
18/23
Dokumentatsiooni pimeala on olukord, kus API eesmärgi, toimimise ja versioonimise üksikasjad on ebaselged, kuna puudub dokumentatsioon, mis neid olulisi atribuute üksikasjalikult kirjeldaks.
Kuidas seda arendaja poolt ära hoida?
DevSecOpsi meeskonnad peavad mõistma samme, mis on vajalikud oma rakenduste jaoks turvaliste konfiguratsioonide loomiseks ja konfiguratsiooni kontrollimiseks automatiseeritud arendusprotsessi kasutamiseks. fileenne juurutamist, sh regulaarsed ühiktestid ja käitusaja kontrollid, et pidevalt kontrollida tarkvara konfiguratsioonivigade või turvaprobleemide suhtes. Turvalisus koodina aitab, muutes konfiguratsioonid korratavaks ja andes rakenduse turvalisuse meeskondadele võimaluse määrata konkreetsete rakenduse komponentide jaoks standardsed konfiguratsioonikomplektid.
Oma turvalise arendustsükli osana peaksid arendajad ja operatsioonimeeskonnad:
· Luua karastamisprotsess, mis lihtsustab turvalise rakenduskeskkonna korduvat loomist ja hooldamist,
· Review ja värskendage kõiki API-virna konfiguratsioone, et uus standard järjepidevalt kaasataks, ning
· Automatiseerida konfiguratsiooniseadete tõhususe hindamist kõigis keskkondades.
Kuidas OpenText saab aidata?
OpenTexti staatilise rakenduse turvatestimise abil saab kontrollida konfiguratsioone arendusprotsessi ajal ja tuvastada mitut tüüpi nõrkusi. Kuna turvakonfiguratsiooni vead esinevad nii rakenduskoodi kui ka infrastruktuuri tasandil, saab valekonfiguratsioonide tuvastamiseks kasutada erinevaid OpenTexti tooteid.
OpenTexti staatilise rakenduse turvatesti skaneeringud saavad kontrollida rakenduse koodi valesti konfigureerimise probleemide suhtes. Staatilise analüüsi kontrolli käigus saab OpenTexti SAST hinnata konfiguratsiooni. fileturvavigade, sh Dockeri, Kubernetese, Ansible'i ja Amazoni vigade puhul Web Teenused, CloudFormation, Terraform ja Azure Resource Manageri mallid.
Konfiguratsioonivigu saab tuvastada ka käitusaja jooksul. OpenText Dynamic Application Security Testing võimaldab DevSecOps meeskondadel regulaarselt testida levinud turvakonfiguratsioonide vigu. DAST-skannimise üks suurimaid tugevusi on see, et see töötab rakendusserveris konfigureeritud keskkonnas, mis tähendab, et kogu keskkonda – rakendust, serverit ja võrku – testitakse korraga, andes dünaamilise analüüsi platvormile põhjaliku ülevaate. view tootmiskeskkonnast on konfigureeritud.
API9:2023 – Ebaõige varude haldamine
Mis see on?
Nagu enamikul tarkvaravaradel, on ka API-del elutsükkel, kus vanemad versioonid asendatakse turvalisemate ja tõhusamate API-dega või kasutatakse üha enam kolmandate osapoolte teenustega ühendatud API-sid. DevSecOps meeskonnad, kes ei halda oma API versioone ja dokumentatsiooni, võivad tekitada haavatavusi, kui vanemaid ja vigaseid API versioone jätkuvalt kasutatakse – seda nõrkust tuntakse ebaõige varude haldamisena. Varude haldamise parimad tavad nõuavad jälgimist
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
19/23
API versioonid, integreeritud teenuste regulaarne hindamine ja inventuur ning pärandversioonide regulaarne aegumine turvanõrkuste leviku vältimiseks.
Mis teeb rakenduse haavatavaks?
API-dest sõltuvad tarkvaraarhitektuurid – eriti need, mis kasutavad mikroteenuste arhitektuure – kipuvad pakkuma rohkem lõpp-punkte kui traditsioonilised web rakendused. API lõpp-punktide rohkus koos tõenäosusega, et API-st eksisteerib samaaegselt mitu versiooni, nõuab API pakkujalt täiendavaid haldusressursse, et vältida rünnakupinna laienemist. OWASP tuvastab kaks peamist pimeala, mis DevSecOps meeskondadel oma API infrastruktuuri osas võivad olla.
Esiteks on dokumentatsiooni pimeala see, kui API eesmärgi, toimimise ja versioonimise üksikasjad on ebaselged, kuna puudub dokumentatsioon, mis neid olulisi atribuute üksikasjalikult kirjeldaks.
Teiseks tekib andmevoo pimeala siis, kui API-sid kasutatakse ebaselgelt, mille tulemuseks on võimalused, mida ei tohiks tingimata lubada ilma tugeva ärilise põhjenduseta. Tundlike andmete jagamine kolmanda osapoolega ilma turvagarantiideta, andmevoo lõpptulemuse nähtavuse puudumine ja kõigi andmevoogude kaardistamata jätmine aheldatud API-des on kõik pimealad.
Nagu endineampNäiteks OWASP-i aruandes viidatakse väljamõeldud sotsiaalvõrgustikule, mis võimaldab integratsiooni kolmandate osapoolte sõltumatute rakendustega. Kuigi lõppkasutaja nõusolek on vajalik, ei säilita sotsiaalvõrgustik andmevoo suhtes piisavat nähtavust, et takistada allavoolu osapooltel andmetele juurdepääsu, näiteks mitte ainult kasutaja, vaid ka tema sõprade tegevuse jälgimist.
Rünnake endistamples
Aastatel 2013 ja 2014 osales Facebooki platvormil veebipõhises psühholoogilises viktoriini koguni 300,000 87 inimest. Viktoriini taga olev ettevõte Cambridge Analytica kogus teavet mitte ainult nende kasutajate, vaid ka nende lingitud sõprade kohta – kokku oli see koguni XNUMX miljonit inimest, kellest valdav enamus ei andnud oma andmete kogumiseks luba. Seejärel kasutas ettevõte teavet oma klientide nimel reklaamide ja sõnumite kohandamiseks neile inimestele, sealhulgas Trumpi valimiskampaaniat toetavate poliitiliste reklaamide saatmiseks.amp2016. aasta valimistel.26 Facebooki vähene nähtavus selle kohta, kuidas kolmandad osapooled tema platvormilt kogutud teavet kasutasid, on näideampEbaõige varude haldamise näide.
Kuidas seda arendajana vältida?
DevSecOpsi meeskonnad peaksid dokumenteerima kõik API hostid ja keskenduma API-de ja kolmandate osapoolte teenuste vaheliste andmevoogude nähtavuse säilitamisele. Peamine viis ebaõige varude haldamise vältimiseks on kõigi API teenuste ja hostide kriitiliste aspektide üksikasjalik dokumenteerimine, sealhulgas teave selle kohta, milliseid andmeid nad töötlevad, kellel on juurdepääs hostidele ja andmetele.
26 Rosenberg, Matthew ja Dance, Gabriel. „Sina oled toode”: Cambridge Analytica sihikule võetud Facebookis. The New York Times. Uudisartikkel. 8. aprill 2018.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
20/23
Organisatsioonid saavad oma API kasutamist hallata, jälgida, turvata ja dokumenteerida OpenTexti OpenText Secure API Manageri abil, mis võimaldab rakenduste turvalisuse meeskondadel hallata API varade ajakohast inventuuri.
ja iga hosti konkreetsed API versioonid. Dokumenteerida tuleks sellised tehnilised üksikasjad nagu autentimise rakendamine, veakäsitlus, kiirusepiirangu kaitsemeetmed, päritoluriikidevahelise ressursside jagamise (CORS) poliitika ja iga lõpp-punkti üksikasjad.
Märkimisväärset dokumentatsioonimahtu on keeruline käsitsi hallata, seega on soovitatav dokumentatsiooni genereerimine pideva integratsiooniprotsessi kaudu ja avatud standardite kasutamine. Juurdepääs API dokumentatsioonile peaks olema piiratud ka nende arendajatega, kellel on API kasutamiseks luba.
Rakenduse loomise ja testimise etappides peaksid arendajad vältima tootmisandmete kasutamist arendus- või tarkvaraarenduse ajal.tagrakenduse uuendatud versioone, et vältida andmelekkeid. Kui API-de uued versioonid avaldatakse, peaks DevSecOpsi meeskond tegema riskianalüüsi, et määrata kindlaks parim lähenemisviis rakenduste täiendamiseks, et neid täiustada.tagsuurenenud turvalisuse tõttu.
Kuidas OpenText saab aidata?
Organisatsioonid saavad oma API kasutamist hallata, jälgida, turvata ja dokumenteerida OpenTextTM Secure API Manageri abil, mis võimaldab rakenduste turvalisuse meeskondadel hallata API varade ajakohast inventuuri. OpenText Secure API Manager pakub autoriteetset hoidlat, kus teie DevSecOps meeskond saab salvestada ja hallata kõiki organisatsiooni poolt kasutatavaid API-sid, võimaldades hõlpsat elutsükli haldamist API arendamisest kuni pensionile jäämiseni. Tarkvara aitab parandada eeskirjade ja litsentsimise järgimist, võimaldades üksikasjalikku analüüsi.
API10:2023 – API-de ohtlik kasutamine
Mis see on?
Rakenduste loomisel natiivse pilveinfrastruktuuri üha suureneva kasutamise tõttu on API-dest saanud rakenduse komponentide vahelise integratsiooni punkt. API-de kaudu ligipääsetavate kolmandate osapoolte teenuste turvaseisund on aga harva selge, mis võimaldab ründajatel kindlaks teha, millistele teenustele rakendus tugineb ja kas mõnel neist teenustest on turvanõrkusi. Arendajad kipuvad usaldama lõpp-punkte, millega nende rakendus suhtleb, ilma väliseid või kolmandate osapoolte API-sid kontrollimata. See API-de ohtlik tarbimine viib sageli rakenduse sõltuvuseni teenustest, millel on nõrgemad turvanõuded või millel puudub põhiline turvalisuse tugevdamine, näiteks sisendi valideerimine.
Mis teeb rakenduse haavatavaks?
Arendajad kipuvad kolmandate osapoolte API-delt saadud andmeid usaldama rohkem kui kasutaja sisendit, kuigi motiveeritud ründaja jaoks on need kaks allikat sisuliselt samaväärsed. Selle valesti suunatud usalduse tõttu loodavad arendajad sisuliselt nõrgematele turvastandarditele sisendi valideerimise ja puhastamise puudumise tõttu.
API-de ohtlik tarbimine võib esineda järgmistel juhtudel:
· Kasutab või tarbib teisi API-sid krüpteerimata side abil,
· Teistelt API-delt või teenustelt saadud andmete valideerimine ja puhastamine ebaõnnestub.
· Lubab ümbersuunamist ilma turvakontrollideta või
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
21/23
Kui arendaja ei kodeeri oma rakendusse turvakontrolle API lõpp-punkti tagastatud andmete kontrollimiseks, järgib nende rakendus ümbersuunamist ja saadab ründajale tundlikku meditsiinilist teavet.
OWASP API turvalisuse top 10 on ülioluline pilvepõhiste arendajate jaoks, kes loovad API-sid. Siiski peaks prioriteediks olema levinud rakenduste haavatavuste, näiteks SQL-süstimise, andmete paljastamise ja turvalisuse valekonfiguratsiooni lahendamine, kuna küberohud kasutavad neid sageli ära. API turvalisuse top 10 on turvalise tarkvaraarenduse oluline osa, kuid see peaks olema üldisemate rakenduste haavatavuste lahendamise kõrval teisejärguline.
· Ressursside tarbimise piiramine läviväärtuste ja ajalõpude abil ebaõnnestub.
EksisampOWASP-i aruande kohaselt võib API, mis integreerub kolmanda osapoole teenusepakkujaga tundliku kasutaja meditsiinilise teabe salvestamiseks, saata privaatseid andmeid API lõpp-punkti kaudu. Ründajad võivad kolmanda osapoole API hosti ohtu seada, et see vastaks tulevastele päringutele 308 püsiva ümbersuunamisega: HTTP/1.1 308 püsiv ümbersuunamine
Asukoht: https://attacker.com/
Kui arendaja ei kodeeri oma rakendusse turvakontrolle API lõpp-punkti tagastatud andmete kontrollimiseks, järgib nende rakendus ümbersuunamist ja saadab ründajale tundlikku meditsiinilist teavet.
Rünnake endistamples
2021. aasta detsembris avastati laialdaselt kasutatava avatud lähtekoodiga tarkvarakomponendi Log4J haavatavuste komplekt, mis võimaldas ründajal esitada puhastamata sisendit, näiteks kodeeritud skripti, ja kasutada Log4J haavatavaid versioone skripti käivitamiseks serveris. Log4J haavatavuse probleem sai alguse sisendi valideerimise puudumisest, täpsemalt sellest, et deserialiseeritud kasutaja esitatud andmetele ei tehtud turvakontrolle. Serialiseeritud pahatahtliku koodi saatmisega said ründajad haavatavust ära kasutada ja haavatavusega serverile rünnaku teha. Arendajad peaksid kontrollima kõiki kolmandate osapoolte API-de ja muude väliste allikate sisestatud andmeid.27
Kuidas seda arendaja poolt ära hoida?
Arendajad peaksid teenusepakkujate hindamisel, nende API turvalisuse seisundi hindamisel ja rangete turvakontrollide rakendamisel tegema hoolsuskohustust. Lisaks peaksid arendajad kinnitama, et kogu suhtlus kolmandate osapoolte API-dega ja kolmandate osapoolte suhtlus organisatsiooni API-dega kasutab turvalist suhtluskanalit, et vältida nuhkimis- ja kordusrünnakuid.
Välistelt kasutajatelt ja masinatelt andmete vastuvõtmisel tuleks sisendid alati puhastada, et vältida koodi tahtmatut käivitamist. Lõpuks, API-de kaudu integreeritud pilveteenuste puhul tuleks integreeritud lahenduse aadressi lukustamiseks kasutada lubatud nimekirju, mitte lubada pimesi mis tahes IP-aadressil rakenduse API-t kutsuda.
Kuidas OpenText saab aidata?
Kombineerides OpenText Static Application Security Testingu staatilise koodi ja API analüüsi funktsioonid OpenText Dynamic Application Security Testingu (DAST) komplekti käitusaja kontrollidega, saavad DevSecOpsi meeskonnad kontrollida oma rakenduste kolmandate osapoolte API-de kasutamist ja testida levinud rünnakutüüpe. Ebaturvaliste API-de leidmiseks saab OpenText Secure API Manager luua hoidla kõigist süsteemi poolt kutsutud API-dest ja sellest, millised välised rakendused saavad teie rakenduse API-sid kasutada.
27 Microsoft Threat Intelligence. Juhised Log4j 2 haavatavuse ennetamiseks, avastamiseks ja ärakasutamiseks. Microsoft. Web lehekülg. Uuendatud: 10. jaanuar 2022.
Arendaja juhend 2023. aasta OWASP-i 10 parima API turvalisuse kohta
22/23
Kuhu edasi minna
Selles dokumendis mainitakse järgmisi tooteid: OpenText Application Security >
OpenTexti staatilise rakenduse turvatestimine >
OpenTexti dünaamiliste rakenduste turvatestimine >
OpenText Secure API haldur >
Lisaressursid OWASP 10 suurimat API turvariski – 2023 >
Gartneri rakenduste turvalisuse testimise maagiline kvadrant >
OpenTexti rakenduste turvalisus Webinar seeria >
API turvalisuse top 10-st ei piisa!
Pilvepõhiste arendajate jaoks, kes keskenduvad spetsiaalselt API-de loomisele teenuste pakkumiseks rakenduse teistele osadele, sisemistele kasutajatele või globaalseks tarbimiseks, on OWASP API turvalisuse 10 parima nimekiri oluline dokument, mida lugeda ja mõista.
Siiski ei ole OWASP API turvalisuse top 10 eraldiseisev dokument. Arendajad peavad ka veenduma, et nad kasutavad muid parimate tavade allikaid, näiteks OWASP Top 10, mis on asjakohased nende praeguse rakenduse ja arhitektuuri jaoks. Levinud rakenduste haavatavused – SQL-süstimine, andmete avalikustamine ja turvalisuse valekonfiguratsioon – on jätkuvalt levinud viisid, kuidas küberohtude rühmitused saavad ettevõtte infrastruktuuri kahjustada, ja need tuleks kiiresti parandada. Lisaks nõuavad mõned API-põhised rakendused, näiteks mobiilirakendused, erinevaid rakenduste turvalisuse tugevdamise samme kui eraldiseisev dokument. web-rakendus ja erineb sellest, mida võidakse nõuda ühenduse ja IoT-seadmete jaoks. Üldiselt on API turvalisuse 10 parima nimekiri oluline, kuid see jääb vaid turvalise tarkvaraarenduse elutsükli tahuks. Nimekirja ja OWASP 10 parima nimekirja tuleks kasutada koos kõigi muude asjakohaste standardite ja parimate tavadega, mida analüüsitav lahendus vajab.
Järeldus
Kuna rakendused toetuvad üha enam pilveinfrastruktuurile, web Rakendusliidestest (API-dest) on saanud interneti alustala. Ettevõtetel on oma keskkonnas tavaliselt sadu, kui mitte tuhandeid API-lõpp-punkte, mis suurendab dramaatiliselt nende rünnakupinda ja avab rakendused mitmesugustele nõrkustele.
2023. aasta OWASP API turvalisuse 10 parima nimekirja avaldamine on hea lähtepunkt ettevõtetele ja arendajatele, et end API-põhise infrastruktuuri riskide kohta harida ja oma rakendusi hinnata. Koos tuntuma rakenduste turvalisuse 10 parima nimekirjaga aitavad need edetabelid DevSecOps meeskondadel oma rakenduste üldise turvalisuse osas tervikliku lähenemisviisi väljatöötamisel.
DevSecOpsi meeskonnad peavad olema teadlikud API-de turvamõjudest, sellest, kuidas vähendada rakenduse haavatavusi ja turvanõrkusi ning kuidas tugevdada oma arendusprotsessi ja sellest tulenevat API-serverit, et ründajatel oleks API-de kaudu rakenduse ohtu seadmine raskem.
Autoriõigus © 2025 Avatud tekst · 04.25 | 262-000177-001
Dokumendid / Ressursid
 |
OpenText 262-000177-001 OWASP 10 parimat API turvalisuse tagamiseks [pdfKasutusjuhend 262-000177-001, 262-000177-001 OWASP API turvalisuse 10 parimat, 262-000177-001, OWASP API turvalisuse 10 parimat, API turvalisuse jaoks, API turvalisus, Turvalisus |