Ranljivosti OAuth: Ko overitev gre narobe

OAuth 2.0 je prevladujoc avtorizacijski okvir na sodobnem spletu, ki poganja "Prijavo z Google", "Prijavo s Facebook" in neskoncno integracij tretjih oseb. Njegova prilagodljivost je hkrati njegova mocna stran in sibkost: vec vrst pooblastil in implementacijskih izbir vsaka uvaja priloznosti za varnostne napake. Po mojih izkusnjah ranljivosti OAuth pogosto vodijo do popolnega prevzema racuna ali eskalacije privilegijev -- med ugotovitvami z najvecjim vplivom pri penetracijskem testu.

Pregled toka OAuth 2.0

Tok avtorizacijske kode deluje takole: odjemalec preusmeri uporabnika na avtorizacijski streznik s parametri client_id, redirect_uri, scope in state. Po overitvi streznik preusmeri nazaj z avtorizacijsko kodo, ki jo odjemalec zamenja za dostopni zeton. Vsak korak predstavlja priloznost za napad.

Implicitni tok vrne dostopni zeton neposredno v fragmentu URL, kar ga izpostavlja v zgodovini brskalnika, glavah referrer in dnevnikih streznika. Najboljse varnostne prakse OAuth (RFC 9700) zdaj izrecno odsvetujejo ta tok v prid toku avtorizacijske kode s PKCE.

Izkoriščanje odprtih preusmeritev

Parameter redirect_uri je najkriticnejsi vektor napada OAuth. Ce napadalec vpliva na to, kam je poslana avtorizacijska koda, jo ukrade. Tehnike obvoda vkljucujejo:

• Manipulacija poti - Dodajanje /callback/../attacker-page, ko je preverjena samo osnovna domena.
• Razlike pri razclenjevanju URL - Obratne posevnice, URL-kodirani znaki (%2F, %23) ali unicode, ki povzrocijo razlicno interpretacijo med validatorjem in brskalnikom.
• Verizenje odprtih preusmeritev - Poiscite odprto preusmeritev na legitimni domeni (npr. /login?next=https://attacker.com) in jo uporabite kot redirect_uri. Streznik potrdi domeno, aplikacija pa posreduje kodo napadalcu.
• Prevzem poddomene - Ce validacija dovoljuje *.example.com in ima poddomena visechi DNS, jo napadalec zahteva za prejemanje avtorizacijskih kod.

CSRF preko manjkajocega parametra state

Parameter state deluje kot zeton CSRF. Brez njega napadalec zacne tok OAuth s svojim racunom in pretenta zrtev, da ga dokonca, s cimer poveze napadalcevo identiteto tretje osebe z racunom zrtve za trajni dostop. Testirajte z odstranitvijo parametra state, zamenjavo s prazno vrednostjo ali ponovno uporabo state iz druge seje -- in preverite, ali povratni klic se vedno uspe.

Uhajanje zetonov in nevarna hramba

Zetoni in avtorizacijske kode uhajajo prek vec kanalov: glave Referer, ko stran povratnega klica nalaga zunanje vire, zgodovine brskalnika, ki shranjuje kode iz parametrov poizvedbe, dnevnikov dostopa streznika in CDN ter uporabnikov, ki nevede kopirajo URL-je povratnih klicev v zahtevke za podporo. Ta tveganja so ojacana pri implicitnem toku, kjer se zetoni pojavljajo neposredno v fragmentih URL.

Hramba na strani odjemalca doloca izpostavljenost XSS. Zetoni v localStorage so dostopni vsakemu JavaScriptu na strani, vkljucno z vrinjenimi skriptami. Najvarnejsi pristop za brskalnik so piskotki httpOnly, Secure, SameSite, nedostopni JavaScriptu. Mobilne aplikacije naj uporabljajo platformske obeske za kljuce (iOS Keychain, Android Keystore) namesto skupnih nastavitev.

Napadi toka avtorizacijske kode

• Ponovna uporaba kode - Kode morajo biti po specifikaciji za enkratno uporabo. Zajemite veljavno kodo in jo zamenjajte veckrat. Robusten streznik preklice vse zetone iz ponovno uporabljene kode.
• Obvod redirect_uri pri zamenjavi - Nekateri strezniki preverijo redirect_uri med avtorizacijo, ne pa med zamenjavo zetonov, kar omogoca zamenjavo kod, pridobljenih prek manipuliranih URI-jev, z legitimnim URI-jem.
• Manjkajoci PKCE - Brez Proof Key for Code Exchange je mogoce prestrezene avtorizacijske kode (prek zlonamernih aplikacij, registriranih za isto shemo URI, ali kompromitiranih preusmeritev) zamenjati za zetone. Preverite code_challenge v avtorizacijskih zahtevah in code_verifier v zahtevah za zamenjavo.
• Izpostavljenost skrivnosti odjemalca - Javni odjemalci ne morejo varno shraniti skrivnosti. Pridobite vgrajene skrivnosti z obratnim inzeniringom aplikacije za zamenjavo prestrezhenih kod.

Vpliv v realnem svetu

To niso teoreticna tveganja. Prevzem racuna prek manipulacije redirect_uri je prizadel velike platforme. Napadi CSRF so omogocili povezovanje zlonamernih racunov s profili zrtev za trajni dostop. Uhajanje zetonov prek napacnega belezenja je izpostavilo uporabniske podatke. Te ranljivosti se redno pojavljajo v programih nagrajevanja hroscev in penetracijskih testih.

Metodologija testiranja

1. Preslikajte implementacijo - Prepoznajte vrste pooblastil, ponudnika OAuth, obsege in hrambo zetonov. Prestrezzite celoten tok v Burp Suite.
2. Testirajte redirect_uri - Poskusite prehod po poteh, onesnazevanje parametrov, trike kodiranja in verizenje z odprtimi preusmeritvami.
3. Preverite obravnavo state - Odstranite state, uporabite prazne in medsejne vrednosti, potrdite zavrnitev.
4. Testirajte obravnavo kode - Predvajajte kode, zamenjajte iz manipuliranih redirect_uri-jev, preverite kratek iztek.
5. Preverite PKCE - Oddajte zamenjavo zetonov brez code_verifier za preverjanje uveljavljanja.
6. Analizirajte zetone - Preverite hrambo, iztek, preklic in rotacijo zetonov za osvezitev.
7. Testirajte eskalacijo obsega - Zahtevajte administratorske obsege preko obicajne uporabe.

Orodja

• Burp Suite - Prestrezanje in spreminjanje tokov OAuth. Logger++ sledi verigam preusmeritev. Repeater omogoca natancno manipulacijo parametrov.
• EsPReSSO - Razsiritev Burp za testiranje protokolov SSO vkljucno z OAuth in OpenID Connect.
• Razvojna orodja brskalnika - Zavihek Omrezje za verige preusmeritev, zavihek Aplikacija za hrambo zetonov, glave za uhajanje Referer.
• Postman - Sestavljanje zahtev za zamenjavo zetonov, testiranje ponovne uporabe kode in eksperimentiranje s kombinacijami parametrov.

Odprava

Uporabite tok avtorizacijske kode s PKCE za vse vrste odjemalcev. Validirajte redirect_uri z natancnim ujemanjem nizov, ne vzorci. Vedno validirajte kriptografsko nakljucen parameter state. Zagotovite enkratne avtorizacijske kode s kratkim iztekom (pod 10 minut), vezane na zahtevajocega odjemalca in redirect_uri. Shranjujte zetone v piskotkih httpOnly ali varni platformski hrambi, nikoli v localStorage. Rotirajte zetone za osvezitev ob uporabi in nastavite razumne case izteka za dostopne zetone. Belezite vse dogodke OAuth za varnostni nadzor, vkljucno z neuspelimi validacijami in anomalijami zamenjave zetonov.