U svijetu Interneta postoji pet različitih kategorija za HTTP statusne kodove, koji se koriste za označavanje rezultata klijentovog zahtjeva serveru. Oni pomažu i klijentu (poput vašeg web pretraživača ili aplikacije) i serveru da shvate šta se dogodilo tokom njihove komunikacije.
Među ovim kategorijama najčešće su:
- Kategorija 2xx – Uspjeh, gdje je zahtjev uspješno primljen, shvaćen i prihvaćen.
- Kategorija 3xx – Preusmjeravanja, što ukazuje da klijent mora poduzeti dodatne radnje da dovrši zahtjev. Ovi kodovi se obično koriste za preusmjeravanje korisnika na drugi URL ili resurs.
- Kategorija 4xx – Greška klijenta, koja ukazuje da je nešto pošlo po zlu zbog zahtjeva klijenta (poput pogrešnog upisa URL-a).
- Kategorija 5xx – Greška servera, što ukazuje da je nešto pošlo po zlu na strani servera.
U ovom članku ćemo se fokusirati na dva specifična HTTP statusna koda, i to:
- “401 Neovlašteno”, što znači da klijent nije autentifikovan i stoga nije ovlašten za pristup resursu.
- “403 Zabranjeno”, što znači da je klijent autentifikovan, ali nema dozvolu za pristup resursu.
Istraživanje API sigurnosti u hipotetičkoj aplikaciji teretane
Sada, zamislimo da ste se nedavno pridružili teretani u vašem naselju, a oni imaju prilagođenu web aplikaciju koju morate koristiti da biste dobili pristup objektu i upisali se na grupne časove.
Ako ste tehničar, i radoznali ste poput mene, jedna od prvih stvari koje ćete učiniti je presresti promet i vidjeti kakvi se zahtjevi postavljaju.
Dakle, nakon prijave i korištenja alata kao što je Burp Suite , možete presresti zahtjeve aplikacije i njene odgovarajuće odgovore. Nakon analize nekoliko zahtjeva, pojavljuje se zanimljiva stvar: možete vidjeti API zahtjev koji navodi informacije o određenom korisniku u aplikaciji.
Za one koji nisu upoznati sa konceptom API-ja, to je skraćenica od Application Programming Interface, i možete ga zamisliti kao glasnik koji preuzima zahtjev od jednog programa, govori drugom programu šta je potrebno, a zatim vraća odgovor.
API odgovori i izloženost informacija
Sada, pretpostavimo da je za pristup informacijama o korisniku jedina informacija koja vam je potrebna jeste adresa e-pošte korisnika. U ovom slučaju, API krajnja tačka bi izgledala kao https://mygymapp.com/api/users/ [email protected] .
Budući da ste prijavljeni, informacije prikazane u API odgovoru su vaši lični podaci koji su dostupni u aplikaciji, odnosno vaš članski broj, puno ime, broj telefona i datum rođenja. U ovom scenariju dobijate 200 OK!
Ali šta ako promijenite e-poštu u [email protected] i provjerite možete li pristupiti tuđim korisničkim informacijama? Pa, u ovom slučaju, API zahtjev bi izgledao kao https://mygymapp.com/api/users/ [email protected] .
Međutim, kada pokušate pristupiti informacijama o ovom korisniku, dobićete „ 404 Not Found “, što znači da nema korisnika sa tom e-poštom registrovanom u aplikaciji za teretanu.
Budući da je treći put čar, a srećom imate prijateljicu koja ide u istu teretanu kao i vi, odlučite pokušati koristiti njenu e-poštu u API zahtjevu da vidite da li možete vidjeti njene informacije.
Ipak, i na vaše zaprepaštenje, dobijate „ 403 Zabranjeno “, drugačiji od prethodnog koda koji ste primili.
Šta ovo znači? To znači da je email vašeg prijatelja važeći u aplikaciji, ali nemate dovoljno dozvola za pristup njenim informacijama.
To je zanimljivo. Šta ako se odjavite iz aplikacije za teretanu i ponovo uputite iste zahtjeve? U ovom scenariju dobijate grešku “401 Neovlašteno” kada pokušavate pristupiti vašim ili informacijama vašeg prijatelja .
Međutim, kada pokušate pristupiti informacijama [email protected] , ponovo ćete dobiti „404 nije pronađeno“!
Sa tačke gledišta hakera, primanje kodova „401 neovlašćeno“ ili „403 zabranjeno“ i „404 nije pronađeno“ izuzetno je vrijedno kada pokušavate da pristupite više resursa koristeći isti API zahtev.
Ovaj pristup olakšava identifikaciju koji su računi važeći u aplikaciji za teretanu, a koji nisu. Ova tehnika je poznata kao nabrajanje korisnika.
Možda se pitate zašto je saznanje koji su računi važeći u aplikaciji za teretanu, a koji ne, sočan podatak za hakera. Istina je da kada spojite male stvari, one mogu prerasti u nešto mnogo veće.
Hakeri rade sa širokim spektrom ciljeva, od konstruktivnih akcija koje imaju za cilj poboljšanje sigurnosti do malicioznih aktivnosti namijenjenih ličnom dobitku ili ometanju.
Korištenje OSINT i Phishing strategija
U ovom slučaju, mogući put za Hakera može početi kreiranjem dugačke liste adresa e-pošte pomoću alata Open-Source Intelligence (OSINT).
OSINT se odnosi na proces prikupljanja i analiziranja javno dostupnih informacija iz različitih izvora kako bi se proizvele djelotvorne obavještajne podatke.
Na Internetu su dostupni brojni OSINT alati koji omogućavaju preuzimanje liste adresa e-pošte na osnovu imena domena.
Da bi ovaj scenario uspio, haker mora potvrditi koje adrese e-pošte su važeće u aplikaciji za teretanu.
Da bi to postigao, Haker zamjenjuje adresu e-pošte u API zahtjevu sa svakim unosom sa novokreirane liste. Izvođenje ove zamjene više puta u kratkom vremenskom okviru, kao što su sekunde, poznato je kao napad grubom silom .
Nakon što Haker potvrdi ispravne adrese e-pošte u aplikaciji za teretanu, još jedan vjerodostojan način može biti kreiranje phishing e-pošte.
Phishing je vrsta napada društvenog inženjeringa koji ima za cilj da navede pojedince da otkriju osjetljive informacije, kao što su korisnička imena, lozinke, brojevi kreditnih kartica ili bilo koje druge lične podatke.
S obzirom na to da je jedina zajednička karakteristika ovih adresa e-pošte do sada aplikacija za teretanu, uvjerljiv predmet za phishing e-poštu mogao bi biti „Nabavite besplatan mjesec!“ ili „Nabavite besplatnu ličnu obuku“.
Korisnik samo treba da klikne dugme i unese podatke za prijavu da bi učestvovao u nagradnoj igri.
Sada, ako haker namjerava ciljati jednog korisnika, može koristiti OSINT alate da locira profile društvenih medija koji su povezani s adresom e-pošte korisnika.
Koristeći informacije iz ovih profila, haker može pristupiti korisniku, uspostaviti vezu, a zatim poslati ciljane phishing poruke.
Koristeći OSINT alate, također je moguće otkriti telefonski broj određenog korisnika.
U ovom slučaju, kada haker ima i adresu e-pošte i telefonski broj korisnika, moguće je kombinovati i phishing i vishing taktiku za izvođenje napada socijalnog inženjeringa. Vishing je oblik phishinga koji koristi glasovne pozive.
Najbolje prakse za jačanje sigurnosti API-ja
Dakle, kako možemo spriječiti da se “401 neovlašteno” i “403 zabranjeno” pretvore u veći problem? Iako su HTTP statusni kodovi veoma vrijedni za programere prilikom kreiranja i rješavanja problema na web aplikacijama, oni također mogu pružiti korisne tragove hakerima kao što smo do sada vidjeli.
Jedna potencijalna preventivna mjera može biti praćenje GitHubove tehnike i vraćanje „404 Not found“ umjesto „401 Unauthorized“ ili „403 Forbidden“. Ova tehnika pomaže u poboljšanju sigurnosti ne otkrivajući da li resurs postoji ili kada je pristup neovlašten ili zabranjen.
Ipak, ova tehnika može zbuniti programere, pa je dobra praksa uključiti je u dokumentaciju API-ja kako biste bili sigurni da su o tome obaviješteni.
Još jedna potencijalna preventivna mjera može biti zamjena adrese e-pošte korisnika u API zahtjevu nasumičnim i nesekventnim identifikatorom, sastavljenim od slova i brojeva. Također možete odabrati da kombinujete ovu mjeru sa prethodnom.
Osim toga, takođe je bitno edukovati korisnike o postojanju i opasnostima phishing i vishing napada, kako bi se osiguralo da se osjetljive informacije ne otkrivaju. Takođe je važno uvijek provjeriti identitet pozivaoca, u slučaju „vishing“ poziva, ili pošiljaoca, u slučaju phishing e-pošte.
Da bi potvrdili identitet pozivaoca, korisnici mogu prekinuti vezu i direktno nazvati teretanu kako bi utvrdili da li je poziv bio legitiman. U slučaju phishing e-pošte, korisnici ne bi trebali kliknuti na bilo koju vezu ili dati bilo kakve osjetljive informacije bez potvrde da je e-mail zaista poslao neko ko radi u teretani.
Kršenje u stvarnom svijetu: primjer Duolinga
U ovom članku smo se fokusirali na aplikaciju u teretani; međutim, mogli smo odabrati bilo koju drugu vrstu aplikacije kao primjer, u rasponu od aplikacije za rezervacije do aplikacije za učenje jezika.
Posljednjih godina bili smo svjedoci nekoliko proboja podataka u kojima su hakeri mogli pristupiti korisničkim podacima jednostavno koristeći njihovu e-mail adresu.
Jedan značajan primjer je breach podataka Duolinga, gdje je legitimna e-pošta poslana na Duolingo API vraća generičke informacije o računu za korisnika.
Ovaj ranjivi API doveo je do breach-a podataka za 2,6 miliona korisnika Duolinga na hakerskom forumu. Ako niste upoznati s Duolingom, to je široko korištena aplikacija za učenje jezika s preko 74 miliona korisnika mjesečno.
Narušeni podaci, koji su uključivali prava imena, imena za prijavu, adrese e-pošte i druge detalje vezane za interne usluge, prvobitno su ponuđeni na prodaju na jednom hakerskom forumu u januaru 2023. za 1500 dolara.
U ovom slučaju, korisnici Duolinga nisu mogli učiniti ništa osim da budu na oprezu u slučaju da budu meta phishing e-poruka.
Balansiranje funkcionalnosti i sigurnosti
U zaključku, razumijevanje HTTP statusnih kodova je od suštinskog značaja za programere, jer oni saopštavaju rezultate zahtjeva i pomažu u rješavanju problema. Međutim, programeri moraju uspostaviti ravnotežu između ponude smislenih odgovora i osiguravanja sigurnosti aplikacije.
Vodeći računa o potencijalnim rizicima povezanim s detaljnim statusnim porukama, programeri mogu zaštititi aplikacije i njihove korisnike, a da pritom i dalje pružaju pozitivno korisničko iskustvo.
Izvor. CyberSecurityNews
