Parhaat OATH-sovellusliittymän haavoittuvuudet
Parhaat OATH-sovellusliittymän haavoittuvuudet: Johdanto
Mitä tulee hyväksikäyttöihin, sovellusliittymät ovat paras paikka aloittaa. API pääsy koostuu yleensä kolmesta osasta. Asiakkaille myönnetään tunnukset valtuutuspalvelin, joka toimii sovellusliittymien rinnalla. API vastaanottaa käyttöoikeudet asiakkaalta ja soveltaa niiden perusteella toimialuekohtaisia valtuutussääntöjä.
Nykyaikaiset ohjelmistosovellukset ovat alttiina useille vaaroille. Pysy ajan tasalla uusimmista hyväksikäytöistä ja tietoturvapuutteista; Näiden haavoittuvuuksien vertailuarvojen saaminen on välttämätöntä sovellusten turvallisuuden varmistamiseksi ennen hyökkäystä. Kolmannen osapuolen sovellukset luottavat yhä enemmän OAuth-protokollaan. Käyttäjillä on parempi yleinen käyttökokemus sekä nopeampi kirjautuminen ja valtuutus tämän tekniikan ansiosta. Se voi olla turvallisempi kuin perinteinen valtuutus, koska käyttäjien ei tarvitse paljastaa valtuustietojaan kolmannen osapuolen sovelluksessa päästäkseen tiettyyn resurssiin. Vaikka protokolla itsessään on turvallinen, sen toteutustapa saattaa jättää sinut avoimeksi hyökkäyksille.
Sovellusliittymiä suunniteltaessa ja isännöitäessä tämä artikkeli keskittyy tyypillisiin OAuth-haavoittuvuuksiin sekä erilaisiin tietoturvakeinoihin.
Rikkoutunut objektitason valtuutus
Hyökkäyspinta on laaja, jos valtuutusta rikotaan, koska API:t tarjoavat pääsyn objekteihin. Koska API-käyttöiset kohteet on todennettu, tämä on välttämätöntä. Ota objektitason valtuutustarkistukset käyttöön API-yhdyskäytävän avulla. Vain niille, joilla on asianmukaiset käyttöoikeudet, tulisi olla pääsy.
Rikkoutunut käyttäjän todennus
Luvattomat tunnukset ovat toinen yleinen tapa hyökkääjille saada pääsy API:ihin. Todennusjärjestelmät voivat olla hakkeroituja tai API-avain saatetaan paljastaa vahingossa. Todennustunnukset voivat olla hakkerit käyttävät pääsyn hankkimiseen. Todenna ihmiset vain, jos heihin voi luottaa, ja käytä vahvoja salasanoja. OAuthin avulla voit ylittää pelkkien API-avaimien ja saada pääsyn tietoihisi. Sinun tulee aina miettiä, kuinka pääset sisään ja poistuit sieltä. OAuth MTLS Sender Constrained Tokeneja voidaan käyttää yhdessä Mutual TLS:n kanssa sen takaamiseksi, että asiakkaat eivät toimi väärin ja välitä tunnuksia väärälle osapuolelle käyttäessään muita koneita.
API-promootio:
Liiallinen tietojen altistuminen
Julkaistavien päätepisteiden määrälle ei ole rajoituksia. Useimmiten kaikki ominaisuudet eivät ole kaikkien käyttäjien saatavilla. Kun paljastat enemmän tietoja kuin on ehdottoman välttämätöntä, vaarannat itsesi ja muut. Vältä paljastamasta herkkiä tiedot kunnes se on ehdottoman välttämätöntä. Kehittäjät voivat määrittää, kenellä on pääsy mihin tahansa käyttämällä OAuth-alueita ja -vaatimuksia. Vaatimuksissa voidaan määrittää, mihin tietojen osiin käyttäjällä on pääsy. Kulunvalvonta voidaan tehdä yksinkertaisemmiksi ja helpompi hallita käyttämällä vakiorakennetta kaikissa API:issa.
Resurssien puute ja hintarajoitus
Mustat hatut käyttävät usein palvelunestohyökkäystä (DoS) raa'ana keinona valtaa palvelin ja vähentää siten sen käyttöaikaa nollaan. Ilman rajoituksia kutsuttaville resursseille API on alttiina heikentävälle hyökkäykselle. 'API-yhdyskäytävän tai hallintatyökalun avulla voit asettaa sovellusliittymille nopeusrajoituksia. Suodatus ja sivutus tulisi sisällyttää, samoin kuin vastauksia rajoitetaan.
Turvajärjestelmän virheellinen määritys
Erilaiset suojauskonfigurointiohjeet ovat melko kattavat johtuen tietoturvavirheiden huomattavasta todennäköisyydestä. Useat pienet asiat voivat vaarantaa alustasi turvallisuuden. On mahdollista, että mustat hatut, joilla on taka-aloja, voivat löytää esimerkiksi arkaluontoisia tietoja, jotka on lähetetty vastauksena väärin muotoiltuihin kyselyihin.
Joukkotehtävä
Se, että päätepistettä ei ole julkisesti määritelty, ei tarkoita, että kehittäjät eivät voi käyttää sitä. Hakkerit voivat siepata ja muuttaa salaisen API:n helposti. Katso tämä perusesimerkki, joka käyttää avointa kantajatunnusta "yksityisessä" API:ssa. Toisaalta julkinen dokumentaatio voi olla olemassa jostakin, joka on tarkoitettu yksinomaan henkilökohtaiseen käyttöön. Mustat hatut voivat käyttää paljastettua tietoa paitsi lukeakseen myös käsitelläkseen kohteen ominaisuuksia. Pidä itseäsi hakkerina etsiessäsi mahdollisia heikkoja kohtia puolustuksestasi. Anna palautetuille pääsy vain niille, joilla on asianmukaiset oikeudet. Minimoi haavoittuvuus rajoittamalla API-vastauspakettia. Vastaajien ei tule lisätä linkkejä, jotka eivät ole ehdottoman pakollisia.
Promoted API:
Virheellinen omaisuudenhoito
Kehittäjän tuottavuuden parantamisen lisäksi nykyiset versiot ja dokumentaatio ovat tärkeitä oman turvallisuutesi kannalta. Valmistaudu uusien versioiden käyttöönottoon ja vanhojen sovellusliittymien käytöstä poistamiseen hyvissä ajoin. Käytä uudempia sovellusliittymiä sen sijaan, että sallit vanhojen pysyä käytössä. API-spesifikaatiota voitaisiin käyttää ensisijaisena totuuden lähteenä dokumentoinnissa.
Injektio
Sovellusliittymät ovat alttiita injektiolle, mutta niin ovat myös kolmannen osapuolen kehittäjäsovellukset. Haitallista koodia voidaan käyttää tietojen poistamiseen tai luottamuksellisten tietojen, kuten salasanojen ja luottokorttien numeroiden, varastamiseen. Tärkein oppitunti tästä on se, ettei ole riippuvainen oletusasetuksista. Hallinto- tai yhdyskäytävätoimittajasi pitäisi pystyä vastaamaan ainutlaatuisiin sovellustarpeisiisi. Virheilmoitukset eivät saa sisältää arkaluonteisia tietoja. Jotta henkilöllisyystiedot eivät vuotaisi järjestelmän ulkopuolelle, tunnuksissa tulisi käyttää parillisia salanimiä. Tämä varmistaa, että kukaan asiakas ei voi tehdä yhteistyötä käyttäjän tunnistamiseksi.
Riittämätön kirjaaminen ja seuranta
Kun hyökkäys tapahtuu, joukkueet tarvitsevat hyvin harkitun reaktiostrategian. Kehittäjät jatkavat haavoittuvuuksien hyödyntämistä jäämättä kiinni, jos luotettavaa kirjaus- ja seurantajärjestelmää ei ole käytössä, mikä lisää tappioita ja vahingoittaa yleisön käsitystä yrityksestä. Ota käyttöön tiukka API-seuranta- ja tuotannon päätepisteiden testausstrategia. Valkoisen hatun testaajat, jotka löytävät haavoittuvuuksia varhain, tulisi palkita palkkiojärjestelmällä. Lokipolkua voidaan parantaa sisällyttämällä käyttäjän identiteetti API-tapahtumiin. Varmista, että kaikki API-arkkitehtuurisi tasot tarkastetaan Access Token -tietojen avulla.
Yhteenveto
Alustan arkkitehdit voivat varustaa järjestelmänsä pysymään askeleen edellä hyökkääjiä noudattamalla vahvistettuja haavoittuvuuskriteerejä. Koska sovellusliittymät voivat tarjota pääsyn henkilökohtaisiin tunnistetietoihin (PII), tällaisten palvelujen turvallisuuden ylläpitäminen on ratkaisevan tärkeää sekä yrityksen vakauden että lainsäädännön, kuten GDPR:n, noudattamisen kannalta. Älä koskaan lähetä OAuth-tunnuksia suoraan API:n kautta ilman API-yhdyskäytävää ja Phantom Token Approachia.
Promoted API:
