hacktricks/pentesting-web/oauth-to-account-takeover.md

# OAuth per Account Takeover

<details>

<summary><strong>Impara l'hacking AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Altri modi per supportare HackTricks:

* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.

</details>

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}


## Informazioni di Base <a href="#d4a8" id="d4a8"></a>

OAuth offre varie versioni, con informazioni di base accessibili alla [documentazione di 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://esempio.com**_, progettato per **mostrare tutti i tuoi post sui social media**, inclusi quelli privati. Per raggiungere questo obiettivo, viene utilizzato OAuth 2.0. _https://esempio.com_ richiederà il tuo permesso per **accedere ai tuoi post sui social media**. Di conseguenza, comparirà una schermata di consenso su _https://socialmedia.com_, che illustra le **autorizzazioni richieste e lo sviluppatore che effettua la richiesta**. Dopo la tua autorizzazione, _https://esempio.com_ acquisisce la capacità di **accedere ai tuoi post per tuo conto**.

È essenziale comprendere i seguenti componenti all'interno del framework di OAuth 2.0:

- **proprietario della risorsa**: Tu, come **utente/entità**, autorizzi l'accesso alla tua risorsa, come i tuoi post sull'account dei social media.
- **server delle risorse**: Il **server che gestisce le richieste autenticate** dopo che l'applicazione ha ottenuto un `token di accesso` per conto del `proprietario della risorsa`, ad esempio **https://socialmedia.com**.
- **applicazione client**: L'**applicazione che richiede l'autorizzazione** dal `proprietario della risorsa`, come **https://esempio.com**.
- **server di autorizzazione**: Il **server che emette `token di accesso`** all'applicazione client dopo l'autenticazione riuscita del `proprietario della risorsa` e la sicurezza dell'autorizzazione, ad esempio **https://socialmedia.com**.
- **client\_id**: Un identificatore pubblico e univoco per l'applicazione.
- **client\_secret:** Una chiave confidenziale, conosciuta solo dall'applicazione e dal server di autorizzazione, utilizzata per generare `token di accesso`.
- **response\_type**: Un valore che specifica **il tipo di token richiesto**, come `codice`.
- **scope**: Il **livello di accesso** richiesto dall'applicazione client al `proprietario della risorsa`.
- **redirect\_uri**: L'**URL a cui l'utente viene reindirizzato dopo l'autorizzazione**. Questo deve corrispondere tipicamente all'URL di reindirizzamento pre-registrato.
- **state**: Un parametro per **mantenere i dati durante il reindirizzamento dell'utente da e verso il 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**.
- **codice**: Il codice di autorizzazione dal `server di autorizzazione`, utilizzato insieme a `client_id` e `client_secret` dall'applicazione client per acquisire un `token di accesso`.
- **token di accesso**: 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 `token di accesso` senza richiedere nuovamente l'autorizzazione dell'utente**.

### Flusso

Il **flusso effettivo di OAuth** procede come segue:

1. Accedi a [https://esempio.com](https://esempio.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://esempio.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. Successivamente ti viene presentata una pagina di consenso.

4. Dopo aver dato il tuo consenso, i Social Media inviano una risposta al `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 al fine di ottenere un `access_token` per tuo conto, consentendo 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 ai Social Media per accedere

## Vulnerabilità <a href="#323a" id="323a"></a>

### Redirect_uri aperto <a href="#cc36" id="cc36"></a>

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 tali richieste a server dannosi, consentendo il furto dell'account.

Le tecniche di sfruttamento variano in base alla logica di convalida del server di autorizzazione. Possono andare dalla corrispondenza rigorosa del percorso all'accettazione di qualsiasi URL all'interno del dominio o della sottodirectory specificata. I metodi comuni di sfruttamento includono reindirizzamenti aperti, attraversamento del percorso, sfruttamento di espressioni regolari deboli e iniezione HTML per il furto del token.

Oltre al `redirect_uri`, altri parametri di OAuth e OpenID come `client_uri`, `policy_uri`, `tos_uri` e `initiate_login_uri` sono anche suscettibili a attacchi di reindirizzamento. Questi parametri sono facoltativi e il loro supporto varia tra i server.

Per coloro che mirano a un server OpenID, il punto di scoperta (`**.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 nell'individuare il punto di registrazione e altri dettagli di configurazione del server.

### XSS nell'implementazione del reindirizzamento <a href="#bda5" id="bda5"></a>

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 l'**URL di reindirizzamento venga riflettuto nella risposta** del server dopo che l'utente si autentica, essendo **vulnerabile a XSS**. Payload possibile da testare:
```
https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
```
### CSRF - Gestione impropria del parametro di stato <a href="#bda5" id="bda5"></a>

Nelle implementazioni di OAuth, l'abuso o l'omissione del parametro **`state`** può aumentare significativamente il rischio di attacchi di **Cross-Site Request Forgery (CSRF)**. Questa vulnerabilità si verifica quando il parametro `state` non viene utilizzato, viene utilizzato come un valore statico o non viene correttamente convalidato, consentendo agli attaccanti di aggirare le protezioni CSRF.

Gli attaccanti possono sfruttare ciò intercettando il processo di autorizzazione per collegare il proprio account con quello della vittima, portando a potenziali **acquisizioni di account**. Questo è particolarmente critico nelle applicazioni in cui OAuth viene utilizzato per **scopi di autenticazione**.

Esempi reali di questa vulnerabilità sono stati documentati in vari **CTF challenges** e **piattaforme di hacking**, evidenziandone le 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 convalida del parametro **`state`** sono cruciali per proteggersi da CSRF e garantire la sicurezza del flusso OAuth.

### Pre Acquisizione dell'Account <a href="#ebe4" id="ebe4"></a>

1. **Senza Verifica dell'Email alla 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 collegare involontariamente questo account di terze parti all'account pre-creato dell'attaccante, portando a un accesso non autorizzato.

2. **Sfruttare la Verifica dell'Email Lassista di OAuth**: Gli attaccanti possono sfruttare i servizi OAuth che non verificano le email registrandosi con il proprio servizio e successivamente cambiando l'email dell'account con quella della vittima. Questo metodo comporta rischi simili di accesso non autorizzato all'account, simile al primo scenario ma attraverso un diverso vettore di attacco.

### Divulgazione di Segreti <a href="#e177" id="e177"></a>

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 gli `access_tokens`** e le informazioni private.

Una vulnerabilità comune si verifica quando le applicazioni gestiscono erroneamente lo scambio del `code` di autorizzazione per un `access_token` lato client anziché lato server. Questo errore porta all'esposizione del `client_secret`, consentendo agli attaccanti di generare `access_tokens` sotto mentite spoglie dell'applicazione. Inoltre, attraverso l'ingegneria sociale, gli attaccanti potrebbero ottenere privilegi aggiuntivi aggiungendo ulteriori ambiti all'autorizzazione OAuth, sfruttando ulteriormente lo status fidato dell'applicazione.

### Brute Force del Client Secret

Puoi provare a **eseguire un attacco di forza bruta al client\_secret** di un fornitore di servizi con l'identity provider per cercare di rubare account.\
La richiesta per il BF potrebbe assomigliare 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 che lascia trapelare Code + State

Una volta che il client ha il **codice e lo stato**, se è **riflesso all'interno dell'intestazione Referer** quando naviga su una pagina diversa, allora è vulnerabile.

### Access Token memorizzato nella cronologia del browser

Vai alla **cronologia del browser e controlla se il token di accesso è salvato lì**.

### Codice di autorizzazione eterno

Il **codice di autorizzazione dovrebbe vivere solo per un certo periodo per limitare la finestra temporale in cui un attaccante può rubarlo e usarlo**.

### Token di autorizzazione/aggiornamento non vincolato al client

Se riesci a ottenere il **codice di autorizzazione e usarlo con un client diverso, allora puoi prendere il controllo di altri account**.

### Percorsi felici, XSS, Iframes e Post Messages per far trapelare codice e valori di stato

**[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 <a href="#bda5" id="bda5"></a>

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 **abbastanza permessi per sovrascrivere i dati dell'utente**. Pertanto, se riesci a **cambiare l'email dell'utente con un'email di un utente diverso**, 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:

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

### Abuso di token di altre app <a href="#bda5" id="bda5"></a>

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 verificano che il token appartenga all'applicazione.

Ciò perché un **attaccante** potrebbe creare un **applicazione che supporta OAuth e accedere con Facebook** (ad esempio) nella propria applicazione. Quindi, una volta che una vittima accede con Facebook nell'**applicazione dell'attaccante**, l'attaccante potrebbe ottenere il **token OAuth dell'utente fornito alla sua applicazione e usarlo per accedere all'applicazione OAuth della vittima usando il token dell'utente della vittima**.

{% hint style="danger" %}
Pertanto, se l'attaccante riesce a far sì che l'utente acceda alla propria applicazione OAuth, sarà in grado di prendere il controllo dell'account delle vittime nelle applicazioni che si aspettano un token e non verificano se il token è stato concesso al proprio ID app.
{% endhint %}

### Due link e cookie <a href="#bda5" id="bda5"></a>

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 puntava all'host dell'attaccante. Queste informazioni sarebbero **memorizzate in un cookie (RU)** e in un **passaggio successivo** il **prompt** chiederà all'**utente** se desidera concedere l'accesso a quell'host dell'attaccante.

Per eludere 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à sull'host dell'attaccante**, ma il cookie sarà impostato su di esso, quindi il **token verrà inviato all'host dell'attaccante** nel reindirizzamento.

### Parametri SSRF <a href="#bda5" id="bda5"></a>

**[Controlla questa ricerca](https://portswigger.net/research/hidden-oauth-attack-vectors) per ulteriori dettagli su questa tecnica.**

La Registrazione Client Dinamica in OAuth funge da vettore meno ovvio ma critico per vulnerabilità di sicurezza, in particolare per attacchi **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 Client Dinamica** è spesso mappata su `/register` e accetta dettagli come `client_name`, `client_secret`, `redirect_uris` e URL per loghi o set di chiavi JSON Web (JWKs) tramite richieste POST.
- Questa funzionalità aderisce alle specifiche delineate in **RFC7591** e **OpenID Connect Registration 1.0**, che includono parametri potenzialmente vulnerabili a SSRF.
- Il processo di registrazione può esporre involontariamente i server a SSRF in diversi modi:
- **`logo_uri`**: Un URL per il logo dell'applicazione client che potrebbe essere recuperato dal server, innescando SSRF o portando a XSS se l'URL non viene gestito correttamente.
- **`jwks_uri`**: Un URL al documento JWK del client, che se creato male può far sì che il server effettui richieste in uscita a un server controllato dall'attaccante.
- **`sector_identifier_uri`**: Fa riferimento a un array JSON di `redirect_uris`, che il server potrebbe recuperare, creando un'opportunità di 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 innescato registrando un nuovo client con URL dannosi nei 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).

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


<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}

<details>

<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Altri modi per supportare HackTricks:

* Se desideri vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusivi [**NFT**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>