Populārākās OATH API ievainojamības
Populārākās OATH API ievainojamības: ievads
Runājot par izmantošanu, API ir labākā vieta, kur sākt. API piekļuve parasti sastāv no trim daļām. Klientiem pilnvaras izsniedz autorizācijas serveris, kas darbojas kopā ar API. API saņem piekļuves pilnvaras no klienta un piemēro domēna autorizācijas noteikumus, pamatojoties uz tiem.
Mūsdienu programmatūras lietojumprogrammas ir neaizsargātas pret dažādām briesmām. Sekojiet līdzi jaunākajām darbībām un drošības trūkumiem; Šo ievainojamību etalonu noteikšana ir būtiska, lai nodrošinātu lietojumprogrammu drošību pirms uzbrukuma. Trešo pušu lietojumprogrammas arvien vairāk paļaujas uz OAuth protokolu. Pateicoties šai tehnoloģijai, lietotājiem būs labāka vispārējā lietošanas pieredze, kā arī ātrāka pieteikšanās un autorizācija. Tā var būt drošāka par parasto autorizāciju, jo lietotājiem nav jāatklāj savi akreditācijas dati, izmantojot trešās puses lietojumprogrammu, lai piekļūtu konkrētajam resursam. Lai gan pats protokols ir drošs, tā ieviešanas veids var radīt iespēju uzbrukt.
Izstrādājot un mitinot API, šajā rakstā galvenā uzmanība pievērsta tipiskām OAuth ievainojamībām, kā arī dažādiem drošības mazināšanas pasākumiem.
Bojāta objekta līmeņa autorizācija
Ja tiek pārkāpta autorizācija, pastāv plaša uzbrukuma virsma, jo API nodrošina piekļuvi objektiem. Tā kā API pieejamie vienumi ir jāautentificē, tas ir nepieciešams. Ieviesiet objekta līmeņa autorizācijas pārbaudes, izmantojot API vārteju. Piekļuve ir jāļauj tikai tiem, kam ir atbilstoši atļauju akreditācijas dati.
Bojāta lietotāja autentifikācija
Neautorizēti marķieri ir vēl viens bieži sastopams veids, kā uzbrucēji var piekļūt API. Var tikt uzlauztas autentifikācijas sistēmas vai kļūdaini atklāta API atslēga. Autentifikācijas marķieri var būt izmanto hakeri lai iegūtu piekļuvi. Autentificējiet cilvēkus tikai tad, ja viņiem var uzticēties, un izmantojiet spēcīgas paroles. Izmantojot OAuth, varat izmantot ne tikai API atslēgas, bet arī piekļūt saviem datiem. Jums vienmēr jādomā par to, kā jūs nokļūsiet un izkļūsiet no vietas. OAuth MTLS sūtītāja ierobežotās pilnvaras var izmantot kopā ar Mutual TLS, lai garantētu, ka klienti, piekļūstot citām iekārtām, nerīkojas nepareizi un nenodod tokenus nepareizai pusei.
API veicināšana:
Pārmērīga datu ekspozīcija
Nav ierobežojumu attiecībā uz to galapunktu skaitu, ko var publicēt. Lielāko daļu laika ne visas funkcijas ir pieejamas visiem lietotājiem. Atklājot vairāk datu, nekā ir absolūti nepieciešams, jūs pakļaujat briesmām sevi un citus. Izvairieties atklāt sensitīvus informācija līdz tas ir absolūti nepieciešams. Izstrādātāji var norādīt, kam ir piekļuve, izmantojot OAuth tvērumus un pretenzijas. Prasībās var norādīt, kurām datu sadaļām lietotājs var piekļūt. Piekļuves kontroli var padarīt vienkāršāku un vieglāk pārvaldāmu, izmantojot standarta struktūru visās API.
Resursu trūkums un likmes ierobežošana
Melnās cepures bieži izmanto pakalpojumu atteikuma (DoS) uzbrukumus kā brutālu veidu, kā pārslogot serveri un tādējādi samazināt tā darbības laiku līdz nullei. Bez ierobežojumiem izsaucamajiem resursiem API ir neaizsargāta pret novājinošu uzbrukumu. Izmantojot API vārteju vai pārvaldības rīku, varat iestatīt API tarifu ierobežojumus. Jāiekļauj filtrēšana un lappušu šķirošana, kā arī jāierobežo atbildes.
Nepareiza drošības sistēmas konfigurācija
Dažādas drošības konfigurācijas vadlīnijas ir diezgan visaptverošas, jo pastāv ievērojama nepareizas drošības konfigurācijas iespējamība. Vairākas sīkas lietas var apdraudēt jūsu platformas drošību. Iespējams, ka melnās cepures ar slēptiem mērķiem var atklāt sensitīvu informāciju, kas nosūtīta, atbildot uz nepareizi veidotiem vaicājumiem, piemēram.
Masu uzdevums
Tas, ka galapunkts nav publiski definēts, nenozīmē, ka izstrādātāji tam nevar piekļūt. Slepeno API var viegli pārtvert un apgriezti konstruēt hakeri. Apskatiet šo pamata piemēru, kurā tiek izmantots atvērts nesēja marķieris “privātajā” API. No otras puses, publiska dokumentācija var pastāvēt par kaut ko, kas ir paredzēts tikai personiskai lietošanai. Atklāto informāciju melnās cepures var izmantot, lai ne tikai lasītu, bet arī manipulētu ar objektu īpašībām. Uzskatiet sevi par hakeri, meklējot iespējamos vājos punktus savā aizsardzībā. Ļaujiet tikai tiem, kam ir atbilstošas tiesības, piekļūt atdotajam. Lai samazinātu ievainojamību, ierobežojiet API atbildes pakotni. Respondentiem nevajadzētu pievienot nekādas saites, kas nav absolūti nepieciešamas.
Reklamētā API:
Nepareiza līdzekļu pārvaldība
Papildus izstrādātāju produktivitātes uzlabošanai pašreizējās versijas un dokumentācija ir būtiska jūsu drošībai. Sagatavojieties jaunu versiju ieviešanai un veco API novecošanai jau iepriekš. Izmantojiet jaunākas API, nevis ļaujiet vecākām lietot tālāk. API specifikāciju varētu izmantot kā primāro patiesības avotu dokumentācijā.
Injekcija
API ir neaizsargātas pret injekciju, bet arī trešo pušu izstrādātāju lietotnes. Ļaunprātīgu kodu var izmantot, lai dzēstu datus vai nozagtu konfidenciālu informāciju, piemēram, paroles un kredītkaršu numurus. Vissvarīgākā mācība, kas jāņem vērā, ir nebūt atkarīga no noklusējuma iestatījumiem. Jūsu vadībai vai vārtejas piegādātājam jāspēj apmierināt jūsu unikālās lietojumprogrammu vajadzības. Kļūdu ziņojumos nevajadzētu ietvert sensitīvu informāciju. Lai novērstu identitātes datu noplūdi ārpus sistēmas, marķieros jāizmanto pāru pseidonīmi. Tas nodrošina, ka neviens klients nevar strādāt kopā, lai identificētu lietotāju.
Nepietiekama mežizstrāde un uzraudzība
Kad notiek uzbrukums, komandām ir nepieciešama pārdomāta reakcijas stratēģija. Izstrādātāji turpinās izmantot ievainojamības bez pieķeršanas, ja nebūs izveidota uzticama mežizstrādes un uzraudzības sistēma, kas palielinās zaudējumus un kaitēs sabiedrības priekšstatam par uzņēmumu. Pieņemiet stingru API uzraudzības un ražošanas parametru pārbaudes stratēģiju. Baltās cepures testētāji, kuri agri atklāj ievainojamības, ir jāapbalvo ar atlīdzības shēmu. Žurnālu var uzlabot, iekļaujot lietotāja identitāti API darījumos. Nodrošiniet, lai visi jūsu API arhitektūras slāņi tiktu pārbaudīti, izmantojot Access Token datus.
Secinājumi
Platformas arhitekti var aprīkot savas sistēmas, lai būtu soli priekšā uzbrucējiem, ievērojot noteiktos ievainojamības kritērijus. Tā kā API var nodrošināt piekļuvi personiski identificējamai informācijai (PII), šādu pakalpojumu drošības uzturēšana ir ļoti svarīga gan uzņēmuma stabilitātei, gan atbilstībai tiesību aktiem, piemēram, GDPR. Nekad nesūtiet OAuth pilnvaras tieši caur API, neizmantojot API vārteju un Phantom Token Approach.
Reklamētā API:
