OAuth to Account takeover

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Basiese Inligting

OAuth bied verskeie weergawes, met grondliggende insigte beskikbaar by OAuth 2.0 documentation. Hierdie bespreking fokus hoofsaaklik op die algemeen gebruikte OAuth 2.0 authorization code grant type, wat ’n authorization framework verskaf wat ’n toepassing in staat stel om toegang te kry of aksies uit te voer op ’n gebruiker se rekening in ’n ander toepassing (the authorization server).

Oorweeg ’n hipotetiese webwerf https://example.com, ontwerp om al jou sosiale media-plasings te vertoon, insluitend privaat plasings. Om dit te bereik word OAuth 2.0 gebruik. https://example.com sal jou toestemming vra om toegang tot jou sosiale media-plasings te kry. Gevolglik sal ’n toestemmingskerm op https://socialmedia.com verskyn, wat die permisse wat gevra word en die ontwikkelaar wat die versoek doen uiteensit. Na jou toestemming kry https://example.com die vermoë om jou plasings namens jou te benader.

Dit is noodsaaklik om die volgende komponente binne die OAuth 2.0 raamwerk te verstaan:

  • resource owner: Jy, as die gebruiker/entiteit, verleen toestemming vir toegang tot jou bron, soos jou sosiale media-rekening se plasings.
  • resource server: Die bediener wat geverifieerde versoeke hanteer nadat die toepassing ’n access token namens die resource owner verkry het, bv. https://socialmedia.com.
  • client application: Die toepassing wat toestemming soek van die resource owner, soos https://example.com.
  • authorization server: Die bediener wat access tokens uitreik aan die client application nadat die resource owner suksesvol geverifieer is en toestemming gegee het, bv. https://socialmedia.com.
  • client_id: ’n openbare, unieke identifiseerder vir die toepassing.
  • client_secret: ’n vertroulike sleutel, bekend aan die toepassing en die authorization server alleenlik, wat gebruik word vir die generering van access_tokens.
  • response_type: ’n waarde wat spesifiseer die tipe token wat versoek word, soos code.
  • scope: Die toegangsvlak wat die client application van die resource owner versoek.
  • redirect_uri: Die URL waarna die gebruiker na toestemming herlei word. Dit moet gewoonlik ooreenstem met die vooraf-geregistreerde redirect URL.
  • state: ’n parameter om data oor die gebruiker se herleiding na en van die authorization server te behou. Die uniekheid daarvan is kritiek om as ’n CSRF-beskermingsmeganisme te dien.
  • grant_type: ’n parameter wat aandui die grant type en die tipe token wat teruggegee sal word.
  • code: Die authorization code van die authorization server, gebruik saam met client_id en client_secret deur die client application om ’n access_token te verkry.
  • access_token: Die token wat die client application gebruik vir API-versoeke namens die resource owner.
  • refresh_token: Maak dit vir die toepassing moontlik om ’n nuwe access_token te bekom sonder om die gebruiker weer te vra.

Flow

Die werklike OAuth-flow verloop soos volg:

  1. Jy navigeer na https://example.com en kies die “Integrate with Social Media” knop.
  2. Die webwerf stuur dan ’n versoek na https://socialmedia.com en vra jou toestemming om https://example.com se toepassing toe te laat om jou plasings te benader. Die versoek is gestruktureer soos:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
  1. Nadat jy jou goedkeuring gegee het, kry jy dan ’n toestemmingbladsy aangebied.
  2. Nadat jy jou goedkeuring gegee het, stuur Sosiale Media ’n reaksie na die redirect_uri met die code en state parameters:
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com gebruik hierdie code, tesame met sy client_id en client_secret, om ’n server-side versoek te maak om access_token namens jou te verkry, wat toegang gee tot die toestemmings waartoe jy ingestem het:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Finally, the process concludes as https://example.com employs your access_token to make an API call to Social Media to access

Kwetsbaarhede

Oop redirect_uri

Per RFC 6749 §3.1.2, the authorization server must redirect the browser only to pre-registered, exact redirect URIs. Any weakness here lets an attacker send a victim through a malicious authorization URL so that the IdP delivers the victim’s code (and state) straight to an attacker endpoint, who can then redeem it and harvest tokens.

Tipiese aanval-werkvloei:

  1. Stel https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback op en stuur dit na die slagoffer.
  2. Die slagoffer autentiseer en keur die scopes goed.
  3. Die IdP herlei na attacker.tld/callback?code=<victim-code>&state=... waar die aanvaller die versoek log en onmiddellik die code inwissel.

Algemene valideringsfoute om te ondersoek:

  • Geen validering – enige absolute URL word aanvaar, wat tot onmiddellike code-diefstal lei.
  • Swak substring/regex-kontroles op die host – omseil met lookalikes soos evilmatch.com, match.com.evil.com, match.com.mx, matchAmatch.com, evil.com#match.com, of match.com@evil.com.
  • IDN homograph-ongelykhede – validering gebeur op die punycode-vorm (xn--), maar die blaaier herlei na die Unicode-domein wat deur die aanvaller beheer word.
  • Arbitrary paths on an allowed host – deur redirect_uri na /openredirect?next=https://attacker.tld of enige XSS/user-content endpoint te wys, die code leaks via geketende herleidings, Referer headers, of geïnjekteerde JavaScript.
  • Directory-beperkings sonder normalisering – patrone soos /oauth/* kan omseil word met /oauth/../anything.
  • Wildcard subdomains – die aanvaarding van *.example.com beteken enige takeover (dangling DNS, S3 bucket, etc.) lewer onmiddellik ’n geldige callback.
  • Nie-HTTPS callbacks – deur http:// URIs toe te laat, kry netwerk-aanvallers (Wi-Fi, corporate proxy) die kans om die code onderweg te gryp.

Herbesigtig ook bykomstige redirect-styl parameters (client_uri, policy_uri, tos_uri, initiate_login_uri, etc.) en die OpenID discovery-dokument (/.well-known/openid-configuration) vir addisionele endpoints wat dieselfde valideringsfoute kan erf.

XSS in redirect-implementering

Soos in hierdie bug bounty-verslag https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html vermeld, kan dit moontlik wees dat die redirect URL in die response van die bediener gereflekteer word nadat die gebruiker autentiseer, en sodoende vatbaar vir XSS is. Moontlike payload om te toets:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - Onbehoorlike hantering van die state-parameter

Die state parameter is die Authorization Code flow CSRF-token: die kliënt moet ’n kriptografies ewekansige waarde per blaaier-instansie genereer, dit stoor op ’n plek wat slegs daardie blaaier kan lees (cookie, local storage, ens.), dit in die authorization request stuur, en enige response verwerp wat nie dieselfde waarde teruggee nie. Wanneer die waarde staties, voorspelbaar, opsioneel, of nie aan die gebruiker se sessie gekoppel is nie, kan die aanvaller hul eie OAuth-flow voltooi, die finale ?code= request onderskep (sonder om dit te stuur), en later ’n slagoffer se blaaier dwing om daardie request te herhaal sodat die slagoffer se rekening aan die aanvaller se identity provider-profiel gekoppeld raak.

Die replay-patroon is altyd dieselfde:

  1. Die aanvaller autentiseer by die IdP met hul rekening en onderskep die laaste redirect wat die code (en enige state) bevat.
  2. Hulle drop daardie request, hou die URL, en misbruik later enige CSRF-primitive (skakel, iframe, outo-inhandigende vorm) om die slagoffer se blaaier dit te laat laai.
  3. As die kliënt state nie afdwing nie, verbruik die toepassing die aanvaller se authorization-resultaat en meld die aanvaller by die slagoffer se app-rekening aan.

’n Praktiese kontrolelys vir state hantering tydens toetse:

  • Missing state entirely – as die parameter nooit verskyn nie, is die hele login CSRFable.
  • state not required – verwyder dit uit die aanvanklike request; as die IdP steeds codes uitreik wat die kliënt aanvaar, is die verdediging opsioneel.
  • Returned state not validated – manipuleer die waarde in die response (Burp, MITM proxy). Aanvaarding van ongelyke waardes beteken die gestoor token word nooit vergelyk nie.
  • Predictable or purely data-driven state – baie apps stop redirect-paaie of JSON-blokke in state sonder om ewekansigheid by te meng, wat aanvallers toelaat om geldige waardes te raai en flows te herhaal. Voeg altyd sterk entropie voor of na data voordat jy dit enkodeer.
  • state fixation – as die app gebruikers toelaat om die state waarde te voorsien (bv. via vervaardigde authorization URLs) en dit deur die hele flow hergebruik, kan ’n aanvaller ’n bekende waarde inslot en dit oor slagoffers hergebruik.

PKCE kan state aanvul (veral vir public clients) deur die authorization code aan ’n code verifier te bind, maar web-kliënte moet steeds state volg om cross-user CSRF/account-linking bugs te voorkom.

Pre Account Takeover

  1. Without Email Verification on Account Creation: Aanvallers kan vooraf ’n rekening skep met die slagoffer se e-pos. As die slagoffer later ’n derdeparty-diens vir login gebruik, kan die toepassing per ongeluk daardie derdeparty-rekening aan die aanvaller se vooraf-geskepte rekening koppel, wat tot ongemagtigde toegang lei.
  2. Exploiting Lax OAuth Email Verification: Aanvallers kan OAuth-dienste wat nie e-posse verifieer nie misbruik deur by hul diens te registreer en dan die rekening-e-pos na die slagoffer se e-pos te verander. Hierdie metode stel op ’n soortgelyke wyse die rekening bloot aan ongemagtigde toegang, soos in die eerste scenario, maar deur ’n ander aanvalsvector.

Disclosure of Secrets

Die client_id is doelbewus publiek, maar die client_secret mag nooit deur eindgebruikers herstelbaar wees nie. Authorization Code-implementasies wat die secret in mobile APKs, desktop clients, or single-page apps inkorporeer, gee daardie geloofsbrief effektief aan enigiemand wat die pakket kan aflaai. Inspekteer altyd public clients deur:

  • Die APK/IPA, desktop-installer, of Electron-app uit te pak en te grep vir client_secret, Base64-blikke wat na JSON decode, of hard-coded OAuth endpoints.
  • Gebundelde konfigurasielêers (plist, JSON, XML) of gedecompileerde stringe vir kliëntgeloofsbriewe te hersien.

Sodra die aanvaller die secret onttrek, hoef hulle net enige slagoffer se authorization code (via ’n swak redirect_uri, logs, ens.) te steel om onafhanklik /token te tref en access/refresh tokens te mint sonder die legitieme app. Beskou public/native clients as onvermoë om secrets te hou—hulle moet in plaas daarvan op PKCE (RFC 7636) staatmaak om besit van ’n per-instansie code verifier te bewys in plaas van ’n statiese secret. Bevestig tydens toetse of PKCE verpligtend is en of die backend token-uitruilings werklik verwerp wat óf die client_secret of ’n geldige code_verifier weglate.

Client Secret Bruteforce

You can try to bruteforce the client_secret of a service provider with the identity provider in order to be try to steal accounts.
The request to BF may look similar to:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer Header leaking Code + State

Once the client has the code and state, if it’s reflected inside the Referer header when he browses to a different page, then it’s vulnerable.

Access Token In blaaiersgeskiedenis gestoor

Die kernwaarborg van die Authorization Code grant is dat access tokens nooit die resource owner se browser bereik nie. Wanneer implementasies tokens client-side leak, word enige klein fout (XSS, Referer leak, proxy logging) ’n onmiddellike rekeningkompromittering. Kontroleer altyd vir:

  • Tokens in URLs – as access_token in die query/fragment verskyn, beland dit in die blaaiergeskiedenis, serverlogs, analytics, en Referer headers wat aan derdes gestuur word.
  • Tokens transiting untrusted middleboxes – terugstuur van tokens oor HTTP of deur debugging/corporate proxies laat netwerkwaarnemers dit regstreeks vasvang.
  • Tokens stored in JavaScript state – React/Vue stores, global variables, of serialized JSON blobs stel tokens bloot aan elke script op die origin (insluitend XSS payloads of kwaadwillige uitbreidings).
  • Tokens persisted in Web Storage – localStorage/sessionStorage behou tokens lank ná logout op gedeelde toestelle en is deur skripte toeganklik.

Enigeen van hierdie bevindinge verhef gewoonlik andersins “low” bugs (soos ’n CSP bypass of DOM XSS) na ’n volledige API takeover omdat die aanvaller eenvoudig die leaked bearer token kan lees en hergebruik.

Langlewende Authorization Code

Authorization codes must be short-lived, single-use, and replay-aware. Wanneer jy ’n flow evalueer, vang ’n code en:

  • Test the lifetime – RFC 6749 beveel minute aan, nie ure nie. Probeer die code na 5–10 minute inlos; as dit steeds werk, is die blootstellingsvenster vir enige leaked code buitensporig.
  • Test sequential reuse – stuur dieselfde code twee keer. As die tweede versoek nog ’n token lewer, kan aanvallers sessies oneindig kloon.
  • Test concurrent redemption/race conditions – stuur twee token-versoeke parallel (Burp intruder, turbo intruder). Swak uitreikers gee soms albei.
  • Observe replay handling – ’n hergebruikpoging moet nie net misluk nie maar ook enige tokens wat reeds vanaf daardie code gemunt is, intrek. Andersins laat ’n opgespoorde replay die aanvaller se eerste token aktief.

Die kombinasie van ’n replay-vriendelike code met enige redirect_uri of ’n logging bug laat volgehoue rekeningtoegang toe selfs nadat die slagoffer die wettige login voltooi het.

Authorization/Refresh Token nie aan client gebind nie

As jy die authorization code kan kry en dit met ’n ander client gebruik, kan jy ander rekeninge oorneem.

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

Kyk na hierdie pos

AWS Cognito

In this bug bounty report: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ jy kan sien dat die token wat AWS Cognito teruggee aan die gebruiker moontlik genoeg permissions het om die gebruikersdata oor te skryf. Daarom, as jy die gebruiker se e-pos na ’n ander gebruiker se e-pos kan verander, kan jy moontlik ander rekeninge oorneem.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

Vir meer gedetailleerde inligting oor hoe om AWS Cognito te misbruik, kyk na AWS Cognito - Unauthenticated Enum Access.

Misbruik van ander apps se tokens

Soos mentioned in this writeup, OAuth-vloei wat verwag om die token (en nie ’n code nie) te ontvang, kan kwesbaar wees as hulle nie kontroleer dat die token aan die app behoort nie.

Dit is omdat ’n aanvaller ’n toepassing wat OAuth ondersteun en aanmelding met Facebook (byvoorbeeld) in sy eie app kan skep. Sodra ’n slagoffer by Facebook in die aanvaller se toepassing aanmeld, kan die aanvaller die OAuth token van die gebruiker wat aan sy toepassing gegee is kry en dit gebruik om by die slagoffer se OAuth-toepassing aan te meld met die slagoffer se gebruikers-token.

Caution

Daarom, as die aanvaller daarin slaag om die gebruiker te kry om toegang tot sy eie OAuth-toepassing te verleen, sal hy die slagoffer se rekening kan oorneem in toepassings wat ’n token verwag en nie kontroleer of die token aan hul app ID toegekken is nie.

Twee skakels & koekie

Volgens this writeup, was dit moontlik om ’n slagoffer ’n bladsy te laat oopmaak met ’n returnUrl wat na die aanvaller se host wys. Hierdie inligting sou in ’n koekie (RU) gestoor word en in ’n later stap sal die prompt die gebruiker vra of hy toegang aan daardie aanvaller se host wil gee.

Om hierdie prompt te omseil, was dit moontlik om ’n oortjie te open om die OAuth flow te inisieer wat hierdie RU-koekie met die returnUrl sou instel, die oortjie te sluit voordat die prompt gewys word, en ’n nuwe oortjie te open sonder daardie waarde. Dan sal die prompt nie oor die aanvaller se host inlig nie, maar die koekie sal daarop gestel wees, sodat die token in die omleiding na die aanvaller se host gestuur sal word.

Prompt Interaction Bypass

Soos verduidelik in this video, laat sommige OAuth-implementasies toe om die GET-parameter prompt op None aan te dui (&prompt=none) om te verhoed dat gebruikers in die web ’n bevestigingsprompt kry vir die gegewe toegang as hulle reeds by die platform aangemeld is.

response_mode

Soos explained in this video, mag dit moontlik wees om die parameter response_mode aan te dui om te bepaal waar die code in die finale URL verskaf sal word:

  • response_mode=query -> Die code word in ’n GET-parameter verskaf: ?code=2397rf3gu93f
  • response_mode=fragment -> Die code word in die URL-fragment verskaf: #code=2397rf3gu93f
  • response_mode=form_post -> Die code word binne ’n POST-form verskaf met ’n input genaamd code en die waarde
  • response_mode=web_message -> Die code word in ’n post message gestuur: window.opener.postMessage({"code": "asdasdasd...

OAuth toestemming-/login-dialoge is ideale clickjacking-doelwitte: as hulle in ’n frame geplaas kan word, kan ’n aanvaller aangepaste grafika oorlê, die ware knoppies wegsteek en gebruikers mislei om gevaarlike scopes goed te keur of rekeninge te koppel. Bou PoCs wat:

  1. Laai die IdP authorization URL binne ’n <iframe sandbox="allow-forms allow-scripts allow-same-origin">.
  2. Gebruik absolute positioning/opacity-truuks om vals knoppies te belyn met die verborge Allow/Approve-kontroles.
  3. Vul opsioneel parameters vooraf in (scopes, redirect URI) sodat die gesteelde goedkeuring dadelik die aanvaller bevoordeel.

Tydens toetsing verifieer dat IdP-bladsye óf X-Frame-Options: DENY/SAMEORIGIN óf ’n beperkende Content-Security-Policy: frame-ancestors 'none' uitstuur. As geen van beide teenwoordig is nie, demonstreer die risiko met gereedskap soos NCC Group’s clickjacking PoC generator en neem op hoe maklik ’n slagoffer die aanvaller se app magtig. Vir addisionele payload-idees sien Clickjacking.

OAuth ROPC flow - 2 FA bypass

Volgens this blog post, is dit ’n OAuth-vloei wat toelaat om via username en password by OAuth aan te meld. As gedurende hierdie eenvoudige vloei ’n token teruggestuur word met toegang tot alle aksies wat die gebruiker kan uitvoer, is dit moontlik om 2FA te omseil deur daardie token te gebruik.

ATO on web page redirecting based on open redirect to referrer

Hierdie blogpost beskryf hoe dit moontlik was om ’n open redirect na die waarde van die referrer te misbruik om OAuth tot ATO te misbruik. Die aanval was:

  1. Die slagoffer besoek die aanvaller se webblad.
  2. Die slagoffer open die kwaadwillige skakel en ’n opener begin die Google OAuth flow met response_type=id_token,code&prompt=none as bykomende parameters en gebruik die aanvaller se webwerf as referrer.
  3. In die opener, nadat die provider die slagoffer magtig, stuur dit hulle terug na die waarde van die redirect_uri-parameter (slagoffer-web) met ’n 30X-kode wat steeds die aanvaller se webwerf in die referer hou.
  4. Die slagoffer se webblad aktiveer die open redirect gebaseer op die referrer en herlei die gebruiker na die aanvaller se webwerf; aangesien die respose_type id_token,code was, sal die code in die URL se fragment na die aanvaller gestuur word, wat hom toelaat om die gebruiker se rekening via Google op die slagoffer se site oor te neem.

SSRFs parameters

Check this research Vir verdere besonderhede oor hierdie tegniek.

Dynamic Client Registration in OAuth dien as ’n minder voor die hand liggende maar kritieke vektor vir sekuriteitskwesbaarhede, veral vir Server-Side Request Forgery (SSRF)-aanvalle. Hierdie endpoint laat OAuth-servers toe om besonderhede oor kliënttoepassings te ontvang, insluitend sensitiewe URL’s wat uitgebuit kan word.

Key Points:

  • Dynamic Client Registration word dikwels gemapped na /register en aanvaar besonderhede soos client_name, client_secret, redirect_uris, en URL’s vir logo’s of JSON Web Key Sets (JWKs) via POST-versoeke.
  • Hierdie funksie volg spesifikasies soos uiteengesit in RFC7591 en OpenID Connect Registration 1.0, wat parameters insluit wat potensieel vir SSRF kwesbaar is.
  • Die registrasieproses kan bedieners op verskeie maniere aan SSRF blootstel:
    • logo_uri: ’n URL vir die kliënttoepassing se logo wat deur die bediener opgevra kan word, wat SSRF kan veroorsaak of tot XSS lei as die URL sleg hanteer word.
    • jwks_uri: ’n URL na die kliënt se JWK-dokument wat, as dit kwaadwillig saamgestel is, die bediener kan dwing om uitgaande versoeke na ’n aanvaller-beheerde bediener te maak.
    • sector_identifier_uri: Verwys na ’n JSON-array van redirect_uris, wat die bediener dalk sal opvra en sodoende ’n SSRF-kans skep.
    • request_uris: Lys toegelate request URIs vir die kliënt, wat uitgebuit kan word as die bediener hierdie URIs aan die begin van die magtigingsproses opvra.

Exploitation Strategy:

  • SSRF kan getrigger word deur ’n nuwe kliënt te registreer met kwaadwillige URL’s in parameters soos logo_uri, jwks_uri, of sector_identifier_uri.
  • Alhoewel direkte uitbuiting via request_uris deur whitelist-beheer beperk kan wees, kan die verskaffing van ’n vooraf-geregistreerde, aanvaller-beheerde request_uri SSRF fasiliteer tydens die magtigingsfase.

OAuth providers Race Conditions

As die platform wat jy toets ’n OAuth-provider is read this to test for possible Race Conditions.

Mutable Claims Attack

In OAuth identifiseer die sub-veld ’n gebruiker uniek, maar die formaat wissel per Authorization Server. Sommige kliënte gebruik e-posadresse of gebruikershandvatsels vir standaardisering van gebruikeridentifikasie. Dit is egter riskant omdat:

  • Sommige Authorization Servers nie verseker dat hierdie eienskappe (soos e-pos) onveranderlik bly nie.
  • In sekere implementasies — soos “Login with Microsoft” — vertrou die kliënt op die e-posveld, wat deur die gebruiker in Entra ID beheer en nie geverifieer is nie.
  • ’n Aanvaller kan dit uitbuit deur sy eie Azure AD-organisasie te skep (bv. doyensectestorg) en dit te gebruik vir ’n Microsoft-aanmelding.
  • Alhoewel die Object ID (gestoor in sub) onveranderlik en veilig is, kan die vertroue op ’n veranderlike e-posveld ’n account takeover moontlik maak (byvoorbeeld deur ’n rekening soos victim@gmail.com te kaap).

Client Confusion Attack

In ’n Client Confusion Attack versuim ’n toepassing wat die OAuth Implicit Flow gebruik om te verifieer dat die finale access token spesifiek vir sy eie Client ID gegenereer is. ’n Aanvaller stel ’n openbare webwerf op wat Google’s OAuth Implicit Flow gebruik, mislei duisende gebruikers om aan te meld en so access tokens vir die aanvaller se site te oes. As hierdie gebruikers ook rekeninge op ’n ander kwesbare webwerf het wat nie die token se Client ID verifieer nie, kan die aanvaller die geoogste tokens hergebruik om die slagoffers te imiteer en hul rekeninge oor te neem.

Scope Upgrade Attack

Die Authorization Code Grant tipe behels veilige server-tot-server kommunikasie vir die oordrag van gebruikersdata. As die Authorization Server egter implisiet vertrou op ’n scope-parameter in die Access Token Request (’n parameter nie in die RFC gedefinieer nie), kan ’n kwaadwillige toepassing die bevoegdhede van ’n authorization code opgradeer deur ’n hoër scope aan te vra. Nadat die Access Token gegenereer is, moet die Resource Server dit verifieer: vir JWT-tokens behels dit die verifiëring van die JWT-handtekening en die uittrekking van data soos client_id en scope, terwyl vir ewekansige string-tokens die bediener die Authorization Server moet navraag doen om die token se besonderhede te kry.

Redirect Scheme Hijacking

In mobiele OAuth-implementasies gebruik toepassings custom URI schemes om omleidings met Authorization Codes te ontvang. Omdat verskeie apps dieselfde scheme op ’n toestel kan registreer, word die aanname dat slegs die legitimêre kliënt die redirect URI beheer, gebreek. Op Android byvoorbeeld, word ’n Intent URI soos com.example.app:// op grond van die scheme en opsionele filters in ’n app se intent-filter gevang. Aangesien Android se intent-resolusie wyd kan wees — veral as slegs die scheme gespesifiseer is — kan ’n aanvaller ’n kwaadwillige app registreer met ’n noukeurig opgeboude intent-filter om die authorization code te kaap. Dit kan ’n account takeover moontlik maak hetsy deur gebruikersinteraksie (wanneer verskeie apps bevoegd is om die intent te hanteer) of via omseilings wat te spesifieke filters uitbuit, soos uiteengesit in Ostorlab se assessment flowchart.

References

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks