hacktricks/pentesting-web/hacking-with-cookies/README.md

# Cookies Hacking

{% hint style="success" %}
Learn & practice AWS Hacking:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>
{% endhint %}

## Cookie Attributes

I cookie hanno diversi attributi che controllano il loro comportamento nel browser dell'utente. Ecco un riepilogo di questi attributi in una voce più passiva:

### Expires e Max-Age

La data di scadenza di un cookie è determinata dall'attributo `Expires`. Al contrario, l'attributo `Max-age` definisce il tempo in secondi fino a quando un cookie viene eliminato. **Opta per `Max-age` poiché riflette pratiche più moderne.**

### Domain

I host che ricevono un cookie sono specificati dall'attributo `Domain`. Per impostazione predefinita, questo è impostato sull'host che ha emesso il cookie, escludendo i suoi sottodomini. Tuttavia, quando l'attributo `Domain` è esplicitamente impostato, comprende anche i sottodomini. Questo rende la specifica dell'attributo `Domain` un'opzione meno restrittiva, utile per scenari in cui è necessario condividere i cookie tra sottodomini. Ad esempio, impostare `Domain=mozilla.org` rende i cookie accessibili sui suoi sottodomini come `developer.mozilla.org`.

### Path

Un percorso URL specifico che deve essere presente nell'URL richiesto affinché l'intestazione `Cookie` venga inviata è indicato dall'attributo `Path`. Questo attributo considera il carattere `/` come separatore di directory, consentendo corrispondenze anche nelle sottodirectory.

### Ordering Rules

Quando due cookie hanno lo stesso nome, quello scelto per l'invio si basa su:

* Il cookie che corrisponde al percorso più lungo nell'URL richiesto.
* Il cookie impostato più di recente se i percorsi sono identici.

### SameSite

* L'attributo `SameSite` determina se i cookie vengono inviati su richieste provenienti da domini di terze parti. Offre tre impostazioni:
* **Strict**: Limita l'invio del cookie su richieste di terze parti.
* **Lax**: Consente l'invio del cookie con richieste GET avviate da siti web di terze parti.
* **None**: Permette l'invio del cookie da qualsiasi dominio di terze parti.

Ricorda, mentre configuri i cookie, comprendere questi attributi può aiutare a garantire che si comportino come previsto in diversi scenari.

| **Request Type** | **Example Code**                   | **Cookies Sent When** |
| ---------------- | ---------------------------------- | --------------------- |
| Link             | \<a href="...">\</a>               | NotSet\*, Lax, None   |
| Prerender        | \<link rel="prerender" href=".."/> | NotSet\*, Lax, None   |
| Form GET         | \<form method="GET" action="...">  | NotSet\*, Lax, None   |
| Form POST        | \<form method="POST" action="..."> | NotSet\*, None        |
| iframe           | \<iframe src="...">\</iframe>      | NotSet\*, None        |
| AJAX             | $.get("...")                       | NotSet\*, None        |
| Image            | \<img src="...">                   | NetSet\*, None        |

Tabella da [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) e leggermente modificata.\
Un cookie con l'attributo _**SameSite**_ **mitigherà gli attacchi CSRF** in cui è necessaria una sessione autenticata.

**\*Nota che da Chrome80 (feb/2019) il comportamento predefinito di un cookie senza un attributo SameSite** **sarà lax** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\
Nota che temporaneamente, dopo aver applicato questa modifica, i **cookie senza una policy SameSite** in Chrome saranno **trattati come None** durante i **primi 2 minuti e poi come Lax per le richieste POST cross-site di livello superiore.**

## Cookies Flags

### HttpOnly

Questo impedisce al **client** di accedere al cookie (ad esempio tramite **Javascript**: `document.cookie`)

#### **Bypasses**

* Se la pagina **invia i cookie come risposta** a una richiesta (ad esempio in una pagina **PHPinfo**), è possibile abusare dell'XSS per inviare una richiesta a questa pagina e **rubare i cookie** dalla risposta (controlla un esempio in [https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/](https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/).
* Questo potrebbe essere bypassato con richieste **TRACE** **HTTP** poiché la risposta del server (se questo metodo HTTP è disponibile) rifletterà i cookie inviati. Questa tecnica è chiamata **Cross-Site Tracking**.
* Questa tecnica è evitata dai **browser moderni non permettendo l'invio di una richiesta TRACE** da JS. Tuttavia, sono stati trovati alcuni bypass in software specifici come l'invio di `\r\nTRACE` invece di `TRACE` a IE6.0 SP2.
* Un altro modo è lo sfruttamento di vulnerabilità zero/day dei browser.
* È possibile **sovrascrivere i cookie HttpOnly** eseguendo un attacco di overflow del Cookie Jar:

{% content-ref url="cookie-jar-overflow.md" %}
[cookie-jar-overflow.md](cookie-jar-overflow.md)
{% endcontent-ref %}

* È possibile utilizzare l'attacco [**Cookie Smuggling**](./#cookie-smuggling) per esfiltrare questi cookie

### Secure

La richiesta invierà **solo** il cookie in una richiesta HTTP solo se la richiesta viene trasmessa su un canale sicuro (tipicamente **HTTPS**).

## Cookies Prefixes

I cookie con prefisso `__Secure-` devono essere impostati insieme al flag `secure` da pagine protette da HTTPS.

Per i cookie con prefisso `__Host-`, devono essere soddisfatte diverse condizioni:

* Devono essere impostati con il flag `secure`.
* Devono provenire da una pagina protetta da HTTPS.
* È vietato specificare un dominio, impedendo la loro trasmissione ai sottodomini.
* Il percorso per questi cookie deve essere impostato su `/`.

È importante notare che i cookie con prefisso `__Host-` non possono essere inviati a superdomini o sottodomini. Questa restrizione aiuta a isolare i cookie dell'applicazione. Pertanto, utilizzare il prefisso `__Host-` per tutti i cookie dell'applicazione può essere considerata una buona pratica per migliorare la sicurezza e l'isolamento.

### Overwriting cookies

Quindi, una delle protezioni dei cookie con prefisso `__Host-` è quella di impedire loro di essere sovrascritti dai sottodomini. Prevenendo ad esempio [**Cookie Tossing attacks**](cookie-tossing.md). Nella conferenza [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F\_wAzF4a7Xg) ([**paper**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) è stato presentato che era possibile impostare cookie con prefisso \_\_HOST- da un sottodominio, ingannando il parser, ad esempio, aggiungendo "=" all'inizio o all'inizio e alla fine...:

<figure><img src="../../.gitbook/assets/image (6) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

O in PHP era possibile aggiungere **altri caratteri all'inizio** del nome del cookie che sarebbero stati **sostituiti da caratteri di sottolineatura**, consentendo di sovrascrivere i cookie `__HOST-`:

<figure><img src="../../.gitbook/assets/image (7) (1) (1) (1).png" alt="" width="373"><figcaption></figcaption></figure>

## Cookies Attacks

Se un cookie personalizzato contiene dati sensibili, controllalo (soprattutto se stai partecipando a un CTF), poiché potrebbe essere vulnerabile.

### Decoding and Manipulating Cookies

I dati sensibili incorporati nei cookie dovrebbero sempre essere scrutinati. I cookie codificati in Base64 o formati simili possono spesso essere decodificati. Questa vulnerabilità consente agli attaccanti di alterare il contenuto del cookie e impersonare altri utenti codificando nuovamente i loro dati modificati nel cookie.

### Session Hijacking

Questo attacco comporta il furto del cookie di un utente per ottenere accesso non autorizzato al proprio account all'interno di un'applicazione. Utilizzando il cookie rubato, un attaccante può impersonare l'utente legittimo.

### Session Fixation

In questo scenario, un attaccante inganna una vittima a utilizzare un cookie specifico per accedere. Se l'applicazione non assegna un nuovo cookie al momento del login, l'attaccante, in possesso del cookie originale, può impersonare la vittima. Questa tecnica si basa sul fatto che la vittima accede con un cookie fornito dall'attaccante.

Se hai trovato un **XSS in un sottodominio** o **controlli un sottodominio**, leggi:

{% content-ref url="cookie-tossing.md" %}
[cookie-tossing.md](cookie-tossing.md)
{% endcontent-ref %}

### Session Donation

Qui, l'attaccante convince la vittima a utilizzare il cookie di sessione dell'attaccante. La vittima, credendo di essere connessa al proprio account, eseguirà involontariamente azioni nel contesto dell'account dell'attaccante.

Se hai trovato un **XSS in un sottodominio** o **controlli un sottodominio**, leggi:

{% content-ref url="cookie-tossing.md" %}
[cookie-tossing.md](cookie-tossing.md)
{% endcontent-ref %}

### [JWT Cookies](../hacking-jwt-json-web-tokens.md)

Clicca sul link precedente per accedere a una pagina che spiega i possibili difetti nei JWT.

I JSON Web Tokens (JWT) utilizzati nei cookie possono anche presentare vulnerabilità. Per informazioni approfondite sui potenziali difetti e su come sfruttarli, si consiglia di accedere al documento collegato sul hacking dei JWT.

### Cross-Site Request Forgery (CSRF)

Questo attacco costringe un utente autenticato a eseguire azioni indesiderate su un'applicazione web in cui è attualmente autenticato. Gli attaccanti possono sfruttare i cookie che vengono inviati automaticamente con ogni richiesta al sito vulnerabile.

### Empty Cookies

(Controlla ulteriori dettagli nella [ricerca originale](https://blog.ankursundara.com/cookie-bugs/)) I browser consentono la creazione di cookie senza un nome, il che può essere dimostrato tramite JavaScript come segue:
```js
document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"
```
Il risultato nell'intestazione del cookie inviato è `a=v1; test value; b=v2;`. In modo intrigante, questo consente la manipolazione dei cookie se viene impostato un cookie con nome vuoto, potenzialmente controllando altri cookie impostando il cookie vuoto a un valore specifico:
```js
function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}

setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value
```
Questo porta il browser a inviare un'intestazione cookie interpretata da ogni server web come un cookie chiamato `a` con un valore `b`.

#### Bug di Chrome: Problema del Codice Surrogato Unicode

In Chrome, se un codice surrogato Unicode fa parte di un cookie impostato, `document.cookie` diventa corrotto, restituendo successivamente una stringa vuota:
```js
document.cookie = "\ud800=meep";
```
Questo porta a `document.cookie` che restituisce una stringa vuota, indicando una corruzione permanente.

#### Cookie Smuggling a causa di problemi di parsing

(Controlla ulteriori dettagli nella [ricerca originale](https://blog.ankursundara.com/cookie-bugs/)) Diversi server web, inclusi quelli di Java (Jetty, TomCat, Undertow) e Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), gestiscono in modo errato le stringhe dei cookie a causa del supporto obsoleto di RFC2965. Leggono un valore di cookie racchiuso tra virgolette come un singolo valore anche se include punti e virgola, che normalmente dovrebbero separare le coppie chiave-valore:
```
RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
```
#### Vulnerabilità di Iniezione dei Cookie

(Controlla ulteriori dettagli nella [ricerca originale](https://blog.ankursundara.com/cookie-bugs/)) L'analisi errata dei cookie da parte dei server, in particolare Undertow, Zope e quelli che utilizzano `http.cookie.SimpleCookie` e `http.cookie.BaseCookie` di Python, crea opportunità per attacchi di iniezione dei cookie. Questi server non delimitano correttamente l'inizio di nuovi cookie, consentendo agli attaccanti di falsificare i cookie:

* Undertow si aspetta un nuovo cookie immediatamente dopo un valore tra virgolette senza un punto e virgola.
* Zope cerca una virgola per iniziare a analizzare il cookie successivo.
* Le classi di cookie di Python iniziano a analizzare su un carattere di spazio.

Questa vulnerabilità è particolarmente pericolosa nelle applicazioni web che si basano sulla protezione CSRF basata su cookie, poiché consente agli attaccanti di iniettare cookie CSRF-token falsificati, potenzialmente eludendo le misure di sicurezza. Il problema è aggravato dalla gestione di nomi di cookie duplicati da parte di Python, dove l'ultima occorrenza sovrascrive quelle precedenti. Solleva anche preoccupazioni per i cookie `__Secure-` e `__Host-` in contesti insicuri e potrebbe portare a bypass di autorizzazione quando i cookie vengono passati a server di back-end suscettibili alla falsificazione.

### Controlli Extra per Cookie Vulnerabili

#### **Controlli di base**

* Il **cookie** è **lo stesso** ogni volta che **accedi**.
* Disconnettiti e prova a utilizzare lo stesso cookie.
* Prova ad accedere con 2 dispositivi (o browser) allo stesso account utilizzando lo stesso cookie.
* Controlla se il cookie contiene informazioni e prova a modificarlo.
* Prova a creare diversi account con nomi utente quasi identici e controlla se puoi vedere somiglianze.
* Controlla l'opzione "**ricordami**" se esiste per vedere come funziona. Se esiste e potrebbe essere vulnerabile, utilizza sempre il cookie di **ricordami** senza alcun altro cookie.
* Controlla se il cookie precedente funziona anche dopo aver cambiato la password.

#### **Attacchi avanzati ai cookie**

Se il cookie rimane lo stesso (o quasi) quando accedi, questo probabilmente significa che il cookie è correlato a qualche campo del tuo account (probabilmente il nome utente). Allora puoi:

* Provare a creare molti **account** con nomi utente molto **simili** e cercare di **indovinare** come funziona l'algoritmo.
* Provare a **bruteforce il nome utente**. Se il cookie viene salvato solo come metodo di autenticazione per il tuo nome utente, allora puoi creare un account con nome utente "**Bmin**" e **bruteforce** ogni singolo **bit** del tuo cookie perché uno dei cookie che proverai sarà quello appartenente a "**admin**".
* Provare **Padding** **Oracle** (puoi decrittare il contenuto del cookie). Usa **padbuster**.

**Padding Oracle - Esempi di Padbuster**
```bash
padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2
```
Padbuster farà diversi tentativi e ti chiederà quale condizione è la condizione di errore (quella che non è valida).

Poi inizierà a decrittografare il cookie (potrebbe richiedere diversi minuti)

Se l'attacco è stato eseguito con successo, allora potresti provare a crittografare una stringa a tua scelta. Ad esempio, se desideri **encrypt** **user=administrator**
```
padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator
```
Questa esecuzione ti darà il cookie correttamente crittografato e codificato con la stringa **user=administrator** all'interno.

**CBC-MAC**

Forse un cookie potrebbe avere un valore e potrebbe essere firmato utilizzando CBC. Quindi, l'integrità del valore è la firma creata utilizzando CBC con lo stesso valore. Poiché si raccomanda di utilizzare come IV un vettore nullo, questo tipo di controllo dell'integrità potrebbe essere vulnerabile.

**L'attacco**

1. Ottieni la firma del nome utente **administ** = **t**
2. Ottieni la firma del nome utente **rator\x00\x00\x00 XOR t** = **t'**
3. Imposta nel cookie il valore **administrator+t'** (**t'** sarà una firma valida di **(rator\x00\x00\x00 XOR t) XOR t** = **rator\x00\x00\x00**

**ECB**

Se il cookie è crittografato utilizzando ECB potrebbe essere vulnerabile.\
Quando accedi, il cookie che ricevi deve essere sempre lo stesso.

**Come rilevare e attaccare:**

Crea 2 utenti con quasi gli stessi dati (nome utente, password, email, ecc.) e prova a scoprire qualche modello all'interno del cookie fornito.

Crea un utente chiamato ad esempio "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" e controlla se c'è qualche modello nel cookie (poiché ECB crittografa con la stessa chiave ogni blocco, gli stessi byte crittografati potrebbero apparire se il nome utente è crittografato).

Dovrebbe esserci un modello (con la dimensione di un blocco utilizzato). Quindi, sapendo come sono crittografati un gruppo di "a", puoi creare un nome utente: "a"\*(dimensione del blocco)+"admin". Poi, potresti eliminare il modello crittografato di un blocco di "a" dal cookie. E avrai il cookie del nome utente "admin".

## Riferimenti

* [https://blog.ankursundara.com/cookie-bugs/](https://blog.ankursundara.com/cookie-bugs/)
* [https://www.linkedin.com/posts/rickey-martin-24533653\_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd](https://www.linkedin.com/posts/rickey-martin-24533653\_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd)

{% hint style="success" %}
Learn & practice AWS Hacking:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>
{% endhint %}