Ovaj članak će se baviti poznatim oauth ranjivosti. Čitatelji će također naučiti kako implementirati sigurno i sigurno odobrenje u web aplikaciji.
Oauth je pouzdan protokol, ali njegov stupanj sigurnosti u velikoj mjeri ovisi o svijesti o web programerima pri provedbi odobrenja. To čini ovu temu iznimno važnom za profesionalce za informacijske sigurnosti. Oni moraju osigurati visoku razinu zaštite računa svojih korisnika. Vrijeme je da se upoznate s učinkovitim praktičarima koji će pomoći smanjiti opasnost od loše prodaje OAuth.
UvodProtokol OAuth 2.0 trenutno se široko koristi u različitim primjenama. Koristeći ga, prikladno korisničko sučelje postaje dostupno, lakše provjeru autentičnosti i autorizacije u usporedbi s tradicionalnim metodama za unos korisničkog imena i zaporke. Uz pravilnu i promišljenu provedbu, Oauth protokol će biti sigurniji od tradicionalnog odobrenja, jer korisnici ne moraju dijeliti svoje računovodstvene podatke s aplikacijom treće strane za pristup određenom resursu. Korisnici često vole prijaviti se koristeći svoje Google račune, Facebook ili LinkedIn, umjesto stvaranja novog računa svaki put kada trebate registrirati na nekoj web stranici. Dakle, oauth protokol uvelike pojednostavljuje naše živote.
Općenito, popularni pružatelji usluga oauth su vrlo pouzdan. Prijavite se s Google ili Facebook računom inspirira određeni osjećaj sigurnosti i to je točno. Protokol je pažljivo testiran od strane stručnjaka. Sve dostupne ranjivosti uvijek se brzo ispravljaju tim za razvojne programere. Međutim, vrijedi napomenuti da osjećaj potpune sigurnosti može biti lažan.
Oauth davatelji usluga ostavili su programerima aplikacije puno razloga za borbu protiv sigurnosti njihovih programa. Zapravo, početno zaštićena OAUTH usluga, nepravilno provedena u procesu njezine instalacije može postati jednostavan cilj za uljeze. Takva preokuparnost će dovesti do krađe osobnih podataka korisnika.
Zatim biste trebali razmotriti najčešće ranjivosti naišli na aplikacije trećih strana koje provode Oauth Protocol za autoriziranje svojih korisnika. Mora se pamtiti da je sam protokol siguran i pouzdan. Tek nakon netočne implementacije postaje ranjiv na hakerski napadi.
Oauth Tockey krađa pomoću zaglavlje o upućivačeKada aplikacija zatraži odobrenje u ime korisnika na OAUTH poslužitelju, osoba dobiva kôd za unos i slanje natrag na poslužitelj za naknadnu provjeru. Ako tijekom rada korisnik će biti preusmjeren na drugu stranicu, kod će se vidjeti u zaglavlju "Refereer" HTTP zahtjeva. Dakle, kod će pasti na vanjsku web-lokaciju, koja će ugroziti korisničke podatke registrirane na OAUTH poslužitelju.
Napomena: Zaglavlje uputača je zaglavlje HTTP upita, prenosi URL host iz kojeg se šalje zahtjev.
Da bi omekšali posljedice ove ranjivosti, programer mora osigurati da njegova web aplikacija ne sadrži bilo koju HTML injekcije. Ako se otkriju injekcije, napadač može lako postaviti oznaku slike na svoj web poslužitelj i pronaći način da preusmjerite korisnika na njemu. Dakle, on će dobiti priliku ukrasti kôd od zaglavlje "Refereer" HTTP zahtjeva.
Oauth Tockey krađa pomoću parametra Redirect_uriAplikacija pokreće postupak autorizacije slanjem zahtjeva za OAUTH Server:
https://www.example.com/sign/authorize? scredirect_uri=https://demo.example.com/loginsuccessful.
Upit uvijek sadrži parametar "Redirect_uri" koji koristi OAuth poslužitelj za slanje tokena natrag u aplikaciju nakon što je korisnik dao pristanak. Ako se vrijednost ovog parametra ne kontrolira ili ne provjerava, napadač ga lako može promijeniti i preusmjeriti zahtjev na svoju web-lokaciju, gdje koristi poseban program za obradu tokena i pristup pristupu ograničenom resursu.
https://www.example.com/sign/authorize? g .]&redirect_uri=https://localhost.evil.com.
Ponekad su slični URL-ovi blokirani. Napadač može preusmjeriti primljene podatke na otvorenom URL-u, ovako:
https://www.example.com/oauth20_authorize.srf? \ t
Ili ovo:
https://www.example.com/oauth2/autorize? [...]% IRT_URI = HTTPS% 3A% 2F% 2FAPPS.FACEBOOK.com% 2Fatchacker% 2f.
Prilikom provedbe OAUTH, nikada ne možete uključiti cijele domene na bijeli popis. Samo nekoliko URL-ova treba dodati u "Redirect_uri" nije preusmjeren zahtjev za otvaranje preusmjeravanja.
Krivotvorenje križnih zahtjevaKrivotvorenje Zahtjev za sjecište može se pojaviti kada napadač uspije u stvaranju žrtve da klikne na svoj link i, dakle, generirati zahtjev koji neće generirati. Krivotvorenje na cross-line zahtjevima obično se omekšava s CSRF tokenom, koji je povezan s korisničkom sesijom. Pomaže aplikaciji da provjeri osobu osobe koja je poslala zahtjev. "State" parametar u OAuth protokolu služi kao CSRF token.
Vrijedi pregledati kako se napad CSRF provodi na OAUTH i kako se "stanje" parametar može koristiti za ublažavanje učinaka ranjivosti.
Hacker otvara web aplikaciju i pokreće proces autorizacije za pristup davatelju usluga koristeći OAUTH. Aplikacija traži davatelja usluga za pristup koji treba osigurati. Haker će biti preusmjeren na web stranicu davatelja usluga, gdje obično trebate unijeti svoje korisničko ime i lozinku za autorizaciju pristupa. Umjesto toga, haker hvata i sprječava taj zahtjev i sprema svoj URL. Haker nekako uzrokuje žrtvu da otvori ovaj URL. Ako je žrtva ušla u sustav davatelja usluga koristeći svoj račun, tada će se njegove vjerodajnice koristiti za izdavanje ovlaštenog koda. Kod autorizacije razmjenjuje pristup toku pristupa. Sada je ovlašten na hakerski račun u aplikaciji. Može pristupiti računu žrtve.
Dakle, kako mogu spriječiti ovu situaciju koristeći "državni" parametar?
Aplikacija mora stvoriti vrijednost koja se nekako na temelju izvodnog računa (na primjer, koristite korisničku sesiju HASH ključ). To nije tako važno što je, glavna stvar je da je vrijednost jedinstvena i generirana pomoću privatnih informacija o izvornom korisniku. Dodijeljen je "državnom" parameru.
Ova se vrijednost prenosi pružatelju usluga prilikom preusmjeravanja. Sada haker poziva žrtvu da otvori URL, koji je zadržao.
Kodeks autorizacije izdaje se i šalje natrag klijentu na sjednici zajedno s "državnim" parametrom.
Klijent generira vrijednost parametra na temelju informacija o sesiji i uspoređuje ga s "državnom" vrijednost, koja je poslana od zahtjeva za autorizaciju na davatelja usluga. Ova vrijednost ne odgovara "stanje" parametra u upitu, budući da je generiran samo na temelju informacija o trenutnoj sesiji. Kao rezultat toga, dobivena vrijednost ne prihvaća sustav.
Ostale ranjivosti otkrivene prilikom provedbe OAuth uključuju mogućnost obavljanja XSS-a (skriptiranje poprečnog mjesta) pomoću parametra "Redirect_uri", postavka privatnog ključa OAUTH (Ključ se ponekad može dobiti prilikom dekompiliranja mobilne aplikacije) i kršenja pravila o autorizaciji (kada Komd za autorizaciju može se koristiti više od jednom za izdavanje više tokena pristupa). Ove ranjivosti su manje uobičajene od gore opisanih, ali ih ne čini manje opasnim. Developer bi trebao znati sve potrebne prakse kako bi se osiguralo pouzdano djelovanje svoje web aplikacije.
Autor prevedenog članka: Simon Saliba.
Važno! Informacije isključivo u akademske svrhe. Pridržavajte se zakonodavstva i nemojte primjenjivati te podatke za nezakonite svrhe.
Zanimljiviji materijal na cisoklolub.ru. Pretplatite se na nas: Facebook | VK | Twitter | Instagram | Telegram | Zen | Messenger | ICQ Novo | Youtube | Puls.