<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Http Injection on Ethical Hacking | Pentest e Sicurezza Informatica | Hackita</title><link>https://hackita.it/tags/http-injection/</link><description>Recent content in Http Injection on Ethical Hacking | Pentest e Sicurezza Informatica | Hackita</description><generator>Hugo</generator><language>it</language><lastBuildDate>Sun, 15 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://hackita.it/tags/http-injection/index.xml" rel="self" type="application/rss+xml"/><item><title>HTTP Header Injection: Host Poisoning e X-Forwarded-For</title><link>https://hackita.it/articoli/http-header-injection/</link><pubDate>Sun, 15 Mar 2026 00:00:00 +0000</pubDate><guid>https://hackita.it/articoli/http-header-injection/</guid><description>&lt;p&gt;Ogni richiesta HTTP è composta da header che il browser invia al server: &lt;code&gt;Host:&lt;/code&gt;, &lt;code&gt;User-Agent:&lt;/code&gt;, &lt;code&gt;Referer:&lt;/code&gt;, &lt;code&gt;Cookie:&lt;/code&gt;, &lt;code&gt;Accept-Language:&lt;/code&gt;. Il server si fida di questi header per decidere come rispondere — quale sito mostrare (Host), quale IP loggare (X-Forwarded-For), quale URL mettere nelle email (X-Forwarded-Host). Ma tutti questi header sono &lt;strong&gt;controllati dall&amp;rsquo;attaccante&lt;/strong&gt;: basta un proxy come Burp Suite per modificarli arbitrariamente.&lt;/p&gt;
&lt;p&gt;La &lt;strong&gt;HTTP Header Injection&lt;/strong&gt; si verifica quando l&amp;rsquo;applicazione usa il valore di un header HTTP della request per generare contenuto, prendere decisioni di sicurezza, o costruire URL — senza validare che il valore sia legittimo. L&amp;rsquo;attacco più devastante è il &lt;strong&gt;Host Header Poisoning&lt;/strong&gt; applicato al password reset: l&amp;rsquo;applicazione genera il link di reset usando il valore dell&amp;rsquo;header &lt;code&gt;Host:&lt;/code&gt;, l&amp;rsquo;attaccante lo modifica in &lt;code&gt;Host: attacker.com&lt;/code&gt;, e la vittima riceve un&amp;rsquo;email con un link &lt;code&gt;http://attacker.com/reset?token=SECRET&lt;/code&gt;. Clic → token rubato → account compromesso.&lt;/p&gt;</description></item><item><title>HTTP Request Smuggling: Desync, Cache Poisoning e Cookie Theft</title><link>https://hackita.it/articoli/http-request-smuggling/</link><pubDate>Sun, 15 Mar 2026 00:00:00 +0000</pubDate><guid>https://hackita.it/articoli/http-request-smuggling/</guid><description>&lt;p&gt;L&amp;rsquo;&lt;strong&gt;HTTP Request Smuggling&lt;/strong&gt; sfrutta il disaccordo tra un reverse proxy (CDN, WAF, load balancer) e il backend su dove &lt;strong&gt;finisce una request HTTP e ne inizia un&amp;rsquo;altra&lt;/strong&gt;. HTTP offre due modi per indicare la lunghezza del body: &lt;code&gt;Content-Length&lt;/code&gt; (numero fisso di byte) e &lt;code&gt;Transfer-Encoding: chunked&lt;/code&gt; (body diviso in chunk). Se il proxy usa &lt;code&gt;Content-Length&lt;/code&gt; e il backend usa &lt;code&gt;Transfer-Encoding&lt;/code&gt; (o viceversa), l&amp;rsquo;attaccante &amp;ldquo;contrabbanda&amp;rdquo; una seconda request nascosta dentro la prima.&lt;/p&gt;</description></item></channel></rss>