{"id":1434,"date":"2014-01-01T09:30:31","date_gmt":"2014-01-01T08:30:31","guid":{"rendered":"http:\/\/christeninformatica.ch\/?p=1434"},"modified":"2022-08-15T10:50:43","modified_gmt":"2022-08-15T08:50:43","slug":"il-protocollo-http-tratto-dal-libro-hacking-web-sicurezza-nel-groviglio-della-rete-italiano","status":"publish","type":"post","link":"https:\/\/christeninformatica.ch\/it\/il-protocollo-http-tratto-dal-libro-hacking-web-sicurezza-nel-groviglio-della-rete-italiano\/","title":{"rendered":"Hacking Web: Sicurezza nel groviglio della rete – Il protocollo http"},"content":{"rendered":"

II concetto fondamentale che dobbiamo trattare a questo punto \u00e8 il protocollo HTTP (HyperText Transfer Protocol), che costituisce il meccanismo di trasferimento alla base del Web e il metodo preferito per scambiare documenti indicizzati da URL tra server e client. Nonostante la presenza del termine hypertext nel nome, il protocollo HTTP e il vero e proprio contenuto ipertestuale (il linguaggio HTML) spesso esistono indipendentemente l\u2019uno dall\u2019altro. Ci\u00f2 premesso, a volte sono intrecciati anche in modi sorprendenti.<\/p>\n

La storia di HTTP<\/b> offre un\u2019interessante visione sulle ambizioni dell\u2019autore e sulla crescente rilevanza di Internet. La prima bozza del protocollo (HTTP\/0.91) datata 1991 \u00e8 scritta da Tim Berners-Lee<\/b>, era lunga a malapena una pagina e mezza e mancava anche delle pi\u00f9 intuitive funzioni che si sarebbero rese necessarie in futuro, come l\u2019estendibilit\u00e0 richiesta per la trasmissione di dati non HTML.<\/p>\n

Cinque anni e diverse iterazioni della specifica dopo, il primo standard ufficiale HTTP\/1.0 (RFC 19452) prov\u00f2 a rettificare queste mancanze in circa 50 pagine fitte di testo. Arriviamo al 1999 e con HTTP\/1.1 (RFC 26163) i sette autori accreditati tentarono di anticipare quasi ogni possibile utilizzo del protocollo, creando un volume di 150 pagine.<\/p>\n

E non \u00e8 tutto: al momento in cui scriviamo, si lavora su HTTPbis4, sostanzialmente un sostituto di HTTP\/1.1, con una specifica di circa 360 pagine. Anche se molto del con\u00adtenuto accumulato \u00e8 irrilevante per il Web moderno, questa progressione evidenzia che il desiderio di aggiungere nuove funzioni supera di gran lunga quello di rimuovere le funzioni scarsamente utilizzate.<\/p>\n

Oggi tutti i client e server supportano un sovrainsieme non proprio accurato di HTTP\/1.0, mentre la maggioranza parla un dialetto ragionevolmente completo di HTTP\/1.1<\/b>, con l\u2019aggiunta di alcune eccezioni. Nonostante non esista alcun motivo pratico per farlo, molti server web e tutti i browser pi\u00f9 comuni mantengono la compa\u00adtibility all\u2019indietro con HTTP\/0.9.<\/p>\n

Sintassi di base del traffico HTTP<\/h2>\n

A prima vista HTTP<\/b> \u00e8 un semplice protocollo di testo basato su TCP\/IP<\/b>. TCP (Tran\u00adsmission Control Protocol) \u00e8 uno dei protocolli di comunicazione alla base di Internet. Fornisce il livello di trasporto a tutti i protocolli applicativi basati su di esso.<\/p>\n

Offre una connettivit\u00e0 ragionevolmente affidabile, ordinata, con mutuo riconoscimento e orientata alle sessioni tra host di rete. Nella maggioranza dei casi tale protocollo si dimostra anche abbastanza resistente rispetto ad attacchi – come il blind packet spoofing – portati da altri host non locali su Internet. Ogni sessione HTTP comincia stabilendo una connessione TCP al server, tipicamente sulla porta 80, quindi effettuando una richiesta contenente un URL. In risposta, il server produce il file richiesto e, nel caso pi\u00f9 rudimentale, chiude la connessione TCP immediatamente dopo.<\/p>\n

Lo standard HTTP\/0.9 originale non prevedeva alcuno spazio per lo scambio di metadati aggiuntivi tra le parti coinvolte. La richiesta del client consisteva sempre di un\u2019unica riga, che iniziava con GET seguito dal percorso e dalla stringa di query dell\u2019URL e terminata con un singolo avanzamento di riga CRLF (codici ASCII OxOD OxOA; per i server era consigliato accettare anche un singolo LF). Una richiesta HTTP\/0.9 poteva quindi avere l\u2019aspetto seguente:<\/p>\n

\n
\n
GET \/-fuzzy_bunnies.txt\n<\/pre>\n<\/blockquote>\n<\/div>\n
In risposta a questo messaggio, il server inviava immediatamente il carico di dati HTML. La specifica richiedeva che i server restituissero righe lunghe esattamente 80 caratteri, ma questo consiglio non e mai stato seguito da nessuno.<\/p>\n
L’approccio di HTTP\/0.9 presenta diverse lacune sostanziali. Per esempio, non da modo al browser di comunicare le preferenze linguistiche dell\u2019utente, di fornire un elenco di tipologie di documenti supportati, e cos\u00ec via. Inoltre non da modo al server di informare che il file richiesto non e stato trovato, che \u00e8 stato spostato a un altro indirizzo o che il file scaricato non \u00e8 un documento HTML – solo per iniziare.<\/p>\n
Infine, il protocollo non \u00e8 gentile con gli amministratori dei server: essendo l\u2019URL limitato a percorso e stringa di query, \u00e8 impossibile per un server ospitare siti diversi, distinti dai loro nomi di host, con un solo indirizzo IP e – a differenza dei record DNS – gli indirizzi IP non sono economici.<\/p>\n
Per sanare queste lacune (e per fare spazio a futuri trucchi), gli standard HTTP\/1.0 e HTTP\/1.1 implementano un formato di conversazione leggermente differente: alla prima riga della richiesta viene aggiunta la versione del protocollo utilizzato, di seguito potranno esserci zero o pi\u00f9 coppie nome: valore (note come header) ciascuna su una riga a s\u00e9. Gli header pi\u00f9 comuni che si possono trovare nelle richieste sono User-Agent (la versione del browser), Host (il nome dell\u2019host presente nell\u2019URL), Accept (i tipi di documento MIME supportati. II tipo MIME, noto anche come Internet media type, \u00e8 un semplice valore formato da due componenti che identifica la classe e il formato di ogni tipo di file. IL concetto nasce negli RFC 2045 e RFC 2046, dove serviva a descrivere i vari tipi di allegati della posta elettronica.<\/p>\n
L\u2019elenco ufficiale di tali valori, come text\/plain o audio\/mpeg, \u00e8 attualmente mantenuto dall\u2019IANA, ma tipi ad hoc sono decisamente comuni), Accept-Language (le lingue accettate) e Referer (un campo – dal nome curiosamente scritto in modo errato per la lingua inglese – che indica la pagina di provenienza della richiesta, se esiste).<\/p>\n
Gli header si concludono con un\u2019unica riga vuota, la quale pu\u00f2 essere seguita da qualsiasi dato il client voglia passare al server (la cui lunghezza in byte dev\u2019essere specificata esplicitamente con l\u2019header Content-Length).<\/p>\n
Il contenuto di questo carico di dati e opaco per il protocollo; in HTML questo spazio viene generalmente utilizzato per l\u2019invio dei dati dei moduli in uno dei diversi formati possibili, anche se non \u00e8 in alcun modo vincolante.<\/p>\n
Quindi, una richiesta HTTP\/1.1 pu\u00f2 avere l\u2019aspetto seguente:<\/p>\n
\n
\n
POST \/fuzzy_bunnies\/bunny_dispenser.php HTTP\/1.1 Host: www.fuzzybunnies.com User-Agent: Bunny-Browser\/1.7 Content-Type: text\/plain Content-Length: 17\nReferer: http:\/\/www.fuzzybunnies.com\/main.html\nI REQUEST A BUNNY\n<\/pre>\n<\/blockquote>\n<\/div>\n
Il server deve rispondere a questa richiesta con una riga nella quale dichiara la versione di protocollo supportata, un codice di stato numerico (utilizzato per indicare condizioni di errore e altre circostanze particolari) e, opzionalmente, un messaggio di stato in formato leggibile dall\u2019uomo. Quindi seguono diversi header auto-esplicativi che terminano con una riga vuota. La risposta prosegue con il contenuto della risorsa richiesta:<\/p>\n
\n
\n
HTTP\/1.1 200 OK Server: Bunny-Server\/O.9.2 Content-Type: text\/plain Connection: close\nBUNNY WISH HAS BEEN GRANTED\n<\/pre>\n<\/blockquote>\n<\/div>\n
Comportamento dell’header Referer<\/h2>\n
Come abbiamo anticipato precedentemente in questo capitolo, le richieste HTTP possono contenere un header Referer che contiene l\u2019URL del documento da cui in qualche modo proviene la navigazione. Esso \u00e8 destinato a favorire la ricerca di errori di programmazione e a promuovere la crescita del Web enfatizzando i riferimenti incrociati tra le pagine web.<\/p>\n
Sfortunatamente, questo header pu\u00f2 rivelare anche alcune informazioni sulle abitudini di navigazione dell\u2019utente a dei malintenzionati, e lasciar scappare informazioni sensibili codificate nei parametri della stringa di query della pagina di provenienza. A causa di queste preoccupazioni e della mancanza di consigli validi su come mitigarne gli effetti, questo header viene spesso abusato per scopi di sicurezza, ma non \u00e8 adatto a questo compito. II principale problema \u00e8 che non c\u2019\u00e8 modo di distinguere un client che non trasmette questo header a causa delle preferenze di privacy dell\u2019utente, da quello che non lo trasmette per il tipo di navigazione in corso, e da quello che deliberatamente lo modifica cancellando la provenienza da un sito malevolo.<\/p>\n
Normalmente questo header e presente nella maggior parte delle richieste HTTP e preservato anche nei reindirizzamenti HTTP, tranne nelle situazioni seguenti.<\/p>\n