Peamised OATH API haavatavused
Peamised OATH API haavatavused: sissejuhatus
Kui rääkida ärakasutamistest, on API-d parim koht alustamiseks. API juurdepääs koosneb tavaliselt kolmest osast. Klientidele väljastab žetoonid autoriseerimisserver, mis töötab koos API-dega. API saab kliendilt juurdepääsuluba ja rakendab nende alusel domeenispetsiifilisi autoriseerimisreegleid.
Kaasaegsed tarkvararakendused on haavatavad mitmesuguste ohtude suhtes. Hoidke end kursis viimaste ärakasutamiste ja turvavigadega; Nende haavatavuste võrdlusnäitajad on hädavajalikud, et tagada rakenduse turvalisus enne rünnakut. Kolmandate osapoolte rakendused toetuvad üha enam OAuthi protokollile. Tänu sellele tehnoloogiale on kasutajatel parem üldine kasutuskogemus ning kiirem sisselogimine ja autoriseerimine. See võib olla tavapärasest autoriseerimisest turvalisem, kuna kasutajad ei pea antud ressursile juurdepääsuks kolmanda osapoole rakendusega oma mandaate avaldama. Kuigi protokoll ise on ohutu ja turvaline, võib selle rakendamisviis teid rünnata.
API-de kujundamisel ja hostimisel keskendub see artikkel tüüpilistele OAuthi haavatavustele ja erinevatele turvameetmetele.
Katkine objektitaseme autoriseerimine
Volituse rikkumise korral on rünnakupind suur, kuna API-d pakuvad juurdepääsu objektidele. Kuna API-juurdepääsetavad üksused peavad olema autentitud, on see vajalik. Rakendage API lüüsi abil objektitaseme autoriseerimiskontrolle. Juurdepääs tuleks lubada ainult neile, kellel on asjakohased mandaadid.
Katkine kasutaja autentimine
Volitamata märgid on teine sagedane viis, kuidas ründajad saavad API-dele juurdepääsu. Autentimissüsteeme võidakse häkkida või API-võti võidakse ekslikult paljastada. Autentimismärgid võivad olla kasutavad häkkerid juurdepääsu saamiseks. Autentige inimesi ainult siis, kui neid saab usaldada, ja kasutage tugevaid paroole. OAuthi abil saate minna kaugemale pelgalt API-võtmetest ja pääseda juurde oma andmetele. Peaksite alati mõtlema, kuidas kuhugi sisse ja sealt välja pääsete. OAuthi MTLS-i saatja piiratud lubasid võib kasutada koos vastastikuse TLS-iga tagamaks, et kliendid ei käitu teistele masinatele juurdepääsu ajal valesti ega edasta žetoone valele poolele.
API reklaam:
Liigne andmete kokkupuude
Avaldatavate lõpp-punktide arvule pole piiranguid. Enamasti pole kõik funktsioonid kõigile kasutajatele saadaval. Avaldades rohkem andmeid, kui on absoluutselt vajalik, seate ennast ja teisi ohtu. Vältige tundlike asjade avaldamist info kuni see on absoluutselt vajalik. Arendajad võivad määrata, kellel on millele juurdepääs, kasutades OAuthi ulatust ja nõudeid. Nõuded võivad täpsustada, millistele andmete osadele on kasutajal juurdepääs. Juurdepääsu kontrolli saab muuta lihtsamaks ja hõlpsamini hallatavaks, kasutades kõigi API-de standardstruktuuri.
Ressursside puudumine ja määra piiramine
Mustad mütsid kasutavad sageli teenuse keelamise (DoS) rünnakuid jõhkra jõuna serveri ülekoormamiseks ja seega selle tööaja nullimiseks. Ilma piiranguteta ressurssidele, mida võidakse kutsuda, on API nõrgestava rünnaku suhtes haavatav. 'API lüüsi või haldustööriista kasutades saate API-dele määrata määrapiirangud. Kaasa tuleks lisada filtreerimine ja lehekülgede jagamine ning vastused peavad olema piiratud.
Turvasüsteemi vale konfiguratsioon
Erinevad turbekonfiguratsiooni juhised on turvavea konfigureerimise märkimisväärse tõenäosuse tõttu üsna põhjalikud. Mitmed pisiasjad võivad teie platvormi turvalisust ohustada. Võimalik, et varjatud eesmärkidega mustad mütsid võivad näiteks avastada tundlikku teavet, mis on saadetud vastuseks valesti vormindatud päringutele.
Massiülesanne
See, et lõpp-punkt pole avalikult määratletud, ei tähenda, et arendajad ei pääse sellele juurde. Häkkerid võivad salajase API hõlpsasti kinni pidada ja pöördprojekteerida. Vaadake seda põhinäidet, mis kasutab privaatses API-s avatud kandemärki. Teisest küljest võib avalik dokumentatsioon eksisteerida millegi jaoks, mis on mõeldud eranditult isiklikuks kasutamiseks. Avatud teavet võivad mustad mütsid kasutada mitte ainult objekti omaduste lugemiseks, vaid ka manipuleerimiseks. Pidage end häkkeriks, kui otsite oma kaitsemehhanismides potentsiaalseid nõrku kohti. Lubage tagastatule juurde pääseda ainult õigete õigustega isikutel. Haavatavuse minimeerimiseks piirake API vastusepaketti. Vastajad ei tohiks lisada linke, mis pole absoluutselt vajalikud.
Reklaamitud API:
Vale varahaldus
Lisaks arendaja tootlikkuse suurendamisele on praegused versioonid ja dokumentatsioon teie enda turvalisuse tagamiseks olulised. Valmistuge uute versioonide kasutuselevõtuks ja vanade API-de kasutusest loobumiseks juba palju varem. Kasutage uuemaid API-sid, selle asemel, et lubada vanematel kasutusse jääda. API spetsifikatsiooni saab kasutada dokumentatsiooni peamise tõeallikana.
Süst
API-d on süstimise suhtes haavatavad, aga ka kolmanda osapoole arendajarakendused. Pahatahtlikku koodi võidakse kasutada andmete kustutamiseks või konfidentsiaalse teabe (nt paroolid ja krediitkaardinumbrid) varastamiseks. Kõige olulisem õppetund sellest on see, et ärge sõltuge vaikeseadetest. Teie juhtkond või lüüsi tarnija peaks suutma rahuldada teie ainulaadsed rakenduse vajadused. Veateated ei tohiks sisaldada tundlikku teavet. Et vältida identiteediandmete lekkimist süsteemist väljapoole, tuleks žetoonides kasutada paarilisi pseudonüüme. See tagab, et ükski klient ei tööta koos kasutaja tuvastamiseks.
Ebapiisav logimine ja jälgimine
Kui rünnak toimub, vajavad meeskonnad hästi läbimõeldud reaktsioonistrateegiat. Arendajad jätkavad turvaaukude ärakasutamist ilma, et nad jääksid vahele, kui puudub usaldusväärne logimis- ja seiresüsteem, mis suurendab kahjusid ja kahjustab avalikkuse ettekujutust ettevõttest. Võtta kasutusele range API jälgimise ja tootmise lõpp-punkti testimise strateegia. Valge mütsi testijaid, kes avastavad haavatavused varakult, tuleks premeerida pearahaskeemiga. Logijälge saab täiustada, lisades kasutaja identiteedi API tehingutesse. Veenduge, et kõiki teie API arhitektuuri kihte auditeeritakse Access Tokeni andmete abil.
Järeldus
Platvormiarhitektid võivad varustada oma süsteeme, et hoida ründajatest sammu võrra ees, järgides kehtestatud haavatavuse kriteeriume. Kuna API-d võivad pakkuda juurdepääsu isikut tuvastavale teabele (PII), on selliste teenuste turvalisuse säilitamine ülioluline nii ettevõtte stabiilsuse kui ka selliste õigusaktide (nt GDPR) järgimise jaoks. Ärge kunagi saatke OAuthi märke otse API kaudu ilma API lüüsi ja Phantom Token Approach'i kasutamata.
Reklaamitud API:
