1. Il DNS — Tradurre nomi in indirizzi
Quando digiti google.com nel browser, il tuo computer non sa a quale indirizzo IP connettersi. Il Domain Name System (DNS) è il sistema distribuito che risolve questo problema: traduce nomi di dominio leggibili dall’uomo in indirizzi IP usabili dalla rete. È, in sostanza, la rubrica telefonica di Internet.
www.example.com) in resource record (es. indirizzi IPv4/IPv6, server di posta, ecc.). Opera principalmente su UDP porta 53; TCP porta 53 per risposte grandi o trasferimenti di zona.1.1 Gerarchia dei namespace
I domini sono organizzati ad albero rovesciato. Ogni nodo è un label separato da punti, letto da destra verso sinistra:
com org it net edu ← TLD (Top Level Domain)
google amazon github ← Second-Level Domain (SLD)
www mail api cdn ← Subdomain (terzo livello)
Ogni livello ha i propri name server autorevoli (authoritative name server), che rispondono con dati definitivi per quella zona.
1.2 Il processo di risoluzione DNS
Quando il tuo browser vuole risolvere www.profgiagnotti.it, avvengono questi passi:
- Browser → cache locale → trovato? ✓ Fine
- Browser → stub resolver (OS) → cache OS
- Stub resolver → resolver ricorsivo (ISP/8.8.8.8)
- Resolver → root server (13 cluster, es. a.root-servers.net)
- Root → referral a TLD server per
.it - TLD server → referral a authoritative NS di profgiagnotti.it
- Authoritative → risponde con A record (IP)
- Resolver → risponde al client, salva in cache (TTL)
| Tipo | Chi la fa | Attesa |
|---|---|---|
| Ricorsiva | Stub resolver → recursive resolver | Risposta finale o errore |
| Iterativa | Recursive resolver → root/TLD/auth | Referral o risposta |
| Non ricorsiva | Se il resolver ha già il dato in cache | Risposta immediata |
Immagina di cercare il numero di telefono di un ristorante. Prima guardi la tua agenda (cache locale), poi chiedi all’operatore del centralino del tuo Comune (resolver ricorsivo), che a sua volta chiama la directory nazionale (root), poi quella regionale (TLD), poi quella della città (authoritative). Il centralino ti richiama con il numero trovato.
1.3 I principali tipi di record DNS
| Tipo | Significato | Esempio | Nota sicurezza |
|---|---|---|---|
A | IPv4 address | profgiagnotti.it → 93.184.216.34 | Target principale DNS spoofing |
AAAA | IPv6 address | profgiagnotti.it → 2001:db8::1 | — |
CNAME | Alias (canonical name) | www → profgiagnotti.it | Non usare per MX/NS |
MX | Mail exchanger | @ → mail.profgiagnotti.it (prio 10) | Target per email spoofing |
NS | Name server autorevole | @ → ns1.hostingprovider.com | NS hijacking |
TXT | Testo libero | SPF, DKIM, DMARC, verifica dominio | Usato per anti-spoofing email |
PTR | Reverse lookup (IP → nome) | 34.216.184.93.in-addr.arpa → host | Usato da tool recon |
SOA | Start of Authority | Primary NS, email admin, serial, TTL | Espone info infrastruttura |
1.4 Il caching e il TTL
Ogni record DNS ha un TTL (Time To Live) in secondi. Dopo la scadenza, il resolver deve rifare la query. Un TTL basso (es. 60s) permette cambiamenti rapidi (failover, migrations) ma aumenta il carico sui name server. Un TTL alto (es. 86400s = 1 giorno) riduce il traffico ma rallenta la propagazione dei cambiamenti.
Un attaccante inietta record DNS falsi nella cache del resolver. La vittima viene reindirizzata a un IP malevolo pur digitando il nome corretto. L’attacco Kaminsky (2008) sfruttava la prevedibilità del port source e del transaction ID DNS per avvelenarla sistematicamente. Mitigazione: DNSSEC (firma crittografica dei record), randomizzazione porta sorgente, DoH/DoT (DNS over HTTPS/TLS).
Comandi utili per interrogare il DNS dal terminale:
# Query record A nslookup profgiagnotti.it dig profgiagnotti.it A # Query MX dig profgiagnotti.it MX # Reverse lookup dig -x 93.184.216.34 # Trace completo (percorso ricorsivo) dig +trace profgiagnotti.it # Query a un resolver specifico dig @8.8.8.8 profgiagnotti.it
2. HTTP — Il protocollo del Web
HTTP (HyperText Transfer Protocol) è il protocollo applicativo su cui si basa il World Wide Web. È un protocollo testuale, stateless (ogni richiesta è indipendente dalla precedente) basato su modello client-server. Oggi esiste in tre versioni principali: HTTP/1.1 (RFC 2616/7230), HTTP/2 (RFC 7540) e HTTP/3 (RFC 9114).
2.1 Struttura di una richiesta HTTP
GET /corsi/cybersecurity HTTP/1.1 Host: profgiagnotti.it User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Accept: text/html,application/xhtml+xml Accept-Language: it-IT,it;q=0.9 Accept-Encoding: gzip, deflate, br Connection: keep-alive Cookie: session_id=abc123xyz; _ga=GA1.2.1234567890
METODO /percorso HTTP/versione
Il metodo indica l’azione richiesta. Il percorso (URI) identifica la risorsa. La versione del protocollo.
Coppie Nome: Valore che portano metadati: chi fa la richiesta (Host), che tipo di risposta accetta (Accept), cookie, credenziali, ecc.
2.2 I metodi HTTP
| Metodo | Scopo | Idempotente | Body richiesta | Nota sicurezza |
|---|---|---|---|---|
GET | Leggi risorsa | ✓ Sì | No | Parametri in URL (visibili nei log) |
POST | Crea risorsa / invia dati | ✗ No | Sì | Dati nel body (non in URL) |
PUT | Sostituisce risorsa | ✓ Sì | Sì | Richiede autenticazione |
PATCH | Modifica parziale | ✗ No | Sì | Richiede autenticazione |
DELETE | Elimina risorsa | ✓ Sì | Opzionale | Richiede autorizzazione |
HEAD | Solo headers (no body) | ✓ Sì | No | Usato per fingerprinting |
OPTIONS | Metodi disponibili / CORS preflight | ✓ Sì | No | Può rivelare metodi abilitati |
2.3 Struttura di una risposta HTTP
HTTP/1.1 200 OK Date: Fri, 10 Apr 2026 14:32:00 GMT Server: nginx/1.24.0 Content-Type: text/html; charset=UTF-8 Content-Length: 8453 Cache-Control: max-age=3600 Set-Cookie: session_id=abc123xyz; HttpOnly; Secure; SameSite=Strict X-Content-Type-Options: nosniff X-Frame-Options: DENY Strict-Transport-Security: max-age=31536000; includeSubDomains [HTML body...]
2.4 I codici di stato HTTP
101 Switching
201 Created
204 No Content
302 Found
304 Not Modified
401 Unauthorized
403 Forbidden
404 Not Found
502 Bad Gateway
503 Unavailable
Un 403 significa che la risorsa esiste ma non sei autorizzato: conferma l’esistenza del path. Un 404 significa che la risorsa non esiste (o il server mente). Un 405 Method Not Allowed rivela che il path esiste ma non accetta quel metodo. Questi dettagli sono utili in fase di recon e enumeration.
2.5 Evoluzione: HTTP/1.1 → HTTP/2 → HTTP/3
| Versione | Anno | Trasporto | Caratteristica chiave | Problema risolto |
|---|---|---|---|---|
| HTTP/1.1 | 1997 | TCP | Persistent connections, pipelining (limitato) | Head-of-line blocking per richiesta |
| HTTP/2 | 2015 | TCP + TLS | Multiplexing binario, header compression (HPACK), server push | HOL blocking a livello HTTP, overhead headers |
| HTTP/3 | 2022 | QUIC (UDP) | Stream indipendenti, 0-RTT, migration connessione | HOL blocking a livello TCP, connessioni lente su mobile |
3. HTTPS — Sicurezza nel trasporto
HTTP è in chiaro: chiunque intercetti il traffico vede richieste, risposte, cookie, credenziali. HTTPS = HTTP + TLS: TLS (Transport Layer Security) cifra il canale e autentica il server prima di trasferire qualsiasi dato applicativo.
Su una rete Wi-Fi pubblica senza HTTPS, un attaccante può intercettare tutto il traffico usando strumenti come ettercap o mitmproxy: legge username, password, cookie di sessione. Con un attacco SSL stripping (sslstrip) può anche degradare HTTPS a HTTP se il server non implementa HSTS.
3.1 Il TLS Handshake (semplificato)
In TLS 1.3 (attuale), l’handshake è ridotto a 1-RTT (o 0-RTT per sessioni riprese), usa solo algoritmi moderni (AES-GCM, ChaCha20-Poly1305) e garantisce Perfect Forward Secrecy tramite ECDHE: anche se la chiave privata del server venisse compromessa in futuro, le sessioni passate restano cifrate.
3.2 Il certificato X.509 e la PKI
- Subject (CN, O, C del proprietario)
- Issuer (CA che ha firmato)
- Validità (notBefore, notAfter)
- Chiave pubblica (RSA/ECDSA)
- SAN (Subject Alternative Names)
- Firma digitale della CA
- Numero seriale univoco
Il browser si fida dei Root CA inclusi nel OS/browser (Mozilla, Microsoft, Apple). I Root CA firmano Intermediate CA, che firmano i certificati dei siti. Questa catena verifica che il sito sia chi dice di essere.
⚠ Se un attaccante installa un certificato Root CA falso nel tuo sistema (es. malware), può eseguire MITM anche su HTTPS.
3.3 HSTS — Forzare HTTPS
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Una volta ricevuto questo header, il browser ricorderà per max-age secondi (1 anno = 31536000) di usare solo HTTPS per quel dominio. Impedisce SSL stripping. La lista HSTS preload (hstspreload.org) fa sì che i browser conoscano il sito prima della prima visita.
4. Sessioni e Cookie
HTTP è stateless: ogni richiesta è indipendente. Il server non ricorda chi sei tra una richiesta e l’altra. Le sessioni risolvono questo problema: dopo il login, il server crea un identificatore univoco (session ID) e lo invia al browser. Il browser lo rinvia in ogni richiesta successiva.
4.1 Meccanismo dei cookie
# Server invia cookie dopo login HTTP/1.1 200 OK Set-Cookie: session_id=f9a3c7b1e2d4; Path=/; HttpOnly; Secure; SameSite=Strict; Max-Age=3600 # Client rimanda il cookie in ogni richiesta GET /dashboard HTTP/1.1 Cookie: session_id=f9a3c7b1e2d4
4.2 Attributi di sicurezza dei cookie
| Attributo | Effetto | Attacco mitigato |
|---|---|---|
HttpOnly | JavaScript non può leggere il cookie | XSS (Cross-Site Scripting) cookie theft |
Secure | Inviato solo su HTTPS | Intercettazione su HTTP / network sniffing |
SameSite=Strict | Non inviato in richieste cross-site | CSRF (Cross-Site Request Forgery) |
SameSite=Lax | Inviato solo per navigazione GET top-level | CSRF (protezione parziale) |
SameSite=None; Secure | Inviato sempre (terze parti) | ⚠ Nessuna protezione CSRF |
Max-Age / Expires | Durata del cookie | Limita la finestra di attacco |
Path | Scope del cookie nel sito | Isola cookie tra sezioni |
Se un attaccante ottiene il session ID (via XSS, MITM su HTTP, o sniffing Wi-Fi), può impersonare la vittima senza conoscere la password. Strumenti come Cookie Editor (estensione browser) o Burp Suite permettono di sostituire il session ID. Contromisure: HttpOnly, Secure, session ID randomico e lungo (≥128 bit), rotazione del session ID dopo il login, binding a IP/User-Agent.
4.3 JWT — Token stateless per le API
Le applicazioni moderne usano spesso JWT (JSON Web Token) invece dei session ID classici. Un JWT è auto-contenuto: include l’identità dell’utente e viene firmato dal server.
HEADER (algo + tipo) . PAYLOAD (dati utente, exp) . SIGNATURE (HMAC/RSA)
⚠ Attenzione: Il payload JWT è solo codificato in Base64, non cifrato — chiunque può decodificarlo e leggerlo. Va cifrato separatamente (JWE) se contiene dati sensibili. Il valore di sicurezza sta solo nella firma.
- Il DNS traduce nomi in IP attraverso una gerarchia distribuita (root → TLD → authoritative); la cache con TTL riduce il carico ma è vulnerabile al cache poisoning
- HTTP è stateless e testuale; la richiesta ha metodo + URI + headers + body; la risposta ha status code + headers + body
- HTTPS = HTTP + TLS: cifra il canale, autentica il server con certificato X.509, protegge da MITM; HSTS impedisce downgrade a HTTP
- Le sessioni risolvono la statelessness di HTTP; i cookie devono avere gli attributi
HttpOnly,Secure,SameSiteper essere sicuri - I principali vettori di attacco a questo livello sono: DNS spoofing, MITM su HTTP, cookie hijacking, session fixation