# OAuth per il takeover dell'account {{#include ../banners/hacktricks-training.md}} ## Informazioni di base OAuth offre varie versioni, con informazioni fondamentali accessibili nella [documentazione OAuth 2.0](https://oauth.net/2/). Questa discussione si concentra principalmente sul [tipo di concessione del codice di autorizzazione OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), fornendo un **framework di autorizzazione che consente a un'applicazione di accedere o eseguire azioni sull'account di un utente in un'altra applicazione** (il server di autorizzazione). Considera un sito web ipotetico _**https://example.com**_, progettato per **mostrare tutti i tuoi post sui social media**, inclusi quelli privati. Per raggiungere questo obiettivo, viene impiegato OAuth 2.0. _https://example.com_ richiederà il tuo permesso per **accedere ai tuoi post sui social media**. Di conseguenza, apparirà una schermata di consenso su _https://socialmedia.com_, delineando le **autorizzazioni richieste e lo sviluppatore che effettua la richiesta**. Una volta autorizzato, _https://example.com_ ottiene la possibilità di **accedere ai tuoi post per tuo conto**. È essenziale comprendere i seguenti componenti all'interno del framework OAuth 2.0: - **proprietario della risorsa**: Tu, come **utente/entità**, autorizzi l'accesso alla tua risorsa, come i post del tuo account sui social media. - **server delle risorse**: Il **server che gestisce le richieste autenticate** dopo che l'applicazione ha ottenuto un `access token` per conto del `proprietario della risorsa`, ad esempio, **https://socialmedia.com**. - **applicazione client**: L'**applicazione che richiede autorizzazione** dal `proprietario della risorsa`, come **https://example.com**. - **server di autorizzazione**: Il **server che emette `access tokens`** all'`applicazione client` dopo l'autenticazione riuscita del `proprietario della risorsa` e l'ottenimento dell'autorizzazione, ad esempio, **https://socialmedia.com**. - **client_id**: Un identificatore pubblico e unico per l'applicazione. - **client_secret:** Una chiave riservata, conosciuta solo dall'applicazione e dal server di autorizzazione, utilizzata per generare `access_tokens`. - **response_type**: Un valore che specifica **il tipo di token richiesto**, come `code`. - **scope**: Il **livello di accesso** che l'`applicazione client` sta richiedendo dal `proprietario della risorsa`. - **redirect_uri**: L'**URL a cui l'utente viene reindirizzato dopo l'autorizzazione**. Questo deve generalmente allinearsi con l'URL di reindirizzamento pre-registrato. - **state**: Un parametro per **mantenere i dati durante il reindirizzamento dell'utente verso e dal server di autorizzazione**. La sua unicità è fondamentale per fungere da **meccanismo di protezione CSRF**. - **grant_type**: Un parametro che indica **il tipo di concessione e il tipo di token da restituire**. - **code**: Il codice di autorizzazione dal `server di autorizzazione`, utilizzato insieme a `client_id` e `client_secret` dall'applicazione client per acquisire un `access_token`. - **access_token**: Il **token che l'applicazione client utilizza per le richieste API** per conto del `proprietario della risorsa`. - **refresh_token**: Consente all'applicazione di **ottenere un nuovo `access_token` senza richiedere nuovamente all'utente**. ### Flusso Il **flusso OAuth effettivo** procede come segue: 1. Naviga su [https://example.com](https://example.com) e seleziona il pulsante “Integra con i social media”. 2. Il sito invia quindi una richiesta a [https://socialmedia.com](https://socialmedia.com) chiedendo la tua autorizzazione per consentire all'applicazione di https://example.com di accedere ai tuoi post. La richiesta è strutturata come: ``` https://socialmedia.com/auth ?response_type=code &client_id=example_clientId &redirect_uri=https%3A%2F%2Fexample.com%2Fcallback &scope=readPosts &state=randomString123 ``` 3. Ti viene quindi presentata una pagina di consenso. 4. Dopo la tua approvazione, Social Media invia una risposta all'`redirect_uri` con i parametri `code` e `state`: ``` https://example.com?code=uniqueCode123&state=randomString123 ``` 5. https://example.com utilizza questo `code`, insieme al suo `client_id` e `client_secret`, per effettuare una richiesta lato server per ottenere un `access_token` per tuo conto, abilitando l'accesso alle autorizzazioni a cui hai acconsentito: ``` POST /oauth/access_token Host: socialmedia.com ...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"} ``` 6. Infine, il processo si conclude quando https://example.com utilizza il tuo `access_token` per effettuare una chiamata API a Social Media per accedere ## Vulnerabilità ### Open redirect_uri Il `redirect_uri` è cruciale per la sicurezza nelle implementazioni di OAuth e OpenID, poiché indica dove vengono inviati i dati sensibili, come i codici di autorizzazione, dopo l'autorizzazione. Se configurato in modo errato, potrebbe consentire agli attaccanti di reindirizzare queste richieste a server malevoli, abilitando il takeover dell'account. Le tecniche di sfruttamento variano in base alla logica di convalida del server di autorizzazione. Possono variare da un abbinamento di percorso rigoroso all'accettazione di qualsiasi URL all'interno del dominio o sottodirectory specificati. I metodi di sfruttamento comuni includono reindirizzamenti aperti, traversata di percorso, sfruttamento di regex deboli e iniezione HTML per il furto di token. Oltre al `redirect_uri`, altri parametri di OAuth e OpenID come `client_uri`, `policy_uri`, `tos_uri` e `initiate_login_uri` sono anch'essi suscettibili ad attacchi di reindirizzamento. Questi parametri sono facoltativi e il loro supporto varia tra i server. Per coloro che mirano a un server OpenID, l'endpoint di discovery (`**.well-known/openid-configuration**`) elenca spesso dettagli di configurazione preziosi come `registration_endpoint`, `request_uri_parameter_supported` e "`require_request_uri_registration`. Questi dettagli possono aiutare a identificare l'endpoint di registrazione e altre specifiche di configurazione del server. ### XSS nell'implementazione del reindirizzamento Come menzionato in questo rapporto di bug bounty [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html), potrebbe essere possibile che il **URL di reindirizzamento venga riflesso nella risposta** del server dopo che l'utente si autentica, risultando **vulnerabile a XSS**. Payload possibile da testare: ``` https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard

test

``` ### CSRF - Gestione impropria del parametro di stato Nelle implementazioni di OAuth, l'uso improprio o l'omissione del **`state` parameter** può aumentare significativamente il rischio di attacchi di **Cross-Site Request Forgery (CSRF)**. Questa vulnerabilità si verifica quando il parametro `state` è **non utilizzato, utilizzato come valore statico, o non validato correttamente o associato alla sessione dell'utente** durante il login, consentendo agli attaccanti di bypassare le protezioni CSRF. Gli attaccanti possono sfruttare questo intercettando il processo di autorizzazione per collegare il proprio account a quello di una vittima, portando a potenziali **account takeovers** facendo in modo che un utente acceda con un flusso oauth quasi completato appartenente all'attaccante. Questo è particolarmente critico nelle applicazioni in cui OAuth è utilizzato per **scopi di autenticazione**. Esempi reali di questa vulnerabilità sono stati documentati in varie **CTF challenges** e **hacking platforms**, evidenziando le sue implicazioni pratiche. Il problema si estende anche alle integrazioni con servizi di terze parti come **Slack**, **Stripe** e **PayPal**, dove gli attaccanti possono reindirizzare notifiche o pagamenti ai propri account. Una corretta gestione e validazione del **`state` parameter** sono cruciali per proteggere contro CSRF e garantire la sicurezza del flusso OAuth. ### Pre Account Takeover 1. **Senza verifica dell'email nella creazione dell'account**: Gli attaccanti possono creare preventivamente un account utilizzando l'email della vittima. Se la vittima successivamente utilizza un servizio di terze parti per il login, l'applicazione potrebbe involontariamente collegare questo account di terze parti all'account pre-creato dall'attaccante, portando ad accessi non autorizzati. 2. **Sfruttare la verifica dell'email OAuth poco rigorosa**: Gli attaccanti possono sfruttare i servizi OAuth che non verificano le email registrandosi con il loro servizio e poi cambiando l'email dell'account con quella della vittima. Questo metodo comporta un rischio simile di accesso non autorizzato all'account, simile al primo scenario ma attraverso un vettore di attacco diverso. ### Divulgazione di segreti Identificare e proteggere i parametri segreti di OAuth è cruciale. Mentre il **`client_id`** può essere divulgato in modo sicuro, rivelare il **`client_secret`** comporta rischi significativi. Se il `client_secret` viene compromesso, gli attaccanti possono sfruttare l'identità e la fiducia dell'applicazione per **rubare i `access_tokens`** degli utenti e informazioni private. Una vulnerabilità comune si verifica quando le applicazioni gestiscono erroneamente lo scambio del `code` di autorizzazione per un `access_token` sul lato client anziché sul lato server. Questo errore porta all'esposizione del `client_secret`, consentendo agli attaccanti di generare `access_tokens` sotto le spoglie dell'applicazione. Inoltre, attraverso l'ingegneria sociale, gli attaccanti potrebbero aumentare i privilegi aggiungendo ulteriori scope all'autorizzazione OAuth, sfruttando ulteriormente lo stato di fiducia dell'applicazione. ### Bruteforce del Client Secret Puoi provare a **bruteforce il client_secret** di un fornitore di servizi con il provider di identità per cercare di rubare account.\ La richiesta per BF potrebbe apparire simile a: ``` 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 leaking Code + State Una volta che il client ha il **code and state**, se è **riflesso all'interno dell'header Referer** quando naviga su un'altra pagina, allora è vulnerabile. ### Access Token Stored in Browser History Vai alla **cronologia del browser e controlla se l'access token è salvato lì**. ### Everlasting Authorization Code Il **authorization code dovrebbe vivere solo per un certo periodo per limitare la finestra temporale in cui un attaccante può rubarlo e usarlo**. ### Authorization/Refresh Token not bound to client Se riesci a ottenere il **authorization code e usarlo con un client diverso, allora puoi prendere il controllo di altri account**. ### Happy Paths, XSS, Iframes & Post Messages to leak code & state values [**Controlla questo post**](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url) ### AWS Cognito In questo rapporto di bug bounty: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) puoi vedere che il **token** che **AWS Cognito** restituisce all'utente potrebbe avere **sufficienti permessi per sovrascrivere i dati dell'utente**. Pertanto, se puoi **cambiare l'email dell'utente con un'altra email**, potresti essere in grado di **prendere il controllo** di altri account. ```bash # 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" } ] } ``` Per ulteriori informazioni dettagliate su come abusare di AWS cognito controlla: {{#ref}} https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.html {{#endref}} ### Abusare di altri token delle app Come [**menzionato in questo articolo**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), i flussi OAuth che si aspettano di ricevere il **token** (e non un codice) potrebbero essere vulnerabili se non controllano che il token appartenga all'app. Questo perché un **attaccante** potrebbe creare un **applicazione che supporta OAuth e accedere con Facebook** (ad esempio) nella propria applicazione. Poi, una volta che una vittima accede con Facebook nell'**applicazione dell'attaccante**, l'attaccante potrebbe ottenere il **token OAuth dell'utente dato alla sua applicazione e usarlo per accedere all'applicazione OAuth della vittima utilizzando il token utente della vittima**. > [!CAUTION] > Pertanto, se l'attaccante riesce a far accedere l'utente alla propria applicazione OAuth, sarà in grado di prendere il controllo dell'account della vittima in applicazioni che si aspettano un token e non controllano se il token è stato concesso al loro ID app. ### Due link & cookie Secondo [**questo articolo**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), era possibile far aprire a una vittima una pagina con un **returnUrl** che punta all'host dell'attaccante. Queste informazioni sarebbero state **memorizzate in un cookie (RU)** e in un **passaggio successivo** il **prompt** **chiederà** all'**utente** se desidera concedere accesso a quell'host dell'attaccante. Per bypassare questo prompt, era possibile aprire una scheda per avviare il **flusso Oauth** che imposterebbe questo cookie RU utilizzando il **returnUrl**, chiudere la scheda prima che venga mostrato il prompt e aprire una nuova scheda senza quel valore. Quindi, il **prompt non informerà riguardo all'host dell'attaccante**, ma il cookie sarebbe impostato su di esso, quindi il **token sarà inviato all'host dell'attaccante** nella redirezione. ### Bypass dell'interazione del prompt Come spiegato in [**questo video**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), alcune implementazioni OAuth consentono di indicare il parametro **`prompt`** GET come None (**`&prompt=none`**) per **prevenire che gli utenti vengano chiesti di confermare** l'accesso dato in un prompt sul web se sono già loggati sulla piattaforma. ### response_mode Come [**spiegato in questo video**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), potrebbe essere possibile indicare il parametro **`response_mode`** per indicare dove si desidera che il codice venga fornito nell'URL finale: - `response_mode=query` -> Il codice è fornito all'interno di un parametro GET: `?code=2397rf3gu93f` - `response_mode=fragment` -> Il codice è fornito all'interno del parametro frammento dell'URL `#code=2397rf3gu93f` - `response_mode=form_post` -> Il codice è fornito all'interno di un modulo POST con un input chiamato `code` e il valore - `response_mode=web_message` -> Il codice è inviato in un messaggio post: `window.opener.postMessage({"code": "asdasdasd...` ### Flusso OAuth ROPC - bypass 2 FA Secondo [**questo post del blog**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), questo è un flusso OAuth che consente di accedere a OAuth tramite **nome utente** e **password**. Se durante questo semplice flusso viene restituito un **token** con accesso a tutte le azioni che l'utente può eseguire, allora è possibile bypassare 2FA utilizzando quel token. ### ATO su pagina web che reindirizza in base a open redirect al referrer Questo [**post del blog**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) commenta come sia stato possibile abusare di un **open redirect** al valore del **referrer** per abusare di OAuth per ATO. L'attacco è stato: 1. La vittima accede alla pagina web dell'attaccante 2. La vittima apre il link malevolo e un opener avvia il flusso OAuth di Google con `response_type=id_token,code&prompt=none` come parametri aggiuntivi utilizzando come **referrer il sito web dell'attaccante**. 3. Nell'opener, dopo che il provider autorizza la vittima, la rimanda al valore del parametro `redirect_uri` (web della vittima) con codice 30X che mantiene ancora il sito web dell'attaccante nel referer. 4. Il **sito web della vittima attiva il reindirizzamento open basato sul referrer** reindirizzando l'utente vittima al sito web dell'attaccante, poiché il **`respose_type`** era **`id_token,code`**, il codice sarà inviato all'attaccante nel **frammento** dell'URL consentendogli di prendere il controllo dell'account dell'utente tramite Google nel sito della vittima. ### Parametri SSRFs [**Controlla questa ricerca**](https://portswigger.net/research/hidden-oauth-attack-vectors) **Per ulteriori dettagli su questa tecnica.** La registrazione dinamica dei client in OAuth funge da vettore meno ovvio ma critico per le vulnerabilità di sicurezza, specificamente per gli attacchi di **Server-Side Request Forgery (SSRF)**. Questo endpoint consente ai server OAuth di ricevere dettagli sulle applicazioni client, inclusi URL sensibili che potrebbero essere sfruttati. **Punti chiave:** - La **registrazione dinamica dei client** è spesso mappata su `/register` e accetta dettagli come `client_name`, `client_secret`, `redirect_uris` e URL per loghi o JSON Web Key Sets (JWKs) tramite richieste POST. - Questa funzionalità aderisce alle specifiche stabilite in **RFC7591** e **OpenID Connect Registration 1.0**, che includono parametri potenzialmente vulnerabili a SSRF. - Il processo di registrazione può involontariamente esporre i server a SSRF in diversi modi: - **`logo_uri`**: Un URL per il logo dell'applicazione client che potrebbe essere recuperato dal server, attivando SSRF o portando a XSS se l'URL è gestito in modo errato. - **`jwks_uri`**: Un URL al documento JWK del client, che se creato in modo malevolo, può causare al server di effettuare richieste outbound a un server controllato dall'attaccante. - **`sector_identifier_uri`**: Riferisce a un array JSON di `redirect_uris`, che il server potrebbe recuperare, creando un'opportunità SSRF. - **`request_uris`**: Elenca gli URI di richiesta consentiti per il client, che possono essere sfruttati se il server recupera questi URI all'inizio del processo di autorizzazione. **Strategia di sfruttamento:** - SSRF può essere attivato registrando un nuovo client con URL malevoli in parametri come `logo_uri`, `jwks_uri` o `sector_identifier_uri`. - Sebbene lo sfruttamento diretto tramite `request_uris` possa essere mitigato da controlli di whitelist, fornire un `request_uri` pre-registrato e controllato dall'attaccante può facilitare SSRF durante la fase di autorizzazione. ## Condizioni di gara dei fornitori OAuth Se la piattaforma che stai testando è un fornitore OAuth [**leggi questo per testare possibili condizioni di gara**](race-condition.md). ## Attacco ai reclami mutabili In OAuth, il campo sub identifica univocamente un utente, ma il suo formato varia a seconda del server di autorizzazione. Per standardizzare l'identificazione degli utenti, alcuni client utilizzano email o handle utente. Tuttavia, questo è rischioso perché: - Alcuni server di autorizzazione non garantiscono che queste proprietà (come l'email) rimangano immutabili. - In alcune implementazioni—come **"Accedi con Microsoft"**—il client si basa sul campo email, che è **controllato dall'utente in Entra ID** e non verificato. - Un attaccante può sfruttare questo creando la propria organizzazione Azure AD (ad esempio, doyensectestorg) e utilizzandola per eseguire un accesso Microsoft. - Anche se l'Object ID (memorizzato in sub) è immutabile e sicuro, la dipendenza da un campo email mutabile può consentire un takeover dell'account (ad esempio, dirottare un account come victim@gmail.com). ## Attacco di confusione del client In un **Attacco di confusione del client**, un'applicazione che utilizza il flusso implicito OAuth non verifica che il token di accesso finale sia specificamente generato per il proprio Client ID. Un attaccante imposta un sito web pubblico che utilizza il flusso implicito OAuth di Google, ingannando migliaia di utenti a effettuare il login e raccogliendo così i token di accesso destinati al sito dell'attaccante. Se questi utenti hanno anche account su un altro sito vulnerabile che non convalida il Client ID del token, l'attaccante può riutilizzare i token raccolti per impersonare le vittime e prendere il controllo dei loro account. ## Attacco di aggiornamento dello scope Il tipo **Authorization Code Grant** implica comunicazione sicura server-server per trasmettere i dati degli utenti. Tuttavia, se il **Server di Autorizzazione** si fida implicitamente di un parametro scope nella richiesta del token di accesso (un parametro non definito nel RFC), un'applicazione malevola potrebbe aggiornare i privilegi di un codice di autorizzazione richiedendo uno scope più elevato. Dopo che il **Token di Accesso** è generato, il **Server delle Risorse** deve verificarlo: per i token JWT, questo comporta il controllo della firma JWT ed estrarre dati come client_id e scope, mentre per i token a stringa casuale, il server deve interrogare il Server di Autorizzazione per recuperare i dettagli del token. ## Hijacking dello schema di reindirizzamento Nelle implementazioni OAuth mobili, le app utilizzano **schemi URI personalizzati** per ricevere reindirizzamenti con codici di autorizzazione. Tuttavia, poiché più app possono registrare lo stesso schema su un dispositivo, l'assunzione che solo il client legittimo controlli l'URI di reindirizzamento viene violata. Su Android, ad esempio, un URI Intent come `com.example.app://` oauth viene catturato in base allo schema e ai filtri opzionali definiti nel filtro dell'intento di un'app. Poiché la risoluzione degli intent di Android può essere ampia—soprattutto se viene specificato solo lo schema—un attaccante può registrare un'app malevola con un filtro di intento accuratamente progettato per dirottare il codice di autorizzazione. Questo può **abilitare un takeover dell'account** sia attraverso l'interazione dell'utente (quando più app sono idonee a gestire l'intento) sia tramite tecniche di bypass che sfruttano filtri eccessivamente specifici, come dettagliato dal diagramma di flusso di valutazione di Ostorlab. ## Riferimenti - [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1) - [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors) - [**https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html**](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html) {{#include ../banners/hacktricks-training.md}}