11
ILIL PROTOCOLLO PROTOCOLLO
HTTPHTTP
PuppoPuppo MarcoMarco
22
IntroduzioneIntroduzione
• HTTP è l’acronimo di Hypertext Transfert Protocol
• Stateless protocol
• 3 versioni:
- HTTP /0.9 (1990)
- HTTP /1.0 (1996) RFC1945
- HTTP /1.1 (1999) RFC2616
33
IntroduzioneIntroduzione
• TCP/IP
• Messaggi MIME (Multipurpose Internet Mail Extensions)
• URL;URI;URN
CLIENT SERVERINTERNET
UTENTE
44
GlossarioGlossario
• Client un’applicazione che stabilisce una connessione HTTP con lo scopo di inviare richieste
• Server un’applicazione che accetta connessioni HTTP e genera risposte
• User agent Quel particolare client che inizia una richiesta HTTP (un browser)
55
GlossarioGlossario
• Risorsa qualsiasi tipo di dato (pagina web;immagini;…)
• Origin server il server che possiede fisicamente la risorsa richiesta (è l’ultimo della catena)
• Proxy applicazione intermediaria che agisce sia da client che da server.
66
GlossarioGlossario
• Gateway applicazione che agisce da intermediario per qualche altro server. A differenza del proxy si comporta come se fosse l’origin server
• MIME (Multipurpose Internet Mail Extensions) protocollo che permette alle e-mail di contenere vari formati di comunicazione (testo;immagini;…)
77
ComunicazioneComunicazione
4 fasi
• Connessione il client crea una connessione TCP/IP con il server usando il dominio (o l’IP) ed il numero della porta. Di default porta 80
• Richiesta documento il client invia la richiesta di un documento mediante una riga ASCII terminata da CR-LF
88
ComunicazioneComunicazione
• Risposta inviata dal server è in forma HTML contenente il documento richiesto
• Disconnessione il server inviata la risorsa si disconnette. Anche il client può disconnettersi senza però creare condizioni d’errore al server
99
Proxy di cacheProxy di cache
1010
Proxy di cacheProxy di cache
1111
Connessione HTTPConnessione HTTP
1212
La richiestaLa richiesta
La richiesta è un messaggio MIME.
La richiesta semplice (HTTP 0.9) è:
GET URI CrLf
La richiesta completa (HTTP 1.0 e succ) è:
Method URI Version CrLf
[Header]*
CrLf
[Body]
1313
La richiestaLa richiesta
• La richiesta semplice è ancora obbligatoria
• La presenza di Version consente al server di capire se può creare la risposta o se deve aspettare altri dati
1414
La richiestaLa richiesta
Method URI Version CrLf[Header]*CrLf[Body]Dove:
• Method rappresenta la richiesta del client al server
• URI è l’identificativo della risorsa locale• Version è HTTP/1.0 o 1.1• Header -> linee RFC822• Body ->messaggio MIME
1515
EsempioEsempio
Get 7beta.html HTTP/1.1Referer: http://www.alpha.com/alpha.htmlConnectio: Keep-AliveUser-Agent:Mozilla/4.16 (Macinthosh;1;PPC)Host: www.alpha.com :80Accept: image/gif, image/jpeg, */*Accept-Encoding: gzipAccept-Language: enAccept-Charset: iso-8859-1,*,utf-8
1616
MetodiMetodi
Un metodo HTTP può essere:• Sicuro: non genera cambiamenti allo stato
interno del server• Idempotente: l’effetto sul server di più richieste
identiche è lo stesso di quello di una sola richiesta.
Alcuni metodi:• GET• HEAD• POST• PUT
1717
GetGet
Il più importante (ed unico in v. 0.9) metodo di HTTP è GET, che richiede una risorsa ad un server.
Questo è il metodo più frequente, ed è quello che viene attivato facendo click su un link ipertestuale di un documento HTML, o specificando un URL nell’apposito campo di un browser.
GET è sicuro ed idempotente.
1818
HeadHeadIl metodo HEAD è simile al metodo GET, ma il serverdeve rispondere soltanto con gli header relativi, senzail corpo.
HEAD è sicuro ed idempotente, e viene usato perverificare:• la validità di un URI: la risorsa esiste e non è di lunghezza zero,• l’accessibilità di un URI: la risorsa è accessibile presso il
server, e non sono richieste procedure di autenticazione del documento.• la coerenza di cache di un URI: la risorsa non è stata
modificata nel frattempo, non ha cambiato lunghezza, valore hash o data di modifica.
1919
PostPostIl metodo POST serve per trasmettere delle informazioni dal
client al server, ma senza la creazione di una nuova risorsa.
POST non è sicuro né idempotente, e viene usato per esempio per passare i dati di una form HTML ad un’applicazione CGI sul server.
Il server può rispondere positivamente in tre modi:• 200 Ok: dati ricevuti e sottomessi alla risorsa specificata.
E’ stata data risposta• 201 Created: dati ricevuti, la risorsa non esisteva ed è
stata creata• 204 No content: dati ricevuti e sottomossi alla risorsa
specificata. Non è stata data risposta.
2020
PutPutIl metodo PUT serve per trasmettere delle
informazioni dal client al server, creando o sostituendo la risorsa specificata.
In generale, l’argomento del metodo PUT è la risorsa che ci si aspetta di ottenere facendo un GET in seguito con lo stesso nome. L’argomento del metodo POST, invece, è una risorsa esistente a cui si aggiunge (es. come input) informazione.
PUT è idempotente ma non sicuro, e comunque non offre nessuna garanzia di controllo degli accessi o locking.
2121
Gli HeaderGli Header
Gli header sono righe RFC822 che specificano la caratteristiche:
• Generali della trasmissione
• Dell’entità trasmessa
• Della richiesta effettuata
• Della risposta generata
2222
Header generaliHeader generali
Possono essere applicati alla richiesta e alla risposta ma non necessariamente al risorsa trasmessa
• Date: data ed ora della trasmissione• MIME-Version: la versione MIME usata per la
trasmissione• Transfer-Encoding: il tipo di formato di codifica usato
per la trasmissione• Cache-Control: il tipo di meccanismo di caching
richiesto o suggerito per la risorsa• Connection: il tipo di connessione da usare (tenere
attiva, chiudere dopo la risposta, ecc.• Via: usato da proxy e gateway.
2323
Header dell’entitàHeader dell’entità
Danno informazioni sul body o sulla risorsa specificata
• Content-Type: il tipo MIME dell’entità acclusa. Questo header è obbligatorio in ogni messaggio che abbia un body.
• Content-Length: la lunghezza in byte del body. Obbligatorio, soprattutto se la connessione è persistente.
2424
Header dell’entitàHeader dell’entità
• Content-Base, Content-Encoding, Content-Language, Content-Location, Content-MD5, Content-Range: l’URL di base, la codifica, il linguaggio, l’URL della risorsa specifica. MD5 e il range richiesto della risorsa.
• Expires: una data dopo la quale la risorsa è considerata non più valida (cancellata dalla cache e ricaricata)
• Last-Modified: data e ora dell’ultima modifica. Possibilmente obbligatorio, serve a determinare la validità della copia posseduta
2525
Header della richiestaHeader della richiestaPosti dal client per specificare informazioni sulla richiestaUser-Agent:• una stringa che descrive il client che origina la richiesta;
tipo, versione e sistema operativo del client, tipicamente.Referer:• l’URL della pagina mostrata all’utente mentre richiede il
nuovo URL.• Se l’URL è richiesto con altri metodi che non
l’attraversamento di un link es. digitando l'URL o selezionandolo dai bookmark, Referer deve essere assente.
• Referer viene usato per controllo sui percorsi degli utenti, utili nel caso di user profiling (che gusti ha il mio utente? Lo capisco dalla pagina da cui proviene) o pubblicità (il mio utente ha cliccato su un banner. A chi devo pagare i diritti?)
2626
Header della richiesta
Host: obbligatorio in HTTP 1.1. Contiene dominio e porta a cui viene fatta la connessione. L’URI manda l’indicazione del nome o della porta acceduta. Se un server ha più siti Web, l’Host permette al server di distinguere il sito
From: indirizzo e-mail del richiedente. Necessita dell’approvazione dell’utente per l’inserimento di questo header nella richiesta
->
2727
Header della richiestaHeader della richiesta
Range: il range della richiesta. Poco usatoAccept, Accept-Charset, Accept-Encoding, Accept-
Language:• Implementazione della negoziazione del formato, per
quel che riguarda tipo MIME, codice caratteri, codifica MIME, linguaggio umano.
• Il client specifica cosa è in grado di accettare, e il server propone il match migliore.
If-Modified-Since,If-Unmodified-Since: solo se la condizione è vera. A pre-condizione valida, ritorna “non modificato” altrimenti GET normale.
Authorization, Proxy-Authorization: una stringa di autorizzazione per l’accesso alla risorsa richiesta.
2828
Esempio di rispostaEsempio di risposta
Version status-code reason-phrase CrLf[Header]*CrLfBody
GET /index.html HTTP/1.1Host: www.cs.unibo.it:80HTTP/1.1 200 OKDate: Fri, 26 Nov 1999 11:46:53 GMTServer: Apache/1.3.3 (Unix)Last-Modified: Mon, 12 Jul 1999 12:55:37 GMTAccept-Ranges: bytesContent-Length: 3357Content-Type: text/html<HTML> …. </HTML>
2929
Status codeStatus code
Lo status code è un numero di tre cifre, di cui la prima indica la classe della risposta, e le altre due la risposta specifica.
Esistono le seguenti classi:• 1xx: Informational. Una risposta temporanea alla richiesta, durante
il suo svolgimento.• 2xx: Successful. Il server ha ricevuto, capito e accettato la
richiesta.• 3xx: Redirection. Il server ha ricevuto e capito la richiesta, ma
sono necessarie altre azioni da parte del client per portare a termine la richiesta.
• 4xx: Client error. La richiesta del client non può essere soddisfatta per un errore da parte del client (errore sintattico o richiesta non autorizzata).
• 5xx: Server error. La richiesta può anche essere corretta, ma il server non è in grado di soddisfare la richiesta per un problema interno (suo o di applicazioni CGI).
3030
Esempi di status codeEsempi di status code
100 Continue (se il client non ha ancora mandato il body)200 Ok (GET con successo)201 Created (PUT con successo)301 Moved permanently (URL non valida, il server
conosce la nuova posizione400 Bad request (errore sintattico nella richiesta)401 Unauthorized (manca l’autorizzazione)403 Forbidden (richiesta non autorizzabile)404 Not found (URL errato)500 Internal server error (tipicamente un CGI mal fatto)501 Not implemented (metodo non conosciuto dal server)
3131
Header della rispostaHeader della risposta
Posti dal server per dare informazioni sulla risorsa e su se stesso al client
• Server: stringa che descrive il server: tipo;S.O.;versione;ecc.
• WWW-Authenticate:include un codice di partenza (challenge) con cui il meccanismo di autenticazione deve fare match in caso di una risposta 401 (unauthorized). Il client genererà con questo valore un valore di autorizzazione posto nell’header Authorization della prossima richiesta.
• Accept-ranges: specifica che tipo di range può accettare (valori previsti: byte e nome).
3232
Cos’è CGICos’è CGI
La Common Gateway Interface (CGI) è una semplice ‘interfaccia’ per eseguire programmi esterni, software o gateway, sotto un server HTTP, indipendentemente dalla piattaforma.
3333
CGICGI
• Il client, tramite il protocollo HTTP, invia al server la FORM compilata con la richiesta di eseguire un programma CGI con i dati passati come parametri d'ingresso.
• Una volta arrivato al server remoto il contenuto della FORM questo, attraverso l'interfaccia CGI, richiama il programma CGI passandogli i dati inviati dal client.
• Eseguite le operazioni necessarie il programma CGI può interagire con un database contenuto sul disco del server dopodichè rimanda al server dei dati elaborati, sempre facendo uso dell'interfaccia CGI, per rispondere al client, ad esmpio si può comunicare al client se l'operazione è andata a buon fine o meno.
• Il server invia al client i dati elaborati dal programma CGI tramite il protocollo HTTP.
3434
CGICGI
L'interfaccia CGI definisce quindi soltanto il metodo con cui i dati ricevuti da una FORM sono passati dal server al programma CGI e viceversa; si tratta quindi di un problema di I/O. Il programma CGI, che è un programma eseguibile, può essere scritto in un qualsiasi linguaggio purché sia in grado di interpretare i dati che arrivano dal server HTTP.
3535
CGICGI
Uno script CGI viene invocato tramite un GET o un POST ad una URL che faccia riferimento al CGI stesso. C'è però un problema: il server deve sapere che la URL ricevuta dal client punta ad un CGI e non ad un documento HTML, in quanto la pagina HTML è inviata al client per la sua visualizzazione mentre lo script CGI deve essere eseguito da una shell di sistema.
3636
CGICGI
Normalmente un CGI viene usato come action di una FORM. I programmi CGI ed il server comunicano principalmente attraverso quattro modi:
1. Variabili d'ambiente di sistema. 2. Comando di linea (usato per eseguire il
programma CGI in una shell di sistema operativo).
3. Standard input (usato soprattutto con il metodo POST).
4. Standard output.
3737
CGICGI
Il risultato di un CGI viene passato al server tramite lo standard output
Il server provvederà così ad impacchettarlo in un messaggio HTTP ed a rinviarlo al client
In risposta un programma CGI puù produrre:• Un file HTML• Un’ immagine• …
3838
Schemi di AutenticazioneSchemi di Autenticazione
• Semplice
• Challenge Response
• Il client confeziona la Response
• Due tipi:
Basic Access Authentication
Digest Access Authentication
3939
Schemi di AutenticazioneSchemi di Autenticazione
Lo schema prescelto (Basic/Digest) dal server HTTP viene restituito al client HTTP in un messaggio HTTP con status-code = 401 (Unauthorized). Il messaggio restituito deve contenere nell'intestazione il campo WWW-Authenticate.
HTTP/1.1 401 Unauthorized…
WWW-Authenticate: Basic realm=”Internet Security”
…Corpo messaggio di risposta
4040
Basic Authentication SchemeBasic Authentication Scheme
Lo schema prevede che l’utente digiti Username e password come specificato dal Challenge Realm. Questo valore non viene allegato alla nuova HTTP Request del client.Tale valore viene utilizzato dal server solo per ricordare all’utente che il documento è associato ad un dominio contraddistinto dal valore alfanumerico specificato nel Challenge Realm
4141
Basic Authentication SchemeBasic Authentication Scheme
La seconda richiesta del client viena considerata valida sa la coppia Username/Password è valida.
Le credenziali inviate dal client devono essere inserite nell’intestazione del messaggio HTTP Request usando il campo Authorization
Get /URL HTTP/1.1
…
Authorization: Basic QWxhZGR…
4242
Basic Authentication SchemeBasic Authentication Scheme
Credenziali= “Aladin:open sesame” (multiplo di 3)
Codifica ASCII= 01000001 01101100 01100001 …
Gruppi di 6 bit = 010000 010110 110001 100001 …
Codifica Radix-64= Q W x h …
4343
Vulnerabilità del BasicVulnerabilità del Basic
• Trasmissioni in chiaro delle credenziali
• Per risorse poco meno che pubbliche
• Username e Passwod memorizzate in un database sul server HTTP
• Facile sostituzione del server da parte di terzi
4444
Digest Authentication SchemeDigest Authentication Scheme
Risolve i problemi legati al controllo degli accessi degl’utenti.
Prevede una preliminare fase di autenticazione
Come nel Basic viene attivato dal server inviando al client un Challenge dentro il messaggio di HTTP Response con status-code=401
4545
Digest Authentication SchemeDigest Authentication Scheme
WWW-Authenticate è molto più complesso:
HTTP/1.1 401 Unauthorized ...
WWW-Authenticate: Digestrealm="[email protected]",
qop="auth,auth-int",nonce="dcd98b710…“opaque="5ccc069c4…"
... Corpo messaggio di risposta
4646
Digest Authentication SchemeDigest Authentication Scheme
Dove:• La risorsa richiesta è http://www.nowhere.org/dir/index.html. • Il parametro realm ha lo stesso significato del parametro omonimo
presente nello schema Basic. • Il parametro qop stabilisce invece la "quality of protection". I valori
previsti sono specificati nella RFC 2069 (auth, e auth-int). • Il parametro opaque viene prodotto dal server HTTP e deve essere
restituito inalterato dal client HTTP in tutte le richieste successive che prevedono l'accesso alla stessa risorsa (specificata dal proprio URI).
• L'algoritmo di digest previsto, se non diversamente specificato è l'algoritmo MD5.
• Il parametro nonce riporta la vera e propria sfida prodotta dal server HTTP. Il contenuto della sfida è dipendente dalla implementazione del server HTTP. Raccomandazione generale è comunque utilizzare la seguente struttura (codificata radix-64):
4747
Digest Authentication SchemeDigest Authentication SchemeIl client aprirà una finestra di dialogo dove l’utente inserirà Username
e Password utilizzate poi per generare la risposta e richiedere la risorsa.
GET /url HTTP/1.1 ...
Authorization: Digest username="Mufasa",realm="[email protected]",
nonce="dcd98b710…",uri="/dir/index.html",
qop=auth, nc=00000001,
cnonce="0a4f113b",response="6629fae4…",opaque="5ccc069c4…"
...
4848
Digest Authentication SchemeDigest Authentication Scheme
Dove:• La nuova richiesta è rivolta ad acquisire la risorsa contrassegnata
da http://www.nowhere.org/dir/index.html. • Il parametro username è l'esatta replica dell'informazione digitata
dall'utente. • Il parametro realm è l'esatta replica di quanto ricevuto nel
precedente messaggio HTTP Response. • Il parametro nonce è l'esatta replica della sfida ricevuta nel
precedente messaggio HTTP Response. Viene inserita nella richiesta dal client HTTP per consentire una elementare verifica dei dati ricevuti da parte del server HTTP prima di procedere alla validazione delle credenziali utente. In nessun modo il server HTTP deve basarsi sul valore del parametro nonce restituito dal client HTTP per validare le credenziali ricevute.
4949
Digest Authentication SchemeDigest Authentication Scheme
• Il parametro uri indica la risorsa richiesta nella Request Line (prima riga) della HTTP Request inviata dal client HTTP.
• Il parametro qop riporta la "quality of protection" scelta dal client HTTP per completare lo schema di autenticazione.
• Il parametro opache è l'esatta replica di quanto ricevuto nel precedente messaggio HTTP Response.
• Il parametro nc indica il numero progressivo di HTTP Request prodotte utilizzando lo stesso nonce.
• Il parametro cnonce riporta un valore casuale prodotto dal client HTTP al fine di evitare ogni forma di attacco di tipo "chosen plaintext" e/o fornire un rudimentale meccanismo per una mutua autenticazione.
• Il parametro response riporta il digest prodotto dal client HTTP. Se non diversamente specificato l'algoritmo utilizzato per produrre il digest è l'algoritmo MD5.
5050
Vulnerabilità del DigestVulnerabilità del Digest
• Tranne la Password, tutto in chiaro• Facile per l’hacker violare il datebase del server e
sostituirsi all’utente• Il response consente all’hacker (con lo snooping della
Request) di richiedere lo stesso documento richiesto dall’utente. Lo si può evitare impostando il server ad accettare una sola richiesta con lo stesso nc
• Man in the middle: inserendosi tra client e server si può modificare l’intestazione della risposta del server in Basic acquisendo facilmente User e Password oltre che intercettare tutti i dati in transito
5151
ConsiderazioniConsiderazioni
• Attraverso il campo server si riesce a risalire alle caratteristiche di quest’ultimo e quindi ai suoi punti deboli
• From;User-Agent;Accept-Language mettono in discussione la sicurezza dell’host
• Potersi intrufolare in un proxy dotato di cache permette di risalire a tutte le connessioni
Per evitare ciò è stato introdotto il Secure HyperText Transfer Protocol (S-HTTP)
5252
Difetti dell’HTTPDifetti dell’HTTP
• HTTP e TCP insieme sono inefficienti.
• Essendo Stateless, è semplice e leggero, ma non garantisce una connessione stabile
5353
BibliografiaBibliografia
http://hoohoo.ncsa.uiuc.edu/cgi/mailtocgi.html
Building internet firewall – Zwicky; Cooper; Chapman
www.dia.unisa.it
HTTP - Hypertext Transfer Protocol Overview
Top Related