From ac5bcb06c0941463abf1c6b609bff32fbe07a762 Mon Sep 17 00:00:00 2001 From: Translator Date: Fri, 5 Sep 2025 11:18:04 +0000 Subject: [PATCH] Translated ['src/network-services-pentesting/pentesting-web/special-http --- .../pentesting-web/special-http-headers.md | 147 ++++--- .../http-request-smuggling/README.md | 372 ++++++++++-------- theme/sponsor.js | 3 +- 3 files changed, 296 insertions(+), 226 deletions(-) diff --git a/src/network-services-pentesting/pentesting-web/special-http-headers.md b/src/network-services-pentesting/pentesting-web/special-http-headers.md index 8df533637..42838183f 100644 --- a/src/network-services-pentesting/pentesting-web/special-http-headers.md +++ b/src/network-services-pentesting/pentesting-web/special-http-headers.md @@ -1,4 +1,4 @@ -# Special HTTP headers +# Header HTTP speciali {{#include ../../banners/hacktricks-training.md}} @@ -7,9 +7,9 @@ - [https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers](https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers) - [https://github.com/rfc-st/humble](https://github.com/rfc-st/humble) -## Headers to Change Location +## Header per modificare la Location -Rewrite **IP source**: +Riscrivere **origine IP**: - `X-Originating-IP: 127.0.0.1` - `X-Forwarded-For: 127.0.0.1` @@ -26,19 +26,20 @@ Rewrite **IP source**: - `True-Client-IP: 127.0.0.1` - `Cluster-Client-IP: 127.0.0.1` - `Via: 1.0 fred, 1.1 127.0.0.1` -- `Connection: close, X-Forwarded-For` (Controlla gli header hop-by-hop) +- `Connection: close, X-Forwarded-For` (Controllare gli hop-by-hop headers) -Rewrite **location**: +Riscrivere **location**: - `X-Original-URL: /admin/console` - `X-Rewrite-URL: /admin/console` ## Hop-by-Hop headers -Un header hop-by-hop è un header progettato per essere elaborato e consumato dal proxy che gestisce attualmente la richiesta, a differenza di un header end-to-end. +Un hop-by-hop header è un'intestazione progettata per essere elaborata e consumata dal proxy che sta gestendo la richiesta, al contrario di un header end-to-end. - `Connection: close, X-Forwarded-For` + {{#ref}} ../../pentesting-web/abusing-hop-by-hop-headers.md {{#endref}} @@ -48,78 +49,98 @@ Un header hop-by-hop è un header progettato per essere elaborato e consumato da - `Content-Length: 30` - `Transfer-Encoding: chunked` + {{#ref}} ../../pentesting-web/http-request-smuggling/ {{#endref}} -## Cache Headers +## L'header Expect + +È possibile che il client invii l'header `Expect: 100-continue` e che il server risponda con `HTTP/1.1 100 Continue` per permettere al client di continuare a inviare il body della richiesta. Tuttavia, alcuni proxy non gradiscono questo header. + +Risultati interessanti di `Expect: 100-continue`: +- Inviare una HEAD request con un body: il server non tiene conto che le HEAD non devono avere body e mantiene la connessione aperta fino al timeout. +- Alcuni server hanno restituito dati strani: dati casuali letti dal socket nella risposta, chiavi segrete o addirittura è servito a impedire al front-end di rimuovere certi valori di header. +- Ha anche causato un desync `0.CL` perché il backend ha risposto con un 400 invece di un 100, ma il proxy front-end era pronto a inviare il body della richiesta iniziale; quindi lo invia e il backend lo interpreta come una nuova richiesta. +- Inviare una variazione come `Expect: y 100-continue` ha causato anch'essa il desync `0.CL`. +- Un errore simile in cui il backend ha risposto con un 404 ha generato un desync `CL.0` perché la richiesta malevola indicava un `Content-Length`; così il backend invia la richiesta malevola + i `Content-Length` byte della richiesta successiva (di una vittima). Questo desincronizza la coda perché il backend invia la risposta 404 per la richiesta malevola + la risposta delle richieste della vittima, mentre il front-end pensava che fosse stata inviata una sola richiesta, quindi la seconda risposta viene inviata a una seconda vittima e la risposta di quella viene inviata alla successiva... + +Per maggiori informazioni su HTTP Request Smuggling controlla: + +{{#ref}} +../../pentesting-web/http-request-smuggling/ +{{#endref}} + + +## Intestazioni di Cache **Server Cache Headers**: -- **`X-Cache`** nella risposta può avere il valore **`miss`** quando la richiesta non è stata memorizzata nella cache e il valore **`hit`** quando è memorizzata nella cache +- **`X-Cache`** nella risposta può avere il valore **`miss`** quando la richiesta non è stata cacheata e il valore **`hit`** quando lo è - Comportamento simile nell'header **`Cf-Cache-Status`** -- **`Cache-Control`** indica se una risorsa è memorizzata nella cache e quando sarà la prossima volta che la risorsa sarà memorizzata di nuovo: `Cache-Control: public, max-age=1800` -- **`Vary`** è spesso usato nella risposta per **indicare header aggiuntivi** che sono trattati come **parte della chiave della cache** anche se normalmente non sono chiave. -- **`Age`** definisce il tempo in secondi in cui l'oggetto è stato nella cache del proxy. -- **`Server-Timing: cdn-cache; desc=HIT`** indica anche che una risorsa è stata memorizzata nella cache +- **`Cache-Control`** indica se una risorsa viene cacheata e per quanto tempo: `Cache-Control: public, max-age=1800` +- **`Vary`** è spesso usato nella risposta per **indicare header aggiuntivi** che sono considerati **parte della chiave di cache** anche se normalmente non lo sono. +- **`Age`** definisce i secondi trascorsi da quando l'oggetto è nella cache del proxy. +- **`Server-Timing: cdn-cache; desc=HIT`** indica anch'esso che una risorsa è stata cacheata + {{#ref}} ../../pentesting-web/cache-deception/ {{#endref}} -**Local Cache headers**: +**Intestazioni Cache locali**: -- `Clear-Site-Data`: Header per indicare la cache che dovrebbe essere rimossa: `Clear-Site-Data: "cache", "cookies"` -- `Expires`: Contiene la data/ora in cui la risposta dovrebbe scadere: `Expires: Wed, 21 Oct 2015 07:28:00 GMT` -- `Pragma: no-cache` stesso di `Cache-Control: no-cache` -- `Warning`: L'header generale **`Warning`** contiene informazioni su possibili problemi con lo stato del messaggio. Più di un header `Warning` può apparire in una risposta. `Warning: 110 anderson/1.3.37 "Response is stale"` +- `Clear-Site-Data`: Header per indicare quali cache devono essere rimosse: `Clear-Site-Data: "cache", "cookies"` +- `Expires`: Contiene la data/ora in cui la risposta deve scadere: `Expires: Wed, 21 Oct 2015 07:28:00 GMT` +- `Pragma: no-cache` equivalente a `Cache-Control: no-cache` +- `Warning`: L'header generale **`Warning`** contiene informazioni su possibili problemi con lo stato del messaggio. Possono apparire più header `Warning` in una risposta. `Warning: 110 anderson/1.3.37 "Response is stale"` -## Conditionals +## Condizionali -- Le richieste che utilizzano questi header: **`If-Modified-Since`** e **`If-Unmodified-Since`** riceveranno una risposta con dati solo se l'header di risposta **`Last-Modified`** contiene un orario diverso. -- Le richieste condizionali che utilizzano **`If-Match`** e **`If-None-Match`** usano un valore Etag in modo che il server web invii il contenuto della risposta se i dati (Etag) sono cambiati. L'`Etag` è preso dalla risposta HTTP. -- Il valore **Etag** è solitamente **calcolato** in base al **contenuto** della risposta. Ad esempio, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` indica che l'`Etag` è il **Sha1** di **37 byte**. +- Le richieste che usano gli header **`If-Modified-Since`** e **`If-Unmodified-Since`** riceveranno la risposta con i dati solo se l'header di risposta **`Last-Modified`** contiene un orario diverso. +- Le richieste condizionali che usano **`If-Match`** e **`If-None-Match`** utilizzano un valore Etag, quindi il web server invierà il contenuto della risposta se il dato (Etag) è cambiato. L'`Etag` viene preso dalla risposta HTTP. +- Il valore **Etag** è solitamente **calcolato** in base al **contenuto** della risposta. Per esempio, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` indica che l'Etag è lo **Sha1** di **37 byte**. ## Range requests -- **`Accept-Ranges`**: Indica se il server supporta le richieste di intervallo e, in tal caso, in quale unità l'intervallo può essere espresso. `Accept-Ranges: ` -- **`Range`**: Indica la parte di un documento che il server dovrebbe restituire. Ad esempio, `Range:80-100` restituirà i byte da 80 a 100 della risposta originale con un codice di stato di 206 Contenuto Parziale. Ricorda anche di rimuovere l'header `Accept-Encoding` dalla richiesta. -- Questo potrebbe essere utile per ottenere una risposta con codice JavaScript riflesso arbitrario che altrimenti potrebbe essere sfuggito. Ma per abusare di questo dovresti iniettare questi header nella richiesta. -- **`If-Range`**: Crea una richiesta di intervallo condizionale che viene soddisfatta solo se l'etag o la data forniti corrispondono alla risorsa remota. Usato per prevenire il download di due intervalli da versioni incompatibili della risorsa. -- **`Content-Range`**: Indica dove in un messaggio a corpo completo appartiene un messaggio parziale. +- **`Accept-Ranges`**: Indica se il server supporta le range requests, e se sì in quale unità la range può essere espressa. `Accept-Ranges: ` +- **`Range`**: Indica la parte di un documento che il server dovrebbe restituire. Per esempio, `Range:80-100` restituirà i byte 80-100 della risposta originale con codice 206 Partial Content. Ricorda inoltre di rimuovere l'header `Accept-Encoding` dalla richiesta. +- Questo può essere utile per ottenere una risposta con codice javascript riflesso arbitrario che altrimenti potrebbe essere escapato. Ma per abusarne dovresti iniettare questi header nella richiesta. +- **`If-Range`**: Crea una range request condizionale che viene soddisfatta solo se l'etag o la data fornita corrispondono alla risorsa remota. Utilizzato per evitare di scaricare due range da versioni incompatibili della risorsa. +- **`Content-Range`**: Indica dove, in un messaggio body completo, appartiene il messaggio parziale. -## Message body information +## Informazioni sul corpo del messaggio - **`Content-Length`:** La dimensione della risorsa, in numero decimale di byte. -- **`Content-Type`**: Indica il tipo di media della risorsa +- **`Content-Type`**: Indica il media type della risorsa - **`Content-Encoding`**: Usato per specificare l'algoritmo di compressione. -- **`Content-Language`**: Descrive la/e lingua/e umana/e destinate al pubblico, in modo che consenta a un utente di differenziare in base alla lingua preferita dell'utente. +- **`Content-Language`**: Descrive la/ le lingua/e umane destinate al pubblico, permettendo all'utente di differenziare secondo le proprie preferenze linguistiche. - **`Content-Location`**: Indica una posizione alternativa per i dati restituiti. -Dal punto di vista di un pentest, queste informazioni sono solitamente "inutili", ma se la risorsa è **protetta** da un 401 o 403 e riesci a trovare un **modo** per **ottenere** queste **info**, questo potrebbe essere **interessante.**\ -Ad esempio, una combinazione di **`Range`** e **`Etag`** in una richiesta HEAD può rivelare il contenuto della pagina tramite richieste HEAD: +Dal punto di vista di un pentest queste informazioni sono solitamente "inutili", ma se la risorsa è **protetta** da un 401 o 403 e trovi un qualche **modo** per **ottenere** queste **info**, potrebbe essere **interessante.**\ +Per esempio, una combinazione di **`Range`** ed **`Etag`** in una HEAD request può leakare il contenuto della pagina tramite richieste HEAD: -- Una richiesta con l'header `Range: bytes=20-20` e con una risposta contenente `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` sta rivelando che il SHA1 del byte 20 è `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y` +- Una richiesta con l'header `Range: bytes=20-20` e con una risposta contenente `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` sta leakando che lo SHA1 del byte 20 è `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y` -## Server Info +## Informazioni sul server - `Server: Apache/2.4.1 (Unix)` - `X-Powered-By: PHP/5.3.3` -## Controls +## Controlli -- **`Allow`**: Questo header è usato per comunicare i metodi HTTP che una risorsa può gestire. Ad esempio, potrebbe essere specificato come `Allow: GET, POST, HEAD`, indicando che la risorsa supporta questi metodi. -- **`Expect`**: Utilizzato dal client per comunicare le aspettative che il server deve soddisfare affinché la richiesta venga elaborata con successo. Un caso d'uso comune coinvolge l'header `Expect: 100-continue`, che segnala che il client intende inviare un grande payload di dati. Il client cerca una risposta `100 (Continue)` prima di procedere con la trasmissione. Questo meccanismo aiuta a ottimizzare l'uso della rete attendendo la conferma del server. +- **`Allow`**: Questo header è usato per comunicare i metodi HTTP che una risorsa può gestire. Per esempio, potrebbe essere `Allow: GET, POST, HEAD`, indicando che la risorsa supporta questi metodi. +- **`Expect`**: Utilizzato dal client per comunicare aspettative che il server deve soddisfare affinché la richiesta venga processata con successo. Un uso comune è l'header `Expect: 100-continue`, che segnala l'intenzione del client di inviare un payload di grandi dimensioni. Il client si aspetta una risposta `100 (Continue)` prima di procedere con la trasmissione. Questo meccanismo aiuta a ottimizzare l'uso della rete attendendo la conferma del server. -## Downloads +## Download -- L'header **`Content-Disposition`** nelle risposte HTTP indica se un file dovrebbe essere visualizzato **inline** (all'interno della pagina web) o trattato come un **allegato** (scaricato). Ad esempio: +- L'header **`Content-Disposition`** nelle risposte HTTP indica se un file deve essere mostrato **inline** (all'interno della pagina) o trattato come **attachment** (scaricato). Per esempio: ``` Content-Disposition: attachment; filename="filename.jpg" ``` -Questo significa che il file chiamato "filename.jpg" è destinato ad essere scaricato e salvato. +Questo significa che il file chiamato "filename.jpg" è destinato a essere scaricato e salvato. -## Intestazioni di Sicurezza +## Intestazioni di sicurezza ### Content Security Policy (CSP) @@ -128,9 +149,9 @@ Questo significa che il file chiamato "filename.jpg" è destinato ad essere scar ../../pentesting-web/content-security-policy-csp-bypass/ {{#endref}} -### **Tipi Fidati** +### **Trusted Types** -Imponendo i Tipi Fidati tramite CSP, le applicazioni possono essere protette contro attacchi DOM XSS. I Tipi Fidati garantiscono che solo oggetti specificamente progettati, conformi alle politiche di sicurezza stabilite, possano essere utilizzati in chiamate API web pericolose, garantendo così la sicurezza del codice JavaScript per impostazione predefinita. +Applicando Trusted Types tramite CSP, le applicazioni possono essere protette contro attacchi DOM XSS. Trusted Types garantiscono che solo oggetti appositamente creati, conformi alle policy di sicurezza stabilite, possano essere usati in chiamate API web pericolose, proteggendo così il codice JavaScript per impostazione predefinita. ```javascript // Feature detection if (window.trustedTypes && trustedTypes.createPolicy) { @@ -149,19 +170,19 @@ el.innerHTML = escaped // Results in safe assignment. ``` ### **X-Content-Type-Options** -Questo header previene il MIME type sniffing, una pratica che potrebbe portare a vulnerabilità XSS. Garantisce che i browser rispettino i tipi MIME specificati dal server. +Questo header impedisce il MIME type sniffing, una pratica che potrebbe portare a vulnerabilità XSS. Garantisce che i browser rispettino i MIME types specificati dal server. ``` X-Content-Type-Options: nosniff ``` ### **X-Frame-Options** -Per combattere il clickjacking, questo header limita come i documenti possono essere incorporati nei tag ``, `