Dobësitë kryesore të API-së OATH
Dobësitë kryesore të OATH API: Hyrje
Kur bëhet fjalë për shfrytëzimet, API-të janë vendi më i mirë për të filluar. API qasja zakonisht përbëhet nga tre pjesë. Klientëve u lëshohen shenja nga një Server Autorizimi, i cili funksionon së bashku me API-të. API merr tokenat e aksesit nga klienti dhe zbaton rregullat e autorizimit specifike për domenin bazuar në to.
Aplikacionet moderne të softuerit janë të prekshëm ndaj një sërë rreziqesh. Vazhdoni me shpejtësinë për shfrytëzimet më të fundit dhe të metat e sigurisë; Të kesh standarde për këto dobësi është thelbësore për të garantuar sigurinë e aplikacionit përpara se të ndodhë një sulm. Aplikacionet e palëve të treta po mbështeten gjithnjë e më shumë në protokollin OAuth. Përdoruesit do të kenë një përvojë më të mirë të përgjithshme të përdoruesit, si dhe hyrje dhe autorizim më të shpejtë, falë kësaj teknologjie. Mund të jetë më i sigurt se autorizimi konvencional pasi përdoruesit nuk duhet të zbulojnë kredencialet e tyre me aplikacionin e palës së tretë për të hyrë në një burim të caktuar. Ndërsa vetë protokolli është i sigurt dhe i sigurt, mënyra se si zbatohet mund t'ju lërë të hapur për të sulmuar.
Gjatë dizajnimit dhe pritjes së API-ve, ky artikull fokusohet në dobësitë tipike të OAuth, si dhe në zbutje të ndryshme të sigurisë.
Autorizimi i nivelit të objektit të thyer
Ekziston një sipërfaqe e madhe sulmi nëse autorizimi shkelet pasi API-të ofrojnë akses në objekte. Meqenëse artikujt e aksesueshëm nga API duhet të vërtetohen, kjo është e nevojshme. Zbatoni kontrollet e autorizimit të nivelit të objektit duke përdorur një portë API. Vetëm atyre me kredencialet e duhura të lejes duhet t'u lejohet qasja.
Autentifikimi i prishur i përdoruesit
Shenjat e paautorizuara janë një mënyrë tjetër e shpeshtë që sulmuesit të kenë akses në API. Sistemet e vërtetimit mund të hakohen ose një çelës API mund të ekspozohet gabimisht. Shenjat e vërtetimit mund të jenë përdorur nga hakerat për të marrë akses. Autentifikoni njerëzit vetëm nëse mund t'u besohet dhe përdorni fjalëkalime të forta. Me OAuth, ju mund të shkoni përtej çelësave të thjeshtë API dhe të merrni akses në të dhënat tuaja. Gjithmonë duhet të mendoni se si do të hyni dhe do të dilni nga një vend. Shenjat e kufizuara të dërguesit të OAuth MTLS mund të përdoren në lidhje me TLS të ndërsjellë për të garantuar që klientët të mos sillen keq dhe t'i kalojnë argumentet palës së gabuar gjatë qasjes në makina të tjera.
Promovimi i API:
Ekspozimi i tepërt i të dhënave
Nuk ka kufizime në numrin e pikave përfundimtare që mund të publikohen. Shumicën e kohës, jo të gjitha veçoritë janë të disponueshme për të gjithë përdoruesit. Duke ekspozuar më shumë të dhëna sesa është absolutisht e nevojshme, ju e vendosni veten dhe të tjerët në rrezik. Shmangni zbulimin e ndjeshme informacion derisa të jetë absolutisht e nevojshme. Zhvilluesit mund të specifikojnë se kush ka qasje në çfarë duke përdorur shtrirjet dhe pretendimet e OAuth. Pretendimet mund të specifikojnë se në cilat seksione të të dhënave ka akses një përdorues. Kontrolli i aksesit mund të bëhet më i thjeshtë dhe më i lehtë për t'u menaxhuar duke përdorur një strukturë standarde në të gjitha API-të.
Mungesa e burimeve dhe kufizimi i tarifave
Kapelet e zeza shpesh përdorin sulmet e mohimit të shërbimit (DoS) si një mënyrë me forcë brutale për të mposhtur një server dhe për të reduktuar kohën e tij të funksionimit në zero. Pa kufizime në burimet që mund të thirren, një API është i prekshëm ndaj një sulmi dobësues. 'Duke përdorur një portë API ose mjet menaxhimi, mund të vendosni kufizime të tarifave për API-të. Duhet të përfshihen filtrimi dhe faqëzimi, si dhe përgjigjet të kufizohen.
Konfigurimi i gabuar i sistemit të sigurisë
Udhëzimet e ndryshme të konfigurimit të sigurisë janë mjaft gjithëpërfshirëse, për shkak të gjasave të konsiderueshme të keqkonfigurimit të sigurisë. Një sërë gjërash të vogla mund të rrezikojnë sigurinë e platformës suaj. Është e mundur që kapelet e zeza me qëllime të fshehta mund të zbulojnë informacione të ndjeshme të dërguara në përgjigje të pyetjeve të keqformuara, si shembull.
Detyrë në masë
Vetëm për shkak se një pikë fundore nuk është e përcaktuar publikisht nuk do të thotë se nuk mund të aksesohet nga zhvilluesit. Një API sekrete mund të përgjohet dhe të ndërtohet me lehtësi nga hakerat. Hidhini një sy këtij shembulli bazë, i cili përdor një Token të hapur Bartës në një API "private". Nga ana tjetër, dokumentacioni publik mund të ekzistojë për diçka që është menduar ekskluzivisht për përdorim personal. Informacioni i ekspozuar mund të përdoret nga kapelet e zeza jo vetëm për të lexuar, por edhe për të manipuluar karakteristikat e objektit. Konsideroni veten një haker ndërsa kërkoni për pika të dobëta të mundshme në mbrojtjen tuaj. Lejo vetëm ata me të drejta të duhura qasje në atë që u kthye. Për të minimizuar cenueshmërinë, kufizoni paketën e përgjigjes API. Të anketuarit nuk duhet të shtojnë asnjë lidhje që nuk kërkohet absolutisht.
API i promovuar:
Menaxhimi jo i duhur i aseteve
Përveç rritjes së produktivitetit të zhvilluesve, versionet dhe dokumentacioni aktual janë thelbësorë për sigurinë tuaj. Përgatituni për prezantimin e versioneve të reja dhe zhvlerësimin e API-ve të vjetra shumë përpara. Përdorni API më të reja në vend që të lejoni që ato të vjetra të mbeten në përdorim. Një Specifikimi API mund të përdoret si burim kryesor i së vërtetës për dokumentacion.
Injeksion
API-të janë të prekshme ndaj injektimit, por po ashtu janë edhe aplikacionet e zhvilluesve të palëve të treta. Kodi keqdashës mund të përdoret për të fshirë të dhënat ose për të vjedhur informacione konfidenciale, si fjalëkalimet dhe numrat e kartave të kreditit. Mësimi më i rëndësishëm për t'u hequr nga kjo është të mos vareni nga cilësimet e paracaktuara. Menaxhmenti juaj ose furnizuesi juaj i portës duhet të jetë në gjendje të plotësojë nevojat tuaja unike të aplikimit. Mesazhet e gabimit nuk duhet të përfshijnë informacione të ndjeshme. Për të parandaluar rrjedhjen e të dhënave të identitetit jashtë sistemit, pseudonimet Pairwise duhet të përdoren në token. Kjo siguron që asnjë klient nuk mund të punojë së bashku për të identifikuar një përdorues.
Regjistrimi dhe monitorimi i pamjaftueshëm
Kur ndodh një sulm, ekipet kërkojnë një strategji reagimi të mirëmenduar. Zhvilluesit do të vazhdojnë të shfrytëzojnë dobësitë pa u kapur nëse nuk ekziston një sistem i besueshëm i regjistrimit dhe monitorimit, i cili do të rrisë humbjet dhe do të dëmtojë perceptimin e publikut për kompaninë. Miratoni një strategji strikte të monitorimit të API dhe testimit të pikës fundore të prodhimit. Testuesit e kapelave të bardha që gjejnë dobësi herët duhet të shpërblehen me një skemë shpërblimi. Gjurma e regjistrit mund të përmirësohet duke përfshirë identitetin e përdoruesit në transaksionet API. Sigurohuni që të gjitha shtresat e arkitekturës suaj API të auditohen duke përdorur të dhënat Access Token.
Përfundim
Arkitektët e platformave mund të pajisin sistemet e tyre për të mbajtur një hap përpara sulmuesve duke ndjekur kriteret e përcaktuara të cenueshmërisë. Për shkak se API-të mund të ofrojnë akses ndaj Informacionit Personal të Identifikueshëm (PII), ruajtja e sigurisë së shërbimeve të tilla është thelbësore si për stabilitetin e kompanisë ashtu edhe për pajtueshmërinë me legjislacionin si GDPR. Asnjëherë mos dërgoni shenja OAuth drejtpërdrejt mbi një API pa përdorur një portë API dhe Qasjen Phantom Token.
API i promovuar:
