OAuth na Rekening oorneem

Reading time: 18 minutes

Basiese Inligting

OAuth bied verskeie weergawes, met fundamentele insigte beskikbaar by OAuth 2.0 dokumentasie. Hierdie bespreking fokus hoofsaaklik op die algemeen gebruikte OAuth 2.0 magtigingskode toekennings tipe, wat 'n magtigingsraamwerk bied wat 'n toepassing in staat stel om toegang te verkry of aksies op 'n gebruiker se rekening in 'n ander toepassing uit te voer (die magtigingsbediener).

Dink aan 'n hipotetiese webwerf https://example.com, ontwerp om al jou sosiale media plasings te vertoon, insluitend privaat ones. Om dit te bereik, word OAuth 2.0 gebruik. https://example.com sal jou toestemming vra om toegang tot jou sosiale media plasings te verkry. Gevolglik sal 'n toestemming skerm verskyn op https://socialmedia.com, wat die toestemmings wat aangevra word en die ontwikkelaar wat die aanvraag doen uiteensit. Na jou magtiging, verkry https://example.com die vermoë om toegang tot jou plasings namens jou te verkry.

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

• resource owner: Jy, as die gebruiker/entiteit, magtig toegang tot jou hulpbron, soos jou sosiale media rekening plasings.
• resource server: Die bediener wat geverifieerde versoeke bestuur nadat die toepassing 'n access token namens die resource owner verkry het, bv. https://socialmedia.com.
• client application: Die toepassing wat magtiging soek van die resource owner, soos https://example.com.
• authorization server: Die bediener wat access tokens uitreik aan die client application na die suksesvolle verifikasie van die resource owner en die verkryging van magtiging, bv. https://socialmedia.com.
• client_id: 'n Publieke, unieke identifiseerder vir die toepassing.
• client_secret: 'n Vertroulike sleutel, bekend slegs aan die toepassing en die magtigingsbediener, wat gebruik word om access_tokens te genereer.
• response_type: 'n Waarde wat die tipe token wat aangevra word spesifiseer, soos code.
• scope: Die vlak van toegang wat die client application van die resource owner aan vra.
• redirect_uri: Die URL waarnatoe die gebruiker herlei word na magtiging. Dit moet tipies ooreenstem met die vooraf geregistreerde herlei URL.
• state: 'n parameter om data te handhaaf oor die gebruiker se herleiding na en van die magtigingsbediener. Die uniekheid daarvan is krities om as 'n CSRF beskermingsmeganisme te dien.
• grant_type: 'n parameter wat die toekennings tipe en die tipe token wat teruggegee moet word aandui.
• code: Die magtigingskode van die authorization server, wat saam met client_id en client_secret deur die kliënttoepassing gebruik word om 'n access_token te verkry.
• access_token: Die token wat die kliënttoepassing gebruik vir API versoeke namens die resource owner.
• refresh_token: Stel die toepassing in staat om 'n nuwe access_token te verkry sonder om die gebruiker weer te vra.

Stroom

Die werklike OAuth stroom verloop soos volg:

1. Jy navigeer na https://example.com en kies die “Integreer met Sosiale Media” knoppie.
2. Die webwerf stuur dan 'n versoek na https://socialmedia.com om jou magtiging te vra om https://example.com se toepassing toegang tot jou plasings te gee. 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

3. Jy word dan met 'n toestemmingsbladsy voorgelê.
4. Na jou goedkeuring, stuur Social Media 'n antwoord na die redirect_uri met die code en state parameters:

https://example.com?code=uniqueCode123&state=randomString123

5. https://example.com gebruik hierdie code, saam met sy client_id en client_secret, om 'n bediener-kant versoek te maak om 'n access_token namens jou te verkry, wat toegang tot die toestemmings wat jy goedgekeur het, moontlik maak:

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

6. Laastens sluit die proses af wanneer https://example.com jou access_token gebruik om 'n API-oproep na Social Media te maak om toegang te verkry

Kw vulnerabilities

Open redirect_uri

Die redirect_uri is van kardinale belang vir sekuriteit in OAuth en OpenID implementasies, aangesien dit aandui waar sensitiewe data, soos magtigingskode, gestuur word na magtiging. As dit verkeerd geconfigureer is, kan dit aanvallers toelaat om hierdie versoeke na kwaadwillige bedieners te herlei, wat rekening oorname moontlik maak.

Eksploitasiemetodes verskil op grond van die validasielogika van die magtigingsbediener. Dit kan wissel van streng padübereenkomste tot die aanvaarding van enige URL binne die gespesifiseerde domein of subgids. Algemene eksploitasie metodes sluit open redirects, pad traversering, die benutting van swak regexes, en HTML-inspuiting vir token-diefstal in.

Benewens redirect_uri, is ander OAuth en OpenID parameters soos client_uri, policy_uri, tos_uri, en initiate_login_uri ook kwesbaar vir herleidingaanvalle. Hierdie parameters is opsioneel en hul ondersteuning verskil oor bedieners.

Vir diegene wat 'n OpenID-bediener teiken, lys die ontdekking eindpunt (**.well-known/openid-configuration**) dikwels waardevolle konfigurasiedetails soos registration_endpoint, request_uri_parameter_supported, en "require_request_uri_registration. Hierdie besonderhede kan help om die registrasie-eindpunt en ander konfigurasiespesifieke van die bediener te identifiseer.

XSS in redirect implementasie

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

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

CSRF - Onbehoorlike hantering van die staat parameter

In OAuth implementasies kan die misbruik of omissie van die state parameter die risiko van Cross-Site Request Forgery (CSRF) aanvalle aansienlik verhoog. Hierdie kwesbaarheid ontstaan wanneer die state parameter nie gebruik word, as 'n statiese waarde gebruik word, of nie behoorlik geverifieer of geassosieer word met die gebruikersessie tydens aanmelding nie, wat dit aanvallers moontlik maak om CSRF beskerming te omseil.

Aanvallers kan dit benut deur die magtiging proses te onderskep om hul rekening met 'n slagoffer se rekening te koppel, wat kan lei tot potensiële rekening oorname deur 'n gebruiker te laat aanmeld met 'n byna voltooide oauth vloei wat aan die aanvaller behoort. Dit is veral krities in toepassings waar OAuth gebruik word vir authentikasie doeleindes.

Werklike voorbeelde van hierdie kwesbaarheid is gedokumenteer in verskeie CTF uitdagings en hacking platforms, wat die praktiese implikasies daarvan uitlig. Die probleem strek ook tot integrasies met derdeparty dienste soos Slack, Stripe, en PayPal, waar aanvallers kennisgewings of betalings na hul rekeninge kan herlei.

Behoorlike hantering en verifikasie van die state parameter is van kardinale belang om teen CSRF te beskerm en die OAuth vloei te beveilig.

Voor Rekening Oorname

1. Sonder E-pos Verifikasie by Rekening Skep: Aanvallers kan proaktief 'n rekening skep met die slagoffer se e-pos. As die slagoffer later 'n derdeparty diens vir aanmelding gebruik, kan die toepassing per ongeluk hierdie derdeparty rekening aan die aanvaller se vooraf geskepte rekening koppel, wat tot ongeoorloofde toegang lei.
2. Misbruik van Los OAuth E-pos Verifikasie: Aanvallers kan OAuth dienste wat nie e-posse verifieer nie, misbruik deur met hul diens te registreer en dan die rekening e-pos na die slagoffer s'n te verander. Hierdie metode hou soortgelyke risiko's van ongeoorloofde rekening toegang in, soortgelyk aan die eerste scenario, maar deur 'n ander aanvalsvector.

Onthulling van Geheime

Identifisering en beskerming van geheime OAuth parameters is van kardinale belang. Terwyl die client_id veilig bekend gemaak kan word, hou die onthulling van die client_secret aansienlike risiko's in. As die client_secret gecompromitteer word, kan aanvallers die identiteit en vertroue van die toepassing misbruik om gebruikers access_tokens en private inligting te steel.

'n Algemene kwesbaarheid ontstaan wanneer toepassings per ongeluk die uitruil van die magtiging code vir 'n access_token aan die kliëntkant hanteer eerder as aan die bedienerkant. Hierdie fout lei tot die blootstelling van die client_secret, wat dit aanvallers moontlik maak om access_tokens onder die dekmantel van die toepassing te genereer. Boonop kan aanvallers deur middel van sosiale ingenieurswese voorregte verhoog deur addisionele skope aan die OAuth magtiging toe te voeg, wat die toepassing se vertroude status verder misbruik.

Kliënt Geheim Bruteforce

Jy kan probeer om die client_secret van 'n diensverskaffer met die identiteitsverskaffer te bruteforce om te probeer om rekeninge te steel.
Die versoek om BF mag soos volg lyk:

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 lek kode + Staat

Sodra die kliënt die kode en staat het, as dit binne die Referer-header weerspieël word wanneer hy na 'n ander bladsy blaai, dan is dit kwesbaar.

Toegangstoken gestoor in Blaaier Geskiedenis

Gaan na die blaaier geskiedenis en kyk of die toegangstoken daar gestoor is.

Ewige Outeurskode

Die auteurskode moet net vir 'n kort tydjie bestaan om die tydsvenster te beperk waarbinne 'n aanvaller dit kan steel en gebruik.

Outeurs-/Herlaai-token nie aan kliënt gebind nie

As jy die auteurskode kan kry en dit met 'n ander kliënt kan gebruik, kan jy ander rekeninge oorneem.

Gelukkige Paaie, XSS, Iframes & Post Boodskappe om kode & staat waardes te lek

Kyk na hierdie pos

AWS Cognito

In hierdie bug bounty verslag: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ kan jy sien dat die token wat AWS Cognito aan die gebruiker teruggee, voldoende toestemmings kan hê om die gebruikersdata te oorskryf. Daarom, as jy die gebruikers e-pos vir 'n ander gebruikers e-pos kan verander, mag jy in staat wees om ander rekeninge oor te neem.

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

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

Vir meer gedetailleerde inligting oor hoe om AWS cognito te misbruik, kyk:

AWS - Cognito Unauthenticated Enum - HackTricks Cloud

Misbruik van ander Apps tokens

Soos genoem in hierdie skrywe, OAuth vloei wat verwag om die token (en nie 'n kode nie) te ontvang, kan kwesbaar wees as hulle nie nagaan dat die token aan die app behoort nie.

Dit is omdat 'n aanvaller 'n aansoek kan skep wat OAuth ondersteun en met Facebook kan aanmeld (byvoorbeeld) in sy eie aansoek. Dan, sodra 'n slagoffer met Facebook in die aanvaller se aansoek aanmeld, kan die aanvaller die OAuth token van die gebruiker wat aan sy aansoek gegee is, verkry en dit gebruik om in die slagoffer se OAuth aansoek aan te meld met die slagoffer se gebruikers token.

Twee skakels & koekie

Volgens hierdie skrywe, was dit moontlik om 'n slagoffer 'n bladsy te laat oopmaak met 'n returnUrl wat na die aanvaller se gasheer wys. Hierdie inligting sou in 'n koekie (RU) gestoor word en in 'n latere stap sal die prompt die gebruiker vra of hy toegang tot daardie aanvaller se gasheer wil gee.

Om hierdie prompt te omseil, was dit moontlik om 'n oortjie te open om die Oauth vloei te begin wat hierdie RU koekie met die returnUrl sou stel, die oortjie te sluit voordat die prompt vertoon word, en 'n nuwe oortjie te open sonder daardie waarde. Dan, die prompt sal nie oor die aanvaller se gasheer inligting gee nie, maar die koekie sou na dit gestel word, sodat die token na die aanvaller se gasheer in die herleiding gestuur sal word.

Prompt Interaksie Omseiling

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

response_mode

Soos verduidelik in hierdie video, mag dit moontlik wees om die parameter response_mode aan te dui om aan te dui waar jy wil hê die kode in die finale URL moet verskaf word:

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

OAuth ROPC vloei - 2 FA omseiling

Volgens hierdie blogpos, is dit 'n OAuth vloei wat toelaat om in OAuth aan te meld via gebruikersnaam en wagwoord. As 'n token met toegang tot al die aksies wat die gebruiker kan uitvoer tydens hierdie eenvoudige vloei teruggestuur word, dan is dit moontlik om 2FA met daardie token te omseil.

ATO op webblad wat herlei op grond van oop herleiding na verwysing

Hierdie blogpos bespreek hoe dit moontlik was om 'n oop herleiding na die waarde van die verwysing te misbruik om OAuth te misbruik vir ATO. Die aanval was:

1. Slagoffer toegang tot die aanvaller se webblad
2. Die slagoffer open die kwaadwillige skakel en 'n opener begin die Google OAuth vloei met response_type=id_token,code&prompt=none as bykomende parameters met die verwysing die aanvaller se webwerf.
3. In die opener, nadat die verskaffer die slagoffer goedkeur, stuur dit hulle terug na die waarde van die redirect_uri parameter (slagoffer web) met 30X kode wat steeds die aanvaller se webwerf in die verwysing hou.
4. Die slagoffer webwerf aktiveer die oop herleiding gebaseer op die verwysing wat die slagoffer gebruiker na die aanvaller se webwerf herlei, aangesien die respose_type id_token,code was, sal die kode teruggestuur word na die aanvaller in die fragment van die URL wat hom in staat stel om die rekening van die gebruiker via Google op die slagoffer se webwerf oor te neem.

SSRFs parameters

Kyk hierdie navorsing Vir verdere besonderhede van hierdie tegniek.

Dinamiese Kliënt Registrasie in OAuth dien as 'n minder voor die hand liggende maar kritieke vektor vir sekuriteitskwesbaarhede, spesifiek vir Server-Side Request Forgery (SSRF) aanvalle. Hierdie eindpunt laat OAuth bedieners toe om besonderhede oor kliënt aansoeke te ontvang, insluitend sensitiewe URL's wat misbruik kan word.

Belangrike Punten:

• Dinamiese Kliënt Registrasie word dikwels aan /register gekoppel en aanvaar besonderhede soos client_name, client_secret, redirect_uris, en URL's vir logo's of JSON Web Key Sets (JWKs) via POST versoeke.
• Hierdie funksie voldoen aan spesifikasies uiteengesit in RFC7591 en OpenID Connect Registrasie 1.0, wat parameters insluit wat moontlik kwesbaar is vir SSRF.
• Die registrasieproses kan per ongeluk bedieners aan SSRF blootstel op verskeie maniere:
• logo_uri: 'n URL vir die kliënt aansoek se logo wat deur die bediener opgevraag kan word, wat SSRF kan aktiveer of kan lei tot XSS as die URL verkeerd hanteer word.
• jwks_uri: 'n URL na die kliënt se JWK dokument, wat, as dit kwaadwillig saamgestel is, kan veroorsaak dat die bediener uitgaande versoeke na 'n aanvaller-beheerde bediener maak.
• sector_identifier_uri: Verwys na 'n JSON-array van redirect_uris, wat die bediener mag opvra, wat 'n SSRF geleentheid skep.
• request_uris: Lys toegelate versoek URI's vir die kliënt, wat misbruik kan word as die bediener hierdie URI's aan die begin van die outorisering proses opvra.

Misbruik Strategie:

• SSRF kan geaktiveer word deur 'n nuwe kliënt met kwaadwillige URL's in parameters soos logo_uri, jwks_uri, of sector_identifier_uri te registreer.
• Terwyl direkte misbruik via request_uris moontlik beperk kan word deur witlysbeheer, kan die verskaffing van 'n vooraf geregistreerde, aanvaller-beheerde request_uri SSRF gedurende die outorisering fase fasiliteer.

OAuth verskaffers Wedloop Voorwaardes

As die platform wat jy toets 'n OAuth verskaffer is lees dit om vir moontlike Wedloop Voorwaardes te toets.

Veranderlike Eise Aanval

In OAuth identifiseer die sub veld 'n gebruiker uniek, maar sy formaat verskil per Outeurskap Bediening. Om gebruikersidentifikasie te standaardiseer, gebruik sommige kliënte e-pos of gebruikershandvatsels. Dit is egter riskant omdat:

• Sommige Outeurskap Bedieners verseker nie dat hierdie eienskappe (soos e-pos) onveranderlik bly nie.
• In sekere implementasies—soos "Aanmeld met Microsoft"—vertrou die kliënt op die e-pos veld, wat deur die gebruiker in Entra ID beheer word en nie geverifieer is nie.
• 'n Aanvaller kan dit misbruik deur sy eie Azure AD-organisasie (bv. doyensectestorg) te skep en dit te gebruik om 'n Microsoft-aanmelding uit te voer.
• Alhoewel die Objekt ID (gestoor in sub) onveranderlik en veilig is, kan die vertroue op 'n veranderlike e-pos veld 'n rekeningsoorname moontlik maak (byvoorbeeld, die oorname van 'n rekening soos victim@gmail.com).

Kliënt Verwarring Aanval

In 'n Kliënt Verwarring Aanval, misluk 'n aansoek wat die OAuth Implicit Flow gebruik om te verifieer dat die finale toegang token spesifiek gegenereer is vir sy eie Kliënt ID. 'n Aanvaller stel 'n publieke webwerf op wat Google se OAuth Implicit Flow gebruik, en mislei duisende gebruikers om aan te meld en sodoende toegang tokens te versamel wat bedoel is vir die aanvaller se webwerf. As hierdie gebruikers ook rekeninge op 'n ander kwesbare webwerf het wat nie die token se Kliënt ID verifieer nie, kan die aanvaller die versamelde tokens hergebruik om die slagoffers na te boots en hul rekeninge oor te neem.

Omvang Opgradering Aanval

Die Outeurskap Kode Grant tipe behels veilige bediener-tot-bediener kommunikasie vir die oordrag van gebruikersdata. As die Outeurskap Bediening egter implisiet 'n omvang parameter in die Toegang Token Versoek vertrou (n parameter wat nie in die RFC gedefinieer is nie), kan 'n kwaadwillige aansoek die voorregte van 'n outeurskap kode opgradeer deur 'n hoër omvang aan te vra. Nadat die Toegang Token gegenereer is, moet die Hulpbron Bediening dit verifieer: vir JWT tokens, behels dit die JWT handtekening te kontroleer en data soos client_id en omvang te onttrek, terwyl vir random string tokens, die bediener die Outeurskap Bediening moet vra om die token se besonderhede te verkry.

Herleiding Skema Hijacking

In mobiele OAuth implementasies gebruik aansoeke aangepaste URI skemas om herleidings met Outeurskap Kodes te ontvang. Omdat verskeie aansoeke dieselfde skema op 'n toestel kan registreer, word die aanname dat slegs die wettige kliënt die herleiding URI beheer, oortree. Op Android, byvoorbeeld, word 'n Intent URI soos com.example.app:// oauth gevang op grond van die skema en opsionele filters wat in 'n aansoek se intent-filter gedefinieer is. Aangesien Android se intent resolusie breed kan wees—veral as slegs die skema gespesifiseer is—kan 'n aanvaller 'n kwaadwillige aansoek registreer met 'n sorgvuldig saamgestelde intent filter om die outeurskap kode te kapen. Dit kan 'n rekeningsoorname moontlik maak of deur gebruikersinteraksie (wanneer verskeie aansoeke in aanmerking kom om die intent te hanteer) of via omseiling tegnieke wat oor spesifieke filters misbruik, soos uiteengesit deur Ostorlab se assesserings stroomdiagram.

Verwysings

• https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors
• https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html