1 / 53

IL PROTOCOLLO HTTP

IL PROTOCOLLO HTTP. Puppo Marco. Introduzione. 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. Introduzione. TCP/IP

orinda
Download Presentation

IL PROTOCOLLO HTTP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IL PROTOCOLLOHTTP PuppoMarco

  2. Introduzione • 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

  3. Introduzione • TCP/IP • Messaggi MIME (Multipurpose Internet Mail Extensions) • URL;URI;URN INTERNET SERVER CLIENT UTENTE

  4. Glossario • 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)

  5. Glossario • Risorsaqualsiasi tipo di dato (pagina web;immagini;…) • Origin server il server che possiede fisicamente la risorsa richiesta (è l’ultimo della catena) • Proxyapplicazione intermediaria che agisce sia da client che da server.

  6. Glossario • 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;…)

  7. Comunicazione 4 fasi • Connessioneil 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 documentoil client invia la richiesta di un documento mediante una riga ASCII terminata da CR-LF

  8. Comunicazione • 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

  9. Proxy di cache

  10. Proxy di cache

  11. Connessione HTTP

  12. La 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]

  13. La 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

  14. La 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

  15. Esempio Get 7beta.html HTTP/1.1 Referer: http://www.alpha.com/alpha.html Connectio: Keep-Alive User-Agent:Mozilla/4.16 (Macinthosh;1;PPC) Host: www.alpha.com :80 Accept: image/gif, image/jpeg, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8

  16. Metodi 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

  17. Get 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.

  18. Head Il metodo HEAD è simile al metodo GET, ma il server deve rispondere soltanto con gli header relativi, senza il corpo. HEAD è sicuro ed idempotente, e viene usato per verificare: • 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.

  19. Post Il 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.

  20. Put Il 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.

  21. Gli Header Gli header sono righe RFC822 che specificano la caratteristiche: • Generali della trasmissione • Dell’entità trasmessa • Della richiesta effettuata • Della risposta generata

  22. Header 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.

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

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

  25. Header della richiesta Posti dal client per specificare informazioni sulla richiesta User-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?)

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

  27. Header della richiesta Range: il range della richiesta. Poco usato Accept, 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.

  28. Esempio di risposta Version status-code reason-phrase CrLf [Header]* CrLf Body GET /index.html HTTP/1.1 Host: www.cs.unibo.it:80 HTTP/1.1 200 OK Date: Fri, 26 Nov 1999 11:46:53 GMT Server: Apache/1.3.3 (Unix) Last-Modified: Mon, 12 Jul 1999 12:55:37 GMT Accept-Ranges: bytes Content-Length: 3357 Content-Type: text/html <HTML> …. </HTML>

  29. Status 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).

  30. Esempi 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 posizione 400 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)

  31. Header 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).

  32. Cos’è CGI La Common Gateway Interface (CGI) è una semplice ‘interfaccia’ per eseguire programmi esterni, software o gateway, sotto un server HTTP, indipendentemente dalla piattaforma.

  33. CGI • 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.

  34. CGI 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.

  35. CGI 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.

  36. CGI Normalmente un CGI viene usato come action di una FORM. I programmi CGI ed il server comunicano principalmente attraverso quattro modi: • Variabili d'ambiente di sistema. • Comando di linea (usato per eseguire il programma CGI in una shell di sistema operativo). • Standard input (usato soprattutto con il metodo POST). • Standard output.

  37. CGI 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 • …

  38. Schemi di Autenticazione • Semplice • Challenge Response • Il client confeziona la Response • Due tipi: Basic Access Authentication Digest Access Authentication

  39. Schemi 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

  40. Basic 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

  41. Basic 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…

  42. Basic 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 …

  43. Vulnerabilità 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

  44. Digest 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

  45. Digest Authentication Scheme WWW-Authenticate è molto più complesso: HTTP/1.1 401 Unauthorized ... WWW-Authenticate: Digest realm="testrealm@host.com", qop="auth,auth-int", nonce="dcd98b710…“ opaque="5ccc069c4…" ... Corpo messaggio di risposta

  46. Digest 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):

  47. Digest Authentication Scheme Il 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="testrealm@host.com", nonce="dcd98b710…", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae4…", opaque="5ccc069c4…" ...

  48. Digest 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.

  49. Digest 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.

  50. Vulnerabilità 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

More Related