Glavne ranjivosti OATH API-ja
Glavne ranjivosti OATH API-ja: Uvod
Kada je riječ o eksploatacijama, API-ji su najbolje mjesto za početak. API pristup se obično sastoji od tri dijela. Klijentima tokene izdaje autorizacijski poslužitelj koji radi uz API-je. API prima pristupne tokene od klijenta i na temelju njih primjenjuje pravila autorizacije specifična za domenu.
Moderne softverske aplikacije osjetljive su na razne opasnosti. Budite u tijeku s najnovijim iskorištavanjima i sigurnosnim nedostacima; posjedovanje referentnih vrijednosti za te ranjivosti ključno je za osiguranje sigurnosti aplikacije prije nego što se napad dogodi. Aplikacije trećih strana sve se više oslanjaju na OAuth protokol. Korisnici će zahvaljujući ovoj tehnologiji imati bolje cjelokupno korisničko iskustvo, kao i bržu prijavu i autorizaciju. Može biti sigurnije od konvencionalne autorizacije budući da korisnici ne moraju otkriti svoje vjerodajnice aplikaciji treće strane kako bi pristupili određenom resursu. Iako je sam protokol siguran i zaštićen, način na koji je implementiran može vas ostaviti otvorenima za napad.
Prilikom dizajniranja i hostinga API-ja, ovaj se članak fokusira na tipične OAuth ranjivosti, kao i na različita sigurnosna ublažavanja.
Pokvarena autorizacija na razini objekta
Postoji ogromna površina napada ako se autorizacija prekrši jer API-ji omogućuju pristup objektima. Budući da stavke dostupne API-ju moraju biti autentificirane, to je neophodno. Implementirajte provjere autorizacije na razini objekta pomoću API pristupnika. Samo onima s odgovarajućim vjerodajnicama za dopuštenje treba dopustiti pristup.
Neispravna provjera autentičnosti korisnika
Neovlašteni tokeni još su jedan čest način na koji napadači dobivaju pristup API-jima. Sustavi za autentifikaciju mogu biti hakirani ili API ključ može biti greškom izložen. Tokeni za autentifikaciju mogu biti koriste hakeri za stjecanje pristupa. Autentificirajte osobe samo ako im se može vjerovati i koristite jake zaporke. Uz OAuth možete ići dalje od običnih API ključeva i dobiti pristup svojim podacima. Uvijek trebate razmišljati o tome kako ćete ući i izaći s nekog mjesta. OAuth MTLS ograničeni tokeni pošiljatelja mogu se koristiti u kombinaciji s Mutual TLS-om kako bi se zajamčilo da se klijenti neće loše ponašati i proslijediti tokene pogrešnoj strani dok pristupaju drugim strojevima.
API promocija:
Pretjerano izlaganje podataka
Ne postoje ograničenja u broju krajnjih točaka koje se mogu objaviti. Većinu vremena nisu sve značajke dostupne svim korisnicima. Izlaganjem više podataka nego što je apsolutno potrebno, dovodite sebe i druge u opasnost. Izbjegavajte otkrivanje osjetljivih informacije sve dok to nije prijeko potrebno. Razvojni programeri mogu odrediti tko čemu ima pristup korištenjem OAuth opsega i zahtjeva. Zahtjevi mogu navesti kojim dijelovima podataka korisnik ima pristup. Kontrola pristupa može biti jednostavnija i lakša za upravljanje korištenjem standardne strukture u svim API-jima.
Nedostatak resursa i ograničenje brzine
Crni šeširi često koriste napade uskraćivanjem usluge (DoS) kao brutalni način nadjačavanja poslužitelja i tako smanjuju njegovo vrijeme rada na nulu. Bez ograničenja resursa koji se mogu pozivati, API je osjetljiv na iscrpljujući napad. 'Koristeći API pristupnik ili alat za upravljanje, možete postaviti ograničenja stope za API-je. Treba uključiti filtriranje i označavanje stranica, kao i ograničenje odgovora.
Pogrešna konfiguracija sigurnosnog sustava
Različite smjernice za sigurnosnu konfiguraciju prilično su sveobuhvatne, zahvaljujući značajnoj vjerojatnosti pogrešne sigurnosne konfiguracije. Brojne male stvari mogu ugroziti sigurnost vaše platforme. Moguće je da crni šeširi sa skrivenim svrhama mogu otkriti osjetljive informacije poslane kao odgovor na neispravne upite, na primjer.
Masovni zadatak
Samo zato što krajnja točka nije javno definirana ne znači da joj programeri ne mogu pristupiti. Hakeri mogu spremno presresti tajni API i izvršiti obrnuti inženjering. Pogledajte ovaj osnovni primjer, koji koristi otvoreni nositeljski token u "privatnom" API-ju. S druge strane, javna dokumentacija može postojati za nešto što je isključivo namijenjeno osobnoj upotrebi. Izložene informacije crni šeširi mogu koristiti ne samo za čitanje već i za manipuliranje karakteristikama objekta. Smatrajte se hakerom dok tražite potencijalne slabe točke u svojoj obrani. Dopustite samo onima s odgovarajućim pravima pristup onome što je vraćeno. Kako biste smanjili ranjivost, ograničite API paket odgovora. Ispitanici ne bi trebali dodavati poveznice koje nisu apsolutno potrebne.
Promovirani API:
Nepravilno upravljanje imovinom
Osim povećanja produktivnosti programera, trenutne verzije i dokumentacija bitni su za vašu vlastitu sigurnost. Pripremite se za uvođenje novih verzija i zastaru starih API-ja daleko unaprijed. Koristite novije API-je umjesto da dopustite da stariji ostanu u upotrebi. Specifikacije API-ja mogu se koristiti kao primarni izvor istine za dokumentaciju.
Ubrizgavanje
API-ji su ranjivi na ubacivanje, ali isto tako su i razvojne aplikacije trećih strana. Zlonamjerni kod može se koristiti za brisanje podataka ili krađu povjerljivih informacija, poput lozinki i brojeva kreditnih kartica. Najvažnija lekcija koju možete naučiti iz ovoga je da ne ovisite o zadanim postavkama. Vaš menadžment ili dobavljač pristupnika trebao bi moći zadovoljiti vaše jedinstvene potrebe aplikacije. Poruke o pogrešci ne smiju sadržavati osjetljive informacije. Kako bi se spriječilo curenje podataka o identitetu izvan sustava, u tokenima bi se trebali koristiti upareni pseudonimi. Ovo osigurava da niti jedan klijent ne može zajedno identificirati korisnika.
Nedovoljno bilježenje i praćenje
Kada se napad dogodi, timovi zahtijevaju dobro promišljenu strategiju reakcije. Programeri će nastaviti iskorištavati ranjivosti, a da ne budu uhvaćeni ako pouzdani sustav za bilježenje i nadzor nije uspostavljen, što će povećati gubitke i oštetiti percepciju javnosti o tvrtki. Usvojite strogi API nadzor i strategiju testiranja krajnje točke proizvodnje. Bijeli šešir testeri koji rano pronađu ranjivosti trebali bi biti nagrađeni programom nagrada. Dnevnik se može 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 platformi mogu opremiti svoje sustave da budu korak ispred napadača slijedeći utvrđene kriterije ranjivosti. Budući da API-ji mogu pružiti pristup podacima koji mogu identificirati osobu (PII), održavanje sigurnosti takvih usluga ključno je i za stabilnost tvrtke i za usklađenost sa zakonodavstvom kao što je GDPR. Nikada ne šaljite OAuth tokene izravno preko API-ja bez upotrebe API pristupnika i pristupa fantomskom tokenu.
Promovirani API:
