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

290 lines
20 KiB
Markdown
Raw Normal View History

# Hacking dei Cookies
2022-04-28 16:01:33 +00:00
<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>
2022-04-28 16:01:33 +00:00
2024-02-10 13:03:23 +00:00
Altri modi per supportare HackTricks:
2024-01-01 17:15:10 +00:00
* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
2024-02-10 13:03:23 +00:00
* 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 esclusive [**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 a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
2022-04-28 16:01:33 +00:00
</details>
**Try Hard Security Group**
<figure><img src="../../.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
{% embed url="https://discord.gg/tryhardsecurity" %}
***
## Attributi dei Cookies
2023-09-02 23:48:41 +00:00
I cookies sono dotati di diversi attributi che ne controllano il comportamento nel browser dell'utente. Ecco un elenco di questi attributi in una forma più passiva:
2024-02-10 13:03:23 +00:00
### Scadenza 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 prima che un cookie venga eliminato. **Optare per `Max-age` poiché riflette pratiche più moderne.**
2024-02-10 13:03:23 +00:00
### Dominio
Gli 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` una opzione meno restrittiva, utile per scenari in cui è necessario condividere i cookie tra i sottodomini. Ad esempio, impostando `Domain=mozilla.org` rende i cookie accessibili sui suoi sottodomini come `developer.mozilla.org`.
2024-02-10 13:03:23 +00:00
### Percorso
2024-02-10 13:03:23 +00:00
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.
### Regole di Ordinamento
2024-02-10 13:03:23 +00:00
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
2024-02-05 20:00:40 +00:00
* L'attributo `SameSite` detta se i cookie vengono inviati su richieste provenienti da domini di terze parti. Offre tre impostazioni:
* **Strict**: Limita il cookie dall'essere inviato su richieste di terze parti.
* **Lax**: Consente al cookie di essere inviato con richieste GET avviate da siti web di terze parti.
* **None**: Permette al cookie di essere inviato da qualsiasi dominio di terze parti.
Ricorda, configurando i cookie, la comprensione di questi attributi può aiutare a garantire che si comportino come previsto in diversi scenari.
| **Tipo di Richiesta** | **Codice di Esempio** | **Cookie Inviati Quando** |
| ---------------- | ---------------------------------- | --------------------- |
| 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 |
2024-02-10 13:03:23 +00:00
| Immagine | \<img src="..."> | NetSet\*, None |
2024-02-10 13:03:23 +00:00
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 attributo _**SameSite**_ **mitiga gli attacchi CSRF** dove è 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 l'applicazione di questa modifica, i **cookie senza una politica SameSite** in Chrome verranno **trattati come None** durante i **primi 2 minuti e poi come Lax per le richieste POST cross-site di alto livello.**
## Bandiere dei Cookies
### HttpOnly
Questo impedisce al **client** di accedere al cookie (tramite **Javascript** ad esempio: `document.cookie`)
2024-02-10 13:03:23 +00:00
#### **Bypass**
* Se la pagina sta **inviando i cookie come risposta** di una richiesta (ad esempio in una pagina **PHPinfo**), è possibile sfruttare l'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 dal server (se questo metodo HTTP è disponibile) rifletterà i cookie inviati. Questa tecnica è chiamata **Cross-Site Tracking**.
* Questa tecnica è evitata dai **browser moderni che non permettono l'invio di una richiesta TRACE** da JS. Tuttavia, sono stati trovati alcuni bypass a questo in software specifici come l'invio di `\r\nTRACE` invece di `TRACE` a IE6.0 SP2.
2024-02-10 13:03:23 +00:00
* 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 un attacco [**Cookie Smuggling**](./#cookie-smuggling) per esfiltrare questi cookie
### Secure
La richiesta invierà il cookie solo in una richiesta HTTP solo se la richiesta viene trasmessa su un canale sicuro (tipicamente **HTTPS**).
## Prefissi dei Cookies
I cookies con prefisso `__Secure-` devono essere impostati insieme alla bandiera `secure` dalle pagine che sono protette da HTTPS.
Per i cookies con prefisso `__Host-`, devono essere soddisfatte diverse condizioni:
* Devono essere impostati con la bandiera `secure`.
* Devono provenire da una pagina protetta da HTTPS.
* È vietato specificare un dominio per questi cookie, impedendo la loro trasmissione ai sottodomini.
* Il percorso per questi cookie deve essere impostato su `/`.
È importante notare che i cookies con prefisso `__Host-` non sono consentiti di essere inviati a superdomini o sottodomini. Questa restrizione aiuta nell'isolamento dei cookies dell'applicazione. Pertanto, l'utilizzo del prefisso `__Host-` per tutti i cookies dell'applicazione può essere considerato una buona pratica per migliorare la sicurezza e l'isolamento.
### Sovrascrittura dei cookie
Quindi, una delle protezioni dei cookie con prefisso `__Host-` è quella di impedirne la sovrascrittura da parte dei sottodomini. Ad esempio, impedendo gli attacchi di [**Cookie Tossing**](cookie-tossing.md). Nella presentazione [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**documento**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) è stato presentato che era possibile impostare i 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 (3).png" alt=""><figcaption></figcaption></figure>
Oppure 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 (1) (1).png" alt="" width="373"><figcaption></figcaption></figure>
## Attacchi ai Cookie
Se un cookie personalizzato contiene dati sensibili, controllalo (specialmente se stai partecipando a un CTF), poiché potrebbe essere vulnerabile.
### Decodifica e Manipolazione dei Cookie
I dati sensibili incorporati nei cookie dovrebbero sempre essere esaminati attentamente. I cookie codificati in Base64 o formati simili possono spesso essere decodificati. Questa vulnerabilità consente agli attaccanti di modificare il contenuto del cookie e impersonare altri utenti codificando i loro dati modificati all'interno del cookie.
### Dirottamento di Sessione
Questo attacco coinvolge il furto del cookie di un utente per ottenere l'accesso non autorizzato al loro account all'interno di un'applicazione. Utilizzando il cookie rubato, un attaccante può impersonare l'utente legittimo.
### Fissazione di Sessione
In questo scenario, un attaccante inganna una vittima affinché utilizzi un cookie specifico per effettuare l'accesso. Se l'applicazione non assegna un nuovo cookie al momento del login, l'attaccante, possedendo il cookie originale, può impersonare la vittima. Questa tecnica si basa sul fatto che la vittima effettua l'accesso con un cookie fornito dall'attaccante.
Se hai trovato un **XSS in un sottodominio** o **controlli un sottodominio**, leggi:
2021-10-19 00:01:07 +00:00
{% content-ref url="cookie-tossing.md" %}
[cookie-tossing.md](cookie-tossing.md)
{% endcontent-ref %}
2024-02-10 13:03:23 +00:00
### Donazione di Sessione
Qui, l'attaccante convince la vittima a utilizzare il cookie di sessione dell'attaccante. La vittima, credendo di essere loggata nel proprio account, eseguirà involontariamente azioni nel contesto dell'account dell'attaccante.
2021-10-19 00:01:07 +00:00
Se hai trovato un **XSS in un sottodominio** o **controlli un sottodominio**, leggi:
2021-10-19 00:01:07 +00:00
{% content-ref url="cookie-tossing.md" %}
[cookie-tossing.md](cookie-tossing.md)
{% endcontent-ref %}
### [Cookie JWT](../hacking-jwt-json-web-tokens.md)
2024-02-10 13:03:23 +00:00
Clicca sul link precedente per accedere a una pagina che spiega possibili difetti nei JWT.
I JSON Web Tokens (JWT) utilizzati nei cookie possono presentare vulnerabilità. Per informazioni dettagliate su possibili difetti e su come sfruttarli, si consiglia di consultare il documento collegato sull'hacking dei JWT.
2024-02-05 20:00:40 +00:00
### Forgery delle Richieste Cross-Site (CSRF)
Questo attacco costringe un utente loggato 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.
2024-02-05 20:00:40 +00:00
### Cookie Vuoti
(Consulta ulteriori dettagli nella [ricerca originale](https://blog.ankursundara.com/cookie-bugs/)) I browser consentono la creazione di cookie senza nome, che possono essere dimostrati tramite JavaScript come segue:
```js
document.cookie = "a=v1"
2024-02-05 20:00:40 +00:00
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, ciò consente la manipolazione dei cookie se viene impostato un cookie con nome vuoto, potenzialmente controllando altri cookie impostando il cookie vuoto su un valore specifico:
```js
function setCookie(name, value) {
2024-02-10 13:03:23 +00:00
document.cookie = `${name}=${value}`;
}
2024-02-05 20:00:40 +00:00
setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value
```
Questo porta il browser a inviare un'intestazione del cookie interpretata da ogni server web come un cookie chiamato `a` con un valore `b`.
#### Bug di Chrome: Problema del Punto di Codice Surrogato Unicode
2024-02-10 13:03:23 +00:00
In Chrome, se un punto di codice surrogato Unicode fa parte di un cookie impostato, `document.cookie` diventa corrotto, restituendo successivamente una stringa vuota:
```js
document.cookie = "\ud800=meep";
```
Questo comporta che `document.cookie` produca una stringa vuota, indicando una corruzione permanente.
#### Traffico di Cookie a Causa di Problemi di Parsing
(Verifica ulteriori dettagli nella [ricerca originale](https://blog.ankursundara.com/cookie-bugs/)) Diversi server web, inclusi quelli in 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 del cookie tra virgolette doppie come un singolo valore anche se include punti e virgola, che normalmente dovrebbero separare le coppie chiave-valore:
```
2024-02-05 20:00:40 +00:00
RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
```
2024-02-10 13:03:23 +00:00
#### Vulnerabilità di Iniezione di Cookie
(Controlla ulteriori dettagli nella [ricerca originale](https://blog.ankursundara.com/cookie-bugs/)) L'errata interpretazione 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 di cookie. Questi server non delimitano correttamente l'inizio dei nuovi cookie, consentendo agli attaccanti di falsificare i cookie:
- Undertow si aspetta un nuovo cookie immediatamente dopo un valore quotato senza punto e virgola.
- Zope cerca una virgola per iniziare l'analisi del cookie successivo.
- Le classi dei cookie di Python iniziano l'analisi 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 falsificati del token CSRF, potenzialmente eludendo le misure di sicurezza. Il problema è aggravato dal modo in cui Python gestisce i nomi dei cookie duplicati, dove l'ultima occorrenza sovrascrive quelle precedenti. Solleva anche preoccupazioni per i cookie `__Secure-` e `__Host-` in contesti non sicuri e potrebbe portare a bypass dell'autorizzazione quando i cookie vengono passati a server back-end suscettibili di falsificazione.
### Controlli Extra sui Cookie Vulnerabili
2024-02-10 13:03:23 +00:00
#### **Controlli di base**
- Il **cookie** è **sempre lo stesso** ogni volta che **effettui il login**.
- Esegui il logout e prova a utilizzare lo stesso cookie.
- Prova a effettuare il login con 2 dispositivi (o browser) nello stesso account utilizzando lo stesso cookie.
- Controlla se il cookie contiene informazioni e prova a modificarlo.
- Prova a creare diversi account con username quasi identici e controlla se riesci a vedere somiglianze.
- Controlla l'opzione "**ricordami**" se esiste per capire come funziona. Se esiste e potrebbe essere vulnerabile, utilizza sempre il cookie di **ricordami** senza altri cookie.
- Verifica se il cookie precedente funziona anche dopo aver cambiato la password.
2024-02-10 13:03:23 +00:00
#### **Attacchi avanzati ai cookie**
Se il cookie rimane lo stesso (o quasi) quando effettui il login, probabilmente significa che il cookie è correlato a qualche campo del tuo account (probabilmente l'username). Quindi puoi:
- Prova a creare molti **account** con username molto **simili** e cerca di **indovinare** come funziona l'algoritmo.
- Prova a **bruteforce dell'username**. Se il cookie salva solo come metodo di autenticazione per il tuo username, puoi creare un account con username "**Bmin**" e **bruteforce** ogni singolo **bit** del tuo cookie perché uno dei cookie che proverai sarà quello appartenente a "**admin**".
- Prova **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 effettuerà diversi tentativi e ti chiederà quale condizione è la condizione di errore (quella non valida).
Successivamente inizierà a decifrare il cookie (potrebbero essere necessari diversi minuti)
2024-02-10 13:03:23 +00:00
Se l'attacco è stato eseguito con successo, potresti provare a crittografare una stringa a tua scelta. Ad esempio, se volessi **crittografare** **user=administrator**
```
padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator
```
Questo eseguirà correttamente il cookie correttamente crittografato e codificato con la stringa **user=administrator** all'interno.
**CBC-MAC**
Forse un cookie potrebbe avere un certo valore e potrebbe essere firmato utilizzando CBC. Quindi, l'integrità del valore è la firma creata utilizzando CBC con lo stesso valore. Poiché è consigliabile utilizzare come IV un vettore nullo, questo tipo di controllo dell'integrità potrebbe essere vulnerabile.
2024-02-10 13:03:23 +00:00
**L'attacco**
1. Ottenere la firma dell'username **administ** = **t**
2. Ottenere la firma dell'username **rator\x00\x00\x00 XOR t** = **t'**
3. Impostare 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 effettui l'accesso, il cookie che ricevi deve essere sempre lo stesso.
2024-02-10 13:03:23 +00:00
**Come rilevare e attaccare:**
Crea 2 utenti con dati quasi identici (username, password, email, ecc.) e cerca di scoprire qualche schema all'interno del cookie fornito
Crea un utente chiamato ad esempio "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" e controlla se c'è qualche schema nel cookie (poiché ECB crittografa con la stessa chiave ogni blocco, gli stessi byte crittografati potrebbero apparire se l'username è crittografato).
Dovrebbe esserci un modello (con la dimensione di un blocco utilizzato). Quindi, sapendo come sono crittografati un gruppo di "a" puoi creare un username: "a"\*(dimensione del blocco)+"admin". Quindi, potresti eliminare il modello crittografato di un blocco di "a" dal cookie. E avrai il cookie dell'username "admin".
2024-02-10 13:03:23 +00:00
## 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)
2023-09-02 23:48:41 +00:00
**Try Hard Security Group**
<figure><img src="../../.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
{% embed url="https://discord.gg/tryhardsecurity" %}
2022-04-28 16:01:33 +00:00
<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>
2022-04-28 16:01:33 +00:00
2024-02-10 13:03:23 +00:00
Altri modi per supportare HackTricks:
2024-01-01 17:15:10 +00:00
* 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.
2022-04-28 16:01:33 +00:00
</details>