1 IL PROTOCOLLO HTTP Puppo Marco. 2 Introduzione HTTP è lacronimo di Hypertext Transfert Protocol...

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 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


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


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


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


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


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


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


• 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

1 IL PROTOCOLLO HTTP Puppo Marco. 2 Introduzione HTTP è lacronimo di Hypertext Transfert Protocol...

Documents

Transcript of 1 IL PROTOCOLLO HTTP Puppo Marco. 2 Introduzione HTTP è lacronimo di Hypertext Transfert Protocol...