Ranljivosti OAuth: Ko overitev gre narobe

OAuth 2.0 je prevladujoč avtorizacijski okvir na sodobnem spletu, ki poganja "Prijavo z Google", "Prijavo s Facebook" in neskončno integracij tretjih oseb. Njegova prilagodljivost je hkrati njegova močna stran in šibkost: več vrst pooblastil in implementacijskih izbir vsaka uvaja priložnosti za varnostne napake. Po mojih izkušnjah ranljivosti OAuth pogosto vodijo do popolnega prevzema računa ali stopnjevanja pravic -- med ugotovitvami z največjim vplivom pri penetracijskem testu.

Zahteve za preverjanje preusmeritev in zaščito avtorizacijskih kod določa RFC 9700: Best Current Practice for OAuth 2.0 Security.

Pregled toka OAuth 2.0

Tok avtorizacijske kode deluje takole: odjemalec preusmeri uporabnika na avtorizacijski strežnik s parametri client_id, redirect_uri, scope in state. Po overitvi strežnik preusmeri nazaj z avtorizacijsko kodo, ki jo odjemalec zamenja za dostopni žeton. Vsak korak predstavlja priložnost za napad.

Implicitni tok vrne dostopni žeton neposredno v fragmentu URL, kar ga izpostavlja v zgodovini brskalnika, glavah referrer in dnevnikih strežnika. Najboljše 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 najkritičnejši vektor napada OAuth. Če napadalec vpliva na to, kam je poslana avtorizacijska koda, jo ukrade. Tehnike obvoda vključujejo:

• Manipulacija poti - Dodajanje /callback/../attacker-page, ko je preverjena samo osnovna domena.
• Razlike pri razčlenjevanju URL - Obratne poševnice, URL-kodirani znaki (%2F, %23) ali unicode, ki povzročijo različno interpretacijo med validatorjem in brskalnikom.
• Veriženje odprtih preusmeritev - Poiščite odprto preusmeritev na legitimni domeni (npr. /login?next=https://attacker.com) in jo uporabite kot redirect_uri. Strežnik potrdi domeno, aplikacija pa posreduje kodo napadalcu.
• Prevzem poddomene - Če validacija dovoljuje *.example.com in ima poddomena viseči DNS, jo napadalec zahteva za prejemanje avtorizacijskih kod.

CSRF preko manjkajočega parametra state

Parameter state deluje kot žeton CSRF. Brez njega napadalec začne tok OAuth s svojim računom in pretenta žrtev, da ga dokonča, s čimer poveže napadalcevo identiteto tretje osebe z računom žrtve za trajni dostop. Testirajte z odstranitvijo parametra state, zamenjavo s prazno vrednostjo ali ponovno uporabo state iz druge seje -- in preverite, ali povratni klic še vedno uspe.

Uhajanje žetonov in nevarna hramba

Žetoni in avtorizacijske kode uhajajo prek več kanalov: glave Referer, ko stran povratnega klica nalaga zunanje vire, zgodovine brskalnika, ki shranjuje kode iz parametrov poizvedbe, dnevnikov dostopa strežnika in CDN ter uporabnikov, ki nevede kopirajo URL-je povratnih klicev v zahtevke za podporo. Ta tveganja so ojačana pri implicitnem toku, kjer se žetoni pojavljajo neposredno v fragmentih URL.

Hramba na strani odjemalca določa izpostavljenost XSS. Žetoni v localStorage so dostopni vsakemu JavaScriptu na strani, vključno z vrinjenimi skriptami. Najvarnejši pristop za brskalnik so piškotki httpOnly, Secure, SameSite, nedostopni JavaScriptu. Mobilne aplikacije naj uporabljajo sistemske shrambe ključev (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 večkrat. Robusten strežnik prekliče vse žetone iz ponovno uporabljene kode.
• Obvod redirect_uri pri zamenjavi - Nekateri strežniki preverijo redirect_uri med avtorizacijo, ne pa med zamenjavo žetonov, kar omogoča zamenjavo kod, pridobljenih prek manipuliranih URI-jev, z legitimnim URI-jem.
• Manjkajoči PKCE - Brez Proof Key for Code Exchange je mogoče prestrežene avtorizacijske kode (prek zlonamernih aplikacij, registriranih za isto shemo URI, ali kompromitiranih preusmeritev) zamenjati za žetone. 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 inženiringom aplikacije za zamenjavo prestreženih kod.

Vpliv v realnem svetu

To niso teoretična tveganja. Prevzem računa prek manipulacije redirect_uri je prizadel velike platforme. Napadi CSRF so omogočili povezovanje zlonamernih računov s profili žrtev za trajni dostop. Uhajanje žetonov prek napačnega beleženja je izpostavilo uporabniške podatke. Te ranljivosti se redno pojavljajo v programih nagrajevanja odkritih ranljivosti in penetracijskih testih.

Metodologija testiranja

1. Preslikajte implementacijo - Prepoznajte vrste pooblastil, ponudnika OAuth, obsege in hrambo žetonov. Prestrezite celoten tok v Burp Suite.
2. Testirajte redirect_uri - Poskusite prehod po poteh, onesnaževanje parametrov, trike kodiranja in veriženje z odprtimi preusmeritvami.
3. Preverite obravnavo state - Odstranite state, uporabite prazne in medsejne vrednosti, potrdite zavrnitev.
4. Testirajte obravnavo kode - Ponovno uporabite kode, zamenjajte iz manipuliranih redirect_uri-jev, preverite kratek iztek.
5. Preverite PKCE - Oddajte zamenjavo žetonov brez code_verifier za preverjanje uveljavljanja.
6. Analizirajte žetone - Preverite hrambo, iztek, preklic in rotacijo žetonov za osvežitev.
7. Testirajte eskalacijo obsega - Zahtevajte administratorske obsege preko običajne uporabe.

Orodja

• Burp Suite - Prestrezanje in spreminjanje tokov OAuth. Logger++ sledi verigam preusmeritev. Repeater omogoča natančno manipulacijo parametrov.
• EsPReSSO - Razširitev Burp za testiranje protokolov SSO vključno z OAuth in OpenID Connect.
• Razvojna orodja brskalnika - Zavihek Omrežje za verige preusmeritev, zavihek Aplikacija za hrambo žetonov, glave za uhajanje Referer.
• Postman - Sestavljanje zahtev za zamenjavo žetonov, testiranje ponovne uporabe kode in eksperimentiranje s kombinacijami parametrov.

Odprava

Uporabite tok avtorizacijske kode s PKCE za vse vrste odjemalcev. Validirajte redirect_uri z natančnim ujemanjem nizov, ne vzorci. Vedno validirajte kriptografsko naključen parameter state. Zagotovite enkratne avtorizacijske kode s kratkim iztekom (pod 10 minut), vezane na zahtevajočega odjemalca in redirect_uri. Shranjujte žetone v piškotkih httpOnly ali varni platformski hrambi, nikoli v localStorage. Rotirajte žetone za osvežitev ob uporabi in nastavite ustrezne čase izteka za dostopne žetone. Beležite vse dogodke OAuth za varnostni nadzor, vključno z neuspelimi validacijami in anomalijami zamenjave žetonov.

Sorodno branje: Varnost JWT: Pogoste napake in kako jih izkoriščati in Microsoft 365 in Entra ID: zmanjšanje izpostavljenosti prevzemu računov.