Najveće ranjivosti OATH API-ja
Najpopularnije OATH API ranjivosti: Uvod
Kada su u pitanju eksploatacije, API-ji su najbolje mjesto za početak. API pristup se obično sastoji od tri dijela. Klijentima izdaje tokene autorizacijski server, koji radi uz API-je. API prima pristupne tokene od klijenta i na osnovu njih primjenjuje pravila autorizacije specifična za domenu.
Moderne softverske aplikacije su podložne raznim opasnostima. Budite u toku s najnovijim eksploatacijama i sigurnosnim propustima; posjedovanje referentnih vrijednosti za ove ranjivosti je od suštinskog značaja za osiguranje sigurnosti aplikacije prije napada. Aplikacije trećih strana se sve više oslanjaju na OAuth protokol. Korisnici će imati bolje cjelokupno korisničko iskustvo, kao i bržu prijavu i autorizaciju, zahvaljujući ovoj tehnologiji. Može biti sigurnije od konvencionalne autorizacije jer korisnici ne moraju otkriti svoje vjerodajnice u aplikaciji treće strane da bi pristupili datom resursu. Iako je sam protokol siguran i bezbjedan, način na koji se implementira može vas ostaviti otvorenim za napad.
Prilikom dizajniranja i hostinga API-ja, ovaj članak se fokusira na tipične OAuth ranjivosti, kao i na različita sigurnosna ublažavanja.
Autorizacija na nivou slomljenog objekta
Postoji velika površina napada ako je autorizacija prekršena jer API-ji pružaju pristup objektima. S obzirom na to da stavke kojima je dostupan API moraju biti provjerene, to je neophodno. Implementirajte provjere autorizacije na razini objekta koristeći API gateway. Pristup bi trebao biti dozvoljen samo onima s odgovarajućim vjerodajnicama.
Pokvarena autentikacija korisnika
Neovlašteni tokeni su još jedan čest način da napadači dobiju pristup API-jima. Sistemi za autentifikaciju mogu biti hakovani ili API ključ može biti greškom izložen. Tokeni za autentifikaciju mogu biti koriste hakeri za dobijanje pristupa. Autentificirajte ljude samo ako im se može vjerovati i koristite jake lozinke. Sa OAuthom, možete ići dalje od pukih API ključeva i dobiti pristup svojim podacima. Uvijek treba razmišljati o tome kako ćete ući i izaći iz nekog mjesta. OAuth MTLS Sender Constrained Tokeni se mogu koristiti zajedno sa Mutual TLS kako bi se garantovalo da se klijenti neće loše ponašati i proslijediti tokene pogrešnoj strani dok pristupaju drugim mašinama.
API promocija:
Prekomjerna izloženost podacima
Ne postoje ograničenja za broj krajnjih tačaka koje se mogu objaviti. Većinu vremena nisu sve funkcije dostupne svim korisnicima. Izlažući više podataka nego što je apsolutno neophodno, dovodite sebe i druge u opasnost. Izbjegavajte otkrivanje osjetljivih informacija sve dok to nije apsolutno neophodno. Programeri mogu odrediti ko ima pristup čemu koristeći OAuth opsege i zahtjeve. Zahtjevi mogu specificirati kojim dijelovima podataka korisnik ima pristup. Kontrola pristupa može biti pojednostavljena i lakša za upravljanje korištenjem standardne strukture u svim API-jima.
Nedostatak resursa i ograničenje stope
Crni šeširi često koriste napade uskraćivanja usluge (DoS) kao grubi način da preplave server i tako smanje njegovo vrijeme rada na nulu. Bez ograničenja na resurse koji se mogu pozvati, API je ranjiv na iscrpljujući napad. 'Koristeći API pristupnik ili alat za upravljanje, možete postaviti ograničenja brzine za API-je. Treba uključiti filtriranje i paginaciju, kao i ograničenje odgovora.
Pogrešna konfiguracija sigurnosnog sistema
Različite smjernice za sigurnosnu konfiguraciju su prilično sveobuhvatne, zbog velike vjerovatnoće sigurnosne pogrešne konfiguracije. Brojne sitnice mogu ugroziti sigurnost vaše platforme. Moguće je da crni šeširi sa skrivenim svrhama mogu otkriti osjetljive informacije poslane kao odgovor na pogrešno oblikovane upite, na primjer.
Mass Assignment
Samo zato što krajnja tačka nije javno definisana ne znači da joj programeri ne mogu pristupiti. Hakeri mogu lako presresti i obrnuti inženjering tajni API. Pogledajte ovaj osnovni primjer, koji koristi otvoreni token nosioca u “privatnom” API-ju. S druge strane, javna dokumentacija može postojati za nešto što je isključivo namijenjeno za ličnu upotrebu. Izložene informacije mogu koristiti crni šeširi ne samo da čitaju, već i da manipulišu karakteristikama objekta. Smatrajte sebe hakerom dok tražite potencijalne slabe tačke u svojoj odbrani. Dozvolite pristup onome što je vraćeno samo onima koji imaju odgovarajuća prava. Da biste smanjili ranjivost, ograničite paket odgovora API-ja. Ispitanici ne bi trebali dodavati nikakve veze koje nisu apsolutno obavezne.
Promovirani API:
Nepravilno upravljanje imovinom
Osim povećanja produktivnosti programera, trenutne verzije i dokumentacija su bitni za vašu sigurnost. Pripremite se za uvođenje novih verzija i ukidanje starih API-ja daleko unaprijed. Koristite novije API-je umjesto da dopuštate da stariji ostanu u upotrebi. API specifikacija bi se mogla koristiti kao primarni izvor istine za dokumentaciju.
ubrizgavanje
API-ji su osjetljivi na ubrizgavanje, ali i aplikacije treće strane za programere. Zlonamjerni kod se može koristiti za brisanje podataka ili krađu povjerljivih informacija, kao što su lozinke i brojevi kreditnih kartica. Najvažnija lekcija koju treba izvući iz ovoga je da ne zavisite od podrazumevanih postavki. Vaš menadžment ili dobavljač mrežnog prolaza trebao bi biti u mogućnosti da zadovolji vaše jedinstvene potrebe aplikacije. Poruke o grešci ne bi trebale sadržavati osjetljive informacije. Kako bi se spriječilo curenje podataka o identitetu izvan sistema, u tokenima bi se trebali koristiti Pairwise Pseudonimi. Ovo osigurava da nijedan klijent ne može raditi zajedno na identifikaciji korisnika.
Nedovoljno evidentiranje i praćenje
Kada dođe do napada, timovima je potrebna dobro osmišljena strategija reakcije. Programeri će nastaviti da iskorištavaju ranjivosti a da ne budu uhvaćeni ako ne postoji pouzdan sistem evidentiranja i praćenja, što će povećati gubitke i oštetiti percepciju javnosti o kompaniji. Usvojite striktno praćenje API-ja i strategiju testiranja krajnje tačke proizvodnje. Testeri bijelih šešira koji rano pronađu ranjivosti trebali bi biti nagrađeni šemom nagrada. Trag evidencije može se poboljšati uključivanjem identiteta korisnika u API transakcije. Osigurajte da su svi slojevi vaše API arhitekture revidirani korištenjem podataka Access Tokena.
zaključak
Arhitekti platforme mogu opremiti svoje sisteme da budu korak ispred napadača prateći utvrđene kriterijume ranjivosti. Budući da API-ji mogu omogućiti dostupnost ličnim identifikacijskim informacijama (PII), održavanje sigurnosti takvih usluga je ključno i za stabilnost kompanije i za usklađenost sa zakonodavstvom kao što je GDPR. Nikada nemojte slati OAuth tokene direktno preko API-ja bez korištenja API pristupnika i Phantom Token pristupa.
Promovirani API:
