Populiariausios OATH API spragos
Populiariausios OATH API spragos: įvadas
Kalbant apie išnaudojimus, API yra geriausia vieta pradėti. API prieiga paprastai susideda iš trijų dalių. Klientams prieigos raktus išduoda autorizavimo serveris, veikiantis kartu su API. API gauna prieigos prieigos raktus iš kliento ir pagal juos taiko konkrečiam domenui būdingas autorizavimo taisykles.
Šiuolaikinės programinės įrangos yra pažeidžiamos įvairių pavojų. Sekite naujausius išnaudojimus ir saugumo trūkumus; Norint užtikrinti programos saugumą prieš įvykstant atakai, būtina turėti šių spragų etalonus. Trečiųjų šalių programos vis labiau pasikliauja OAuth protokolu. Dėl šios technologijos vartotojai turės geresnę bendrą vartotojo patirtį, taip pat greitesnį prisijungimą ir prieigos teisę. Tai gali būti saugesnė nei įprastas autorizavimas, nes naudotojai neturi atskleisti savo kredencialų naudodami trečiosios šalies programą, kad galėtų pasiekti tam tikrą šaltinį. Nors pats protokolas yra saugus, jo įdiegimo būdas gali leisti jums atakuoti.
Kuriant ir priglobiant API, šiame straipsnyje dėmesys sutelkiamas į tipinius OAuth pažeidžiamumus ir įvairius saugos mažinimo būdus.
Sugadintas objekto lygio leidimas
Pažeidus autorizaciją, yra didžiulis atakos paviršius, nes API suteikia prieigą prie objektų. Kadangi API pasiekiami elementai turi būti autentifikuoti, tai būtina. Įdiekite objekto lygio įgaliojimų patikras naudodami API šliuzą. Prieiga turėtų būti suteikta tik tiems, kurie turi atitinkamus leidimų kredencialus.
Sugadintas vartotojo autentifikavimas
Neteisėti prieigos raktai yra dar vienas dažnas būdas užpuolikams gauti prieigą prie API. Autentifikavimo sistemos gali būti įsilaužtos arba API raktas gali būti per klaidą atskleistas. Autentifikavimo žetonai gali būti naudojo įsilaužėliai gauti prieigą. Autentifikuokite žmones, tik jei jais galima pasitikėti, ir naudokite stiprius slaptažodžius. Naudodami OAuth galite ne tik naudoti API raktus, bet ir gauti prieigą prie savo duomenų. Visada turėtumėte galvoti apie tai, kaip įeisite ir išeisite iš vietos. „OAuth MTLS Sender Constrained Tokens“ gali būti naudojami kartu su Mutual TLS, siekiant užtikrinti, kad klientai nesielgs netinkamai ir neperduos prieigos raktų neteisingai šaliai, kai pasiekia kitus įrenginius.
API reklama:
Per didelis duomenų eksponavimas
Galinių taškų, kurie gali būti paskelbti, skaičiui apribojimų nėra. Dažniausiai ne visos funkcijos yra prieinamos visiems vartotojams. Atskleidę daugiau duomenų, nei būtina, keliate pavojų sau ir kitiems. Venkite atskleisti jautrius informacija kol tai tikrai būtina. Kūrėjai gali nurodyti, kas prie ko turi prieigą, naudodami „OAuth“ apimtį ir pretenzijas. Pretenzijose gali būti nurodyta, prie kurių duomenų skilčių vartotojas turi prieigą. Prieigos valdymas gali būti paprastesnis ir lengviau valdomas naudojant standartinę visų API struktūrą.
Išteklių trūkumas ir tarifų ribojimas
Juodosios kepurės dažnai naudoja atsisakymo teikti paslaugas (DoS) puolimą kaip žiaurų būdą užvaldyti serverį ir taip sumažinti jo veikimo laiką iki nulio. Be jokių apribojimų ištekliams, kuriuos galima iškviesti, API gali būti pažeidžiama sekinančiam puolimui. „Naudodami API šliuzą arba valdymo įrankį galite nustatyti API greičio apribojimus. Turėtų būti įtrauktas filtravimas ir puslapių skirstymas, taip pat apriboti atsakymai.
Neteisinga apsaugos sistemos konfigūracija
Įvairios saugos konfigūracijos gairės yra gana išsamios dėl didelės klaidingos saugos konfigūracijos tikimybės. Daugybė smulkmenų gali kelti pavojų jūsų platformos saugumui. Gali būti, kad juodos skrybėlės su slaptais tikslais gali aptikti neskelbtinos informacijos, siunčiamos atsakant į netinkamai suformuotas užklausas.
Mišių paskyrimas
Vien todėl, kad galutinis taškas nėra viešai apibrėžtas, nereiškia, kad kūrėjai jo negali pasiekti. Slaptą API gali lengvai perimti ir pakeisti įsilaužėliai. Pažvelkite į šį pagrindinį pavyzdį, kuriame naudojamas atviras nešiklio prieigos raktas „privačioje“ API. Kita vertus, vieši dokumentai gali egzistuoti tam, kas yra skirta tik asmeniniam naudojimui. Atidengtą informaciją juodos kepurės gali naudoti norėdami ne tik skaityti, bet ir manipuliuoti objekto charakteristikomis. Laikykite save įsilaužėliu, kai ieškote galimų silpnų savo gynybos vietų. Leiskite tik atitinkamas teises turintiems asmenims prieiti prie to, kas buvo grąžinta. Norėdami sumažinti pažeidžiamumą, apribokite API atsako paketą. Respondentai neturėtų pridėti jokių nuorodų, kurios nėra visiškai būtinos.
Reklamuojama API:
Netinkamas turto valdymas
Be kūrėjo produktyvumo didinimo, dabartinės versijos ir dokumentacija yra būtini jūsų pačių saugumui. Pasiruoškite naujų versijų įvedimui ir senų API naudojimo nutraukimui iš anksto. Naudokite naujesnes API, o ne leiskite naudoti senesnes. API specifikacija galėtų būti naudojama kaip pagrindinis dokumentacijos tiesos šaltinis.
Įpurškimas
API yra pažeidžiamos injekcijoms, bet taip pat ir trečiųjų šalių kūrėjų programos. Kenkėjiškas kodas gali būti naudojamas norint ištrinti duomenis arba pavogti konfidencialią informaciją, pvz., slaptažodžius ir kredito kortelių numerius. Svarbiausia pamoka – nepriklausyti nuo numatytųjų nustatymų. Jūsų vadovybė arba šliuzo tiekėjas turėtų turėti galimybę patenkinti jūsų unikalius programos poreikius. Klaidų pranešimuose neturėtų būti neskelbtinos informacijos. Kad tapatybės duomenys nepatektų už sistemos ribų, žetonuose turėtų būti naudojami poriniai pseudonimai. Taip užtikrinama, kad joks klientas negalės dirbti kartu, kad identifikuotų vartotoją.
Nepakankamas registravimas ir stebėjimas
Kai įvyksta ataka, komandoms reikia gerai apgalvotos reakcijos strategijos. Jei nebus įdiegta patikima registravimo ir stebėjimo sistema, kūrėjai ir toliau išnaudos pažeidžiamumą, o tai padidins nuostolius ir pakenks visuomenės suvokimui apie įmonę. Priimkite griežtą API stebėjimo ir gamybos galutinio taško testavimo strategiją. Baltų skrybėlių bandytojai, anksti aptikę pažeidžiamumą, turėtų būti apdovanoti premijų schema. Žurnalo seką galima patobulinti įtraukiant vartotojo tapatybę į API operacijas. Įsitikinkite, kad visi jūsų API architektūros sluoksniai yra tikrinami naudojant Access Token duomenis.
Išvada
Laikydamiesi nustatytų pažeidžiamumo kriterijų, platformos architektai gali aprūpinti savo sistemas, kad jos būtų vienu žingsniu priekyje užpuolikų. Kadangi API gali suteikti prieigą prie asmenį identifikuojančios informacijos (PII), tokių paslaugų saugumas yra labai svarbus tiek įmonės stabilumui, tiek teisės aktų, pvz., BDAR, laikymuisi. Niekada nesiųskite „OAuth“ prieigos raktų tiesiai per API, nenaudodami API šliuzo ir „Phantom Token Approach“.
Reklamuojama API:
