Cos'è, in fondo, l'Hypertext Transfer Protocol (HTTP)?

La creazione del World Wide Web fu perfezionata negli anni tra il 1988 e il 1991 circa.

In origine i meccanismi di HTTP furono progettati per permettere agli scienziati di tutto il mondo di condividere una piattaforma di ricerca e collaborazione. Com'è andata, il World Wide Web ha messo strumenti di pubblicazione, apprendimento e collaborazione alla portata di chiunque abbia una connessione Internet.

• (ul custom) Pagina Wikipedia di Tim Berners-Lee

(hr)

I componenti originali dietro l'invenzione di Tim Berners-Lee sono ancora in uso oggi. Anzi, alcuni web server moderni capiscono ancora la specifica HTTP originale (anche se oggi è considerata obsoleta):

Componenti di base del World Wide Web:

• un web server
• uno user agent
• la visualizzazione testuale
• i media type
• un protocollo che permette il trasferimento di documenti, HTTP

Il W.W.W. di oggi
web server	IIS, Apache, NGiNX
user agent	CuRL, Chrome, Firefox, lettori RSS
dati testuali	UTF-8, ASCII, JSON, HTML, XML, CSS
media type	dati testuali, immagini, video, animazioni
specifiche HTTP	HTTP/1.1 (RFC 9112), HTTP/2 (RFC 9113) e HTTP/3 (RFC 9114), con semantica condivisa nella RFC 9110

Due entità principali hanno il compito di definire l'evoluzione dell'HTTP moderno:

• W3C World Wide Web Consortium Il W3C si occupa della funzionalità dei web server, delle esigenze future delle specifiche, degli user agent (o browser), di HTML, XML, video, immagini e tecnologie di distribuzione dei contenuti. In sostanza, il W3C si occupa degli effetti di HTTP sul livello applicativo.
• IETF Internet Engineering Task Force La IETF si occupa di come HTTP funzionerà a un livello tecnico più basso. HTTP lavora sopra tecnologie sottostanti come IPv4, TCP, UDP, Ethernet e molti altri protocolli di livello inferiore. Tutti i protocolli inferiori lavorano insieme per portare i dati dallo user-agent al web server e di nuovo allo user agent.

Presi dal sito di ciascuno, W3C e IETF si descrivono con le loro parole:

• Il World Wide Web Consortium (W3C) è una comunità internazionale in cui le organizzazioni membro, uno staff a tempo pieno e il pubblico lavorano insieme per sviluppare gli standard del Web. (https://www.w3.org/Consortium/)
• L'obiettivo della IETF è far funzionare meglio Internet. La missione della IETF è far funzionare meglio Internet producendo documenti tecnici rilevanti e di alta qualità che influenzano il modo in cui le persone progettano, usano e gestiscono Internet. (https://www.ietf.org)

Come vengono definiti standard come HTTP? (h2, anchor section01)

Quando un protocollo Internet come HTTP viene adottato o rivisto, gli standard sono definiti in documenti chiamati RFC.

RFC sta per Request For Comments.

Ogni protocollo di comunicazione dati riconosciuto e accettato per l'uso generale su Internet è definito in una serie di documenti RFC. Tecnologie come HTTP, IPv4, TLS, PKI, SNMP, POP3 e persino Ethernet non sono tecnologie di proprietà di Microsoft, Apple o Google.

Gli standard definiti in una RFC sono pensati per essere adottati come mezzo per permettere la comunicazione tra piattaforme di più vendor. Ogni tecnologia (nel suo nucleo) documentata in una RFC può essere implementata, perfezionata per l'uso e persino aggiunta a prodotti da qualsiasi persona o vendor, senza royalty né brevetti.

Una RFC è di solito un documento piuttosto arido, disponibile in testo ASCII, nella tradizione di restare leggibile su qualsiasi piattaforma. Una RFC presuppone inoltre che il lettore abbia dimestichezza con i concetti tecnici.

• (ul custom) Le specifiche HTTP attuali: RFC 9110 HTTP Semantics, RFC 9112 HTTP/1.1, RFC 9113 HTTP/2 e RFC 9114 HTTP/3

(hr)

HTTP è l'acronimo di Hyper Text Transfer Protocol. HTTP è un protocollo di livello applicativo senza stato, progettato per comunicare scambi di informazioni tra sistemi attraverso Internet. In quanto tale, HTTP definisce un insieme di regole che permettono sia il trasferimento sia l'accesso a documenti remoti. HTTP è stato usato anche per trasferire informazioni in altri modi, come SSDP, che usa UDP e indirizzamento multicast (adottato come HTTPU) per i trasferimenti di informazioni.

Cosa NON è HTTP?

HTTP e il World Wide Web non sono Internet. HTTP è un protocollo che fa funzionare una porzione estremamente popolare di Internet nota come il World Wide Web.

HTTP opera sopra i protocolli di comunicazione di rete sottostanti nel modello TCP/IP. TCP/IP è un meccanismo per trasferire dati, informazioni di framing e dati di livello applicativo su Internet. HTTP è uno standard di livello applicativo specializzato nel trasferimento di un certo tipo di dati. HTTP/1.1 e HTTP/2 girano su TCP, mentre HTTP/3 gira su QUIC, costruito su UDP.

TCP/IP è una suite di protocolli di comunicazione dati sviluppata dal Dipartimento della Difesa degli Stati Uniti. TCP/IP viene talvolta chiamato «il modello di rete del DoD».

Nei suoi primi anni Internet e TCP/IP furono donati dai laboratori DARPA al mondo accademico. Dopo essere stata perfezionata per l'uso accademico, Internet fu adottata da consumatori e aziende fino a diventare l'Internet che conosciamo oggi. Fu durante il periodo di transizione dal mondo accademico ai primi usi pubblici che HTTP e il World Wide Web furono introdotti.

TCP/IP	Protocolli per livello
Livello applicativo	HTTP: World Wide Web; FTP: file transfer protocol; POP3 e IMAP: posta in arrivo; SMTP: posta in uscita; HTML: markup per la visualizzazione delle pagine web; JPEG: formato grafico per la visualizzazione delle immagini
Livello di trasporto	TCP: comunicazione orientata alla connessione tra host; UDP: comunicazione senza connessione tra host (QUIC, usato da HTTP/3, gira sopra di esso)
Livello Internet	IPv4: indirizzamento per le reti remote; IPv6: indirizzamento per le reti remote; BGP: instradamento del traffico tra provider Internet; OSPF: instradamento del traffico sulle reti interne; ICMP: struttura per trasmettere diagnostica
Livello di collegamento	Ethernet livello fisico e segnalazione per il trasferimento dati di basso livello; Token Ring concorrente di Ethernet ormai raramente visto; 802.11 specifiche per le comunicazioni wireless; Bluetooth specifica per collegare dispositivi senza fili; Frame Relay specifiche fisiche e dati per le reti geografiche (WAN)

(The right-hand cells are ul lists in the English; one list item per ;-separated entry above.)

La tabella qui sopra rappresenta come HTTP si inserisce in Internet e in TCP/IP.

(hr)

Le specifiche di HTTP (h2, anchor section02)

Principalmente, HTTP serve a comunicare trasferimenti di documenti tra uno user agent e un web server.

Gli scambi HTTP consistono di solito nello user agent che richiede una serie di documenti a un web server. Quando una richiesta HTTP viene ricevuta dal web server, questo la analizza. Infine, il web server restituisce un documento e un codice di stato, oppure può negare la richiesta restituendo un codice di stato che spiega perché è stata negata.

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/jKNyIni.jpg (unchanged, 454x379); alt: Richiesta HTTP semplice; caption: Richiesta HTTP riuscita

• (ul custom) Per i dettagli sul perché un web server possa negare una richiesta del client, fate riferimento alla sezione sui codici di stato HTTP 400

User-Agent è il termine ricercato per un'applicazione che richiede risorse HTTP a un web server. Il più delle volte gli user agent sono noti come browser. Ma anche i lettori RSS, i bot di web scraping, gli spider e le librerie HTTP come CURL sono user agent.

Web server è un demone che gira comunemente sulla porta 80 (HTTP) e sulla porta 443 (HTTPS), dedicato specificamente a recuperare documenti da una porzione designata del file system del server per consegnarli a uno user agent.

I tre web server ad alto carico più comuni su Internet oggi sono Apache, Nginx (si pronuncia Engine-X) e IIS (di Microsoft).

Guardiamo una semplice richiesta HTTP con un'applicazione user-agent chiamata Fiddler.

Fiddler è un proxy di debug HTTP per API e applicazioni web; gli strumenti per sviluppatori integrati in ogni browser moderno mostrano gran parte delle stesse informazioni.

• (ul custom) Link a Fiddler di Telerik

(hr)

I metodi di richiesta HTTP (h2, anchor section03)

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/Wu6yTXV.jpg (unchanged, 852x597); alt: Semplice richiesta HTTP GET; caption: Il grafico mostra gli scambi di richiesta e risposta HTTP con il contenuto, proprio come quando «https://www.google.com» viene digitato in un comune browser

Proprio come mostrato nel primo diagramma di uno scambio richiesta/risposta HTTP, lo user-agent richiede un documento e il web server soddisfa una richiesta HTTP valida.

Come mostrato nella parte superiore della finestra di Fiddler, Fiddler, lo user-agent, ha inviato tre righe di dati:

1. GET specifica file e percorso
2. User-Agent identifica il software client
3. HOST specifica l'host dove si trova il contenuto

Il metodo di richiesta in questa richiesta è GET. Conosceremo altri metodi di richiesta HTTP in questa introduzione.

La stringa User-Agent: una stringa User-Agent è il modo in cui il software client si identifica presso il web server. API e siti web spesso concedono o negano privilegi di accesso e impostazioni di visualizzazione in base alla stringa User-Agent del client.

I crawler ben educati si identificano onestamente nella loro stringa User-Agent e seguono le regole che un sito pubblica nel suo file robots.txt.

Alcune stringhe User-Agent di esempio (i numeri di versione cambiano a ogni release):
Chrome su Windows 7	Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Internet Explorer 11	Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Googlebot	Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
PlayStation 4	Mozilla/5.0 (PlayStation 4 4.71) AppleWebKit/601.2 (KHTML, like Gecko)

(Each right-hand cell is a pre > code block in the English; strings verbatim.)

Host

L'header Host specifica il server (e il dominio) che possiede il documento richiesto. Da HTTP/1.1 l'header Host è obbligatorio (HTTP/2 e HTTP/3 portano la stessa informazione nel campo :authority). È obbligatorio perché molti siti condividono un solo server e un solo indirizzo IP, una configurazione chiamata virtual hosting basato sul nome, e il server ha bisogno dell'header Host per sapere a quale sito è destinata una richiesta.

Un host con indirizzo IP 192.168.1.98 può avere un nome DNS esterno web3.biga-hosting.com. Questo server chiamato web3.biga-hosting.com può ospitare centinaia di domini. A sua volta, l'header Host di HTTP fa sapere al server a quale dominio ospitato è destinata una richiesta. Più domini virtuali possono avere lo stesso indirizzo IPv4 192.168.1.98 (il DNS inverso di solito punta a web3.biga-hosting.com).

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/R1cibUs.jpg (unchanged, 500x441); alt: Richiesta GET a un server che ospita più domini; caption: Richiesta GET a un web server che ospita più domini

(hr)

Anatomia di HTTP

Questa sezione scende un po' più in profondità nel funzionamento interno del protocollo HTTP. Gli argomenti trattati per dare una panoramica di HTTP includono:

• Concetti di URI e URL
• I verbi HTTP: - GET - POST - PUT - DELETE - HEAD - TRACE - OPTIONS
• I media type
• Caratteristiche comuni di HTTP: - senza stato - nessuna cifratura integrata - autenticazione HTTP

(hr)

Concetti di URI e URL (h2, anchor section04)

Di tutti i concetti che riguardano HTTP, decifrare i termini URI e URL è semplice eppure ancora fonte di confusione sia tra gli studenti sia tra alcuni sviluppatori. A confondere ulteriormente un concetto semplice, il termine URI è stato affinato e documentato in standard che permettono al termine URL di essere sinonimo di URI.

URI è l'acronimo di Uniform Resource Identifier. URL è l'acronimo di Uniform Resource Locator.

Definiamo ciascuno nei termini più semplici possibili, con un'analogia. Nel nostro scenario diciamo che URI è analogo al termine autoveicolo. Un URL è un tipo specifico di URI. Diciamo quindi che URL è analogo a un'«automobile», ma non a un camion o a un furgone.

Si consiglia tuttavia di usare sempre il termine URI se la differenza ha una qualche importanza.

Per capire meglio il concetto di URI, diciamo ora di voler trovare un libro. Ma non sappiamo dove si trova. Non potremmo usare un URL, perché un URL è specifico di un host. Potremmo però usare un URN:

urn:isbn:0451450523

Quando si usa un URN come quello mostrato, un'applicazione web sottostante ha il compito di gestire la logica che individua il documento richiesto.

Diciamo, nella nostra analogia, che un URN è un furgone, un altro tipo specifico di autoveicolo. Un URI definisce sia URN che URL. Un URN identifica una risorsa specifica, nel nostro esempio un libro. Mentre un URL identifica la posizione e gli altri mezzi per accedere a una risorsa.

Anatomia di un URL

Un URL, altrimenti noto come Uniform Resource Locator, è l'URI più comune in uso sul World Wide Web. È ciò che digitiamo nella barra degli indirizzi di un browser per ottenere https://www.google.com.

Diamo un'occhiata a un URL più complesso e scomponiamone ogni parte:

http://admin:password@web5.acmeco.com:8080/admin-docs/2017/ins/infrastructure.xlsx

È sintatticamente valido, ma mostra qualcosa che non dovreste mai fare.

La forma utente:password in un URL è deprecata (RFC 3986), e i browser moderni la rimuovono o la bloccano. Le credenziali in un URL finiscono nei log del server, nella cronologia del browser e negli header Referer. Non mettete mai credenziali, in hash o meno, in un URL.

Credenziali nell'URL
schema	http://
credenziali	admin:password
risorsa/host	web5.acmeco.com
porta	8080
percorso	/admin-docs/2017/ins/
documento	infrastructure.xlsx

Anche http://www.acmeco.com/ è un URL valido.

La barra finale dice al web server che vogliamo il documento predefinito nella webroot. Tradizionalmente questo documento si chiama index.html, ma l'amministratore del server può cambiarlo in qualsiasi cosa.

Un altro URL valido può essere: mailto:user@example.com. Invece di richiedere un documento, questo URL apre il client di posta predefinito, pronto a scrivere a quell'indirizzo.

Alcuni schemi di protocollo validi per gli URL sono: https://, http://, ftp://, file://, mailto:, tel:, e probabilmente qualche altro. http e https sono comunque i protocolli più usati sul World Wide Web.

Le query string

Esiste un altro modo comune di specificare un URL, usato di frequente sul World Wide Web. Si chiama query string. Una query string si usa di solito insieme a un'applicazione web di back-end o a uno script CGI.

Un esempio, aggiunto alla nostra precedente richiesta GET, che accede direttamente a Google Search:

https://www.google.com/search?q=euro+vps

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/vU3oN4i.jpg (unchanged, 697x448); alt: Query string che accede direttamente alla ricerca di Google; caption: Uno sguardo dietro le quinte alla nostra richiesta GET con una query string valida aggiunta

Le query string si usano di solito per passare parametri a uno script di back-end. La query string viene codificata dal browser, poi consegnata a un web server, decodificata dal web server o dall'applicazione, e infine elaborata dall'applicazione web.

È noto che le query string sono state sfruttate passando parametri malevoli nel tentativo di manipolare la funzionalità di un'applicazione web.

https://www.acmeco.com/auth/auth.php?user=acmeuser&password=EXAMPLE

Qui sopra c'è un esempio di cosa non fare mai. Le credenziali, in hash o meno, non devono mai viaggiare in un URL: finiscono nei log HTTP, nella cronologia del browser e negli header Referer. Inviatele nel corpo di una POST su HTTPS, oppure in un header Authorization.

(hr)

I verbi HTTP (h2, anchor section05)

Ora che abbiamo un'idea chiara di cos'è un URL e di come si usano le query string, introduciamo i verbi usati nelle richieste HTTP. I verbi HTTP più usati sono:

• POST e GET
• PUT
• DELETE
• HEAD
• TRACE
• OPTIONS
• CONNECT

1. POST e GET

GET è il metodo predefinito quando si digita un sito nella barra degli indirizzi del browser o si clicca un collegamento ipertestuale. Quando viene richiesta una pagina web, il browser può in realtà fare diverse richieste GET o POST, scaricando tutte le risorse che compongono la pagina: immagini, fogli di stile, script lato client, risorse tipografiche e altro:

Collegamento ipertestuale (hyperlink) è il nome tecnico del collegamento a pagine web secondarie. Quando l'utente clicca su un link (o hyperlink), il browser invia una richiesta GET per la pagina collegata

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/8GeEaCU.jpg (unchanged, 872x621); alt: Richiesta singola; caption: Digitare www.yahoo.com per richiedere la pagina predefinita di yahoo.com avvia molte richieste HTTP GET e POST.

Le richieste POST

I due metodi di richiesta più usati sono GET e POST. Abbiamo già scomposto una richiesta GET. Esaminiamo quindi una richiesta POST.

E se volessimo caricare un file da 1GB tramite uno script PHP o asp? Naturalmente un URL non può contenere una stringa binaria da 1GB. In questo scenario useremmo il metodo POST.

POST è simile a GET in quanto può passare parametri come una query string. Ma i dati POST non vengono aggiunti a un URL come con la query string.

I dati POST viaggiano invece nel corpo della richiesta HTTP, dopo gli header. POST si usa più comunemente con i dati dei form HTML.

Il metodo POST si usa comunemente quando servono queste funzionalità:

• caricamento di file
• tenere i dati sensibili fuori dall'URL
• invio di stringhe di dati più lunghe
• uso di schemi di codifica diversi
• non può essere messo in cache (se è un problema di sicurezza)

Confrontiamo con alcuni vantaggi del metodo GET con una query string aggiunta all'URL

• può essere salvato come segnalibro
• può essere messo in cache
• i risultati di una query possono essere condivisi con un link

2. PUT

Il metodo PUT si usa più spesso nelle API web RESTful. PUT crea o sostituisce la risorsa all'URI indicato nella richiesta, mentre POST chiede al server di elaborare i dati, spesso creando una nuova risorsa a un URI scelto dal server.

PUT è di solito disabilitato per impostazione predefinita nelle installazioni dei web server.

Lasciare PUT abilitato potrebbe permettere agli attaccanti di caricare ed eseguire file sul web server.

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/LC10OIJ.jpg (unchanged, 858x618); alt: Richiesta PUT negata; caption: Una richiesta PUT a http://google.com viene negata con un codice di errore HTTP 405.

3. DELETE

Come PUT, il metodo DELETE si usa più comunemente nelle API RESTful. Usare DELETE dovrebbe eseguire un'azione di eliminazione su un oggetto URI:

DELETE http://acmeco.com/customers/{customer-id}

DELETE è disabilitato per impostazione predefinita nella maggior parte delle installazioni dei web server. Abilitare DELETE quando non serve potrebbe essere un rischio di sicurezza, permettendo agli attaccanti di eliminare documenti da un sito.

4. HEAD

Il metodo HEAD è simile a GET ma restituisce solo gli header, senza contenuto. HEAD si usa comunemente per verificare se un documento in cache è stato aggiornato. Se il documento è più recente della versione in cache, l'intero documento viene scaricato e messo in cache.

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/ry5bv8c.jpg (unchanged, 865x633); alt: Richiesta HEAD in Fiddler; caption: La stessa richiesta a Google usando HEAD invece di GET

5. TRACE

TRACE è un metodo diagnostico e di solito è disabilitato sulla maggior parte dei web server. Molti ricercatori di sicurezza hanno scoperto potenziali vulnerabilità nei metodi TRACE. Nella maggior parte dei casi, con TRACE i rischi superano di gran lunga l'utilità.

6. OPTIONS

OPTIONS chiede al server quali metodi e funzionalità supporta per una risorsa. Non disabilitatelo: i browser inviano una richiesta OPTIONS come preflight CORS prima di molte chiamate API cross-origin, e bloccarla rompe quelle applicazioni. Consentite invece solo i metodi di cui la vostra applicazione ha davvero bisogno, e disabilitate TRACE.

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/4DaBFXV.jpg (unchanged, 856x597); alt: Richiesta HEAD in Fiddler; caption: Un web server che consente ancora TRACE, che andrebbe disabilitato

7. CONNECT

CONNECT è usato dai proxy e non dovrebbe essere abilitato su un web server ordinario. Quando è abilitato e mal configurato, CONNECT può permettere connessioni che inoltrano richieste ad altri server. Queste connessioni proxy possono essere usate per attacchi o per scaricare file illegali.

Per impostazione predefinita, la maggior parte dei software web server ha CONNECT disabilitato.

L'uso legittimo di CONNECT è il tunneling di HTTPS e di altre connessioni TLS attraverso un forward proxy.

(hr)

I media type (h2, anchor section06)

Un media type definisce i file in base a natura e formato per la visualizzazione o l'elaborazione. L'header Content-Type si usa in una risposta HTTP per permettere al browser di visualizzare il testo della risposta, caricare un plugin per un tipo di file supportato, o semplicemente scaricare un file da vedere in un'altra applicazione.

In origine il media type fu implementato per gli allegati e-mail e battezzato MIME type. MIME sta per Multipurpose Internet Mail Extension.

Alcuni media type possono avere il prefisso «x-» o «vnd». La «x» significa che un media type non è ufficialmente elencato dalla IANA (Internet Assigned Numbers Authority). La parte «vnd» significa che un media type è specifico di un vendor (per esempio application/vnd.ms-excel).

Vedere i media type in Firefox

• digitate «about:config» nella barra degli indirizzi.
• nella casella di ricerca della configurazione digitate «mime»

• image (aligncenter): src /blog/wp-content/uploads/2017/12/rNTzwB7-e1513109426632.jpg (unchanged, 700x352); alt: Configurazione dei MIME type di Firefox in Linux

Su una piattaforma Linux vediamo che Firefox usa il file /etc/mime.types

Diamo un'occhiata a una parte del nostro file /etc/mime.types:

$ head -n 40 /etc/mime.types | grep -v "^#"
application/activemessage
application/andrew-inset			ez
application/annodex				anx
application/applefile
application/atom+xml				atom
application/atomcat+xml				atomcat
application/atomicmail
application/atomserv+xml			atomsrv
application/batch-SMTP
application/bbolin				lin
application/beep+xml
application/cals-1840
application/commonground
application/cu-seeme				cu
application/cybercash
$ wc -l /etc/mime.types
835 /etc/mime.types

Come mostrato, questo sistema riconosce oltre 800 MIME type specifici. In sostanza questo dice a Firefox quali estensioni sono associate a certi tipi di file.

NOTA: i media type sono diversi dalle «applicazioni predefinite» del sistema operativo. Pur simili nel concetto, i MIME type sono usati dalle applicazioni che parlano con Internet, mentre il sistema operativo tiene un registro separato dei tipi di file e dei visualizzatori associati.

Quando viene fatta una richiesta GET per un foglio Excel, l'header Content-Type restituisce application/vnd.ms-excel. Il browser sa così che il file non va mostrato come testo nella finestra. Il file viene invece caricato in un plugin di visualizzazione o scaricato per essere aperto in seguito in un'altra applicazione.

Anche un web server Unix o Linux usa /etc/mime.types per l'header Content-Type. Inoltre va impostato un handler per un linguaggio di scripting come php, in modo che i file PHP vengano eseguiti anziché inviati al browser come testo. Su RHEL, /etc/httpd/conf.d/php.conf di Apache li passa a PHP-FPM:

<FilesMatch \.(php|phar)$>
    SetHandler "proxy:unix:/run/php-fpm/www.sock|fcgi://localhost"
</FilesMatch>

Sopra: i file che terminano in .php (e .phar) vengono passati al servizio PHP-FPM attraverso il suo socket, invece di essere serviti come file semplici.

Se vi è mai capitato di cliccare un link e vedere il browser mostrare un'immagine o altri dati binari come ASCII, o di ricevere la richiesta di scaricare una pagina web, significa che i MIME type del browser o del server erano mal configurati.

Per risolvere il problema, guardate l'header Content-Type negli strumenti per sviluppatori del browser (scheda Network):

• image (aligncenter): src /blog/wp-content/uploads/2017/12/FTSurmm-e1513109444640.jpg (unchanged, 700x462); alt: Header Content-Type in HTTPFox

Vediamo che nella risposta del server era specificato il content-type corretto. Se il browser chiedesse di salvare l'immagine richiesta dalla richiesta GET, sapremmo che il MIME type del browser per image/jpeg va riconfigurato.

Configurazioni improprie dello scripting lato server o dei MIME type binari possono portare a problemi di sicurezza sul server o sul client.

La IANA (Internet Assigned Numbers Authority) ha il compito di mantenere una mappatura ufficiale dei media type attraverso lo stato di RFC.

RFC IANA sui media type

(hr)

Caratteristiche di HTTP (h2, class anchor-holder)

In questa sezione parliamo delle caratteristiche del protocollo HTTP. I concetti più importanti da conoscere quando si lavora con HTTP sono:

• HTTP è senza stato
• HTTP non offre cifratura integrata

Cos'è un protocollo senza stato?

HTTP è senza stato per progetto: ogni richiesta porta con sé tutto ciò che serve al server per rispondere. HTTP non è però senza connessione. HTTP/1.1 e HTTP/2 tengono aperte le connessioni TCP e le riusano per molte richieste, e HTTP/3 fa lo stesso su QUIC.

Senza stato significa semplicemente che le transazioni HTTP vengono richieste da uno user-agent e poi ricevono risposta dal web server. Se un client non mette in cache le risorse richieste, deve emettere di nuovo lo stesso metodo per ottenerle ancora. Un web server HTTP non ha una tabella di stato in cui cercare le comunicazioni precedenti con uno user-agent.

I cookie HTTP: i cookie possono aiutare un web server a fare riferimento a interazioni HTTP passate con uno user-agent. Il protocollo in sé resta senza stato: ogni richiesta sta in piedi da sola, anche quando viaggia su una connessione riusata.

La maggior parte dei linguaggi di back-end, come il framework Django di Python, PHP e ASP .Net, offre librerie per mantenere lo stato dell'applicazione con framework di sessione integrati. Questo approccio aggiunge statefulness a un'applicazione web, ma è astratto a un livello più alto di HTTP.

HTTP non fornisce cifratura

HTTP di per sé non fornisce meccanismi di cifratura integrati. La cifratura è lasciata ad altri protocolli che definiscono HTTPS. HTTPS usa Transport Layer Security, o TLS, il successore di SSL.

TLS funziona con molti protocolli, non solo con HTTP. HTTPS è progettato per trasportare i dati di contenuto e gli header HTTP su connessioni TLS protette. SSL fu sviluppato in origine negli anni Novanta da Netscape. La IETF ne ha poi standardizzato il successore come TLS. Tutte le versioni di SSL sono ormai obsolete; TLS 1.2 e TLS 1.3 sono quelle attuali.

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/qhDltKK.jpg (unchanged, 453x417); alt: Scambio di chiavi TLS; caption: Scambio di chiavi TLS

Il lettore attento potrebbe chiedersi: «Quindi HTTPS ha uno stato? Giusto? Ogni sessione ha una chiave? Giusto?». Le chiavi vengono messe in cache dal client, sì. Ma TLS funziona comunque a un livello più basso del nucleo HTTP di HTTPS. Le interazioni con il web server usano ancora gli stessi metodi HTTP: GET, POST, PUT e DELETE.

(hr)

L'autenticazione HTTP (h2, anchor section07)

L'autenticazione, a differenza della cifratura, è integrata in HTTP. HTTP supporta più tipi di autenticazione, tra cui:

1. Basic
2. Bearer
3. Digest
4. HOBA
5. Mutual
6. Negotiate
7. OAuth
8. SCRAM-SHA1
9. SCRAM-SHA256
10. vapid

Basic Authentication

Il metodo di autenticazione HTTP di gran lunga più comune è la Basic Authentication. La Basic Authentication è comune perché è semplice da implementare, non perché sia sicura. Altri schemi di autenticazione sono più sicuri, e la Basic Authentication va usata solo ed esclusivamente su HTTPS.

Il problema di sicurezza più grande della Basic Authentication è che le credenziali vengono inviate in chiaro. Le credenziali sono codificate in Base64, ma codificare non è cifrare: nel migliore dei casi sono offuscate. Le credenziali possono essere compromesse facilmente quando non si usa TLS o quando il traffico web TLS cade vittima di un attacco man-in-the-middle.

Limiti della Basic Authentication:

• codifica le credenziali solo in BASE 64
• le credenziali vengono messe in cache nel browser, aprendo un altro vettore di attacco
• le credenziali possono essere memorizzate in modo permanente nel browser
• proxy server malevoli possono potenzialmente registrare le credenziali
• le credenziali sono nell'header HTTP

La BASIC Authentication ha ancora uno scopo. Ma è importante riconoscere i limiti di quello scopo. La Basic Authentication va bene solo per il controllo degli accessi. Il controllo degli accessi serve semplicemente a regolare l'accesso alle risorse. La Basic Authentication non va bene per proteggere i dati. Soprattutto le informazioni sensibili che, se esposte, potrebbero tradursi in una perdita di fatturato o di privacy.

Quando implementate uno schema di autenticazione HTTP, pensate alla Basic Authentication come a un codice di accesso che permette l'ingresso autorizzato in un edificio o in un ufficio solo quando il personale di sicurezza è presente. Dopo l'orario di lavoro, le stesse porte vengono chiuse con un meccanismo più sicuro per proteggere l'edificio.

• il controllo degli accessi è un accesso comodo per il personale autorizzato
• la sicurezza mantiene la proprietà al sicuro dagli attaccanti

Qui sotto un'illustrazione di una richiesta/risposta con Basic Authentication:

• image (aligncenter): src /blog/wp-content/uploads/2017/12/fvNIZLj-e1513109471712.jpg (unchanged, 700x393); alt: Basic Authentication 1
• image (aligncenter): src /blog/wp-content/uploads/2017/12/Svu1sFi-e1513109482792.jpg (unchanged, 700x394); alt: Basic Authentication 2

1. Lo user-agent fa una richiesta per un documento
2. Il web server risponde con il codice HTTP 401: Authorization Required
3. Lo user-agent ripete la richiesta con le credenziali
4. Il web server consente o nega l'accesso in base alla validità delle credenziali

Come dimostrazione dei limiti della Basic Authentication, provate a ricavare le credenziali dalla stringa codificata in BASE64 mostrata.

Autenticazione basata su token Bearer

L'autenticazione basata su token Bearer è popolare tra i fornitori di framework di autenticazione. La Bearer Authentication può anche essere distribuita come soluzione autonoma, per singola istanza.

La Bearer Authentication si basa su token ed è usata sia nei framework OAuth che OpenID. Tipicamente OAuth serve per l'autorizzazione, mentre OpenID per l'autenticazione. Esistono però diverse zone grigie che sfumano i confini tra autenticazione e autorizzazione in ciascun framework.

• OpenID fornisce autenticazione federata, cioè servizi di accesso
• OAuth fornisce autorizzazione delegata

• figure (aligncenter): src /blog/wp-content/uploads/2017/12/tKHiVm4-1024x571.jpg (unchanged, 1024x571); alt: OAuth 2.0 con GitHub; caption: Terze parti possono accedere alle risorse di GitHub con OAuth

GitHub fornisce una guida OAuth per gli sviluppatori di applicazioni di terze parti che vogliono accedere alle risorse di GitHub per conto di un utente finale. Guida GitHub alle OAuth App

I grandi identity provider come Google offrono l'accesso tramite OpenID Connect, l'attuale standard OpenID, costruito su OAuth 2.0.

Accesso con OpenID Connect tramite un account Google:

• image (aligncenter): src /blog/wp-content/uploads/2017/12/BMtbtwA.jpg (unchanged, 600x595); alt: Google come provider di autenticazione OpenID

Digest Authentication

La Digest Authentication è più sicura della Basic Authentication. Tuttavia la Digest Authentication è ancora inadeguata a proteggere materiale sensibile su Internet. La Digest Authentication non cifra le credenziali, le sottopone a hash, e se quegli hash vengono catturati un attaccante può lanciare un attacco offline a forza bruta o a dizionario.

Sia lo schema Digest che quello Basic sono considerati deboli nel quadro generale della sicurezza dei dati. Ciascuno ha difetti e ciascuno è stato attaccato con successo. Quando serve più di un semplice controllo degli accessi o autorizzazione, va adottato uno schema di autenticazione più sicuro.

Altri schemi di autenticazione basati su HTTP

NTLM, nota come autenticazione NT Lan Manager, è una tecnologia Microsoft con plugin per molti prodotti, sistemi operativi e servizi di terze parti.

Nei domini Windows la scelta preferita è Negotiate, che usa Kerberos e ripiega su NTLM solo quando deve; Microsoft sta dismettendo NTLM. Con Kerberos, gli utenti di dominio che hanno già effettuato l'accesso possono accedere alle risorse autorizzate senza reinserire le credenziali.

I maggiori svantaggi dell'autenticazione basata su NTLM sono:

• può essere macchinosa da implementare su piattaforme diverse da Windows
• può perdere molte funzionalità di sicurezza se distribuita fuori da un dominio Windows
• NTLM è sicura solo quanto lo è la rete aziendale
• le versioni più vecchie di NTLM sono considerate insicure

SCRAM-SHA1 e SCRAM-SHA256

SCRAM è l'acronimo di Salted Challenge Response Authentication Mechanism

Quando occorre autenticare dipendenti interni, l'autenticazione SCRAM abbinata a OpenLDAP può essere una buona soluzione per ambienti con vendor eterogenei.

SCRAM può essere più sofisticata da distribuire di NTLM per un dominio Windows. Ma SCRAM può essere un'ottima scelta su una rete con client Linux, MacOS Server, Windows e Unix, e persino su Internet.