1

Il protocollo HTTP seconda parte

Larosa Sabatino

2

Introduzione

L’esistenza del Word Wide Web è stato il fattore che ha determinato l’esplosione e l’incremento di internet, e di conseguenza del protocollo HTTP su cui si basa. Il notevole miglioramento delle tecnologie legate a tale sistema ha portato ad un incremento esponenziale delle sue potenzialità,ma ha anche dato vita ad una serie di problemi riguardanti la sicurezza.

3

Aspetti generali di sicurezza per un Server HTTP

Quando si installa un server HTTP su di una macchina si dà la possibilità di usufruire dei nostri servizi a molte persone.Questo però comporta molti rischi in quanto magari si vogliono tenere private alcune informazioni.Inoltre i server HTTP fanno largo uso di protocolli supplementari (SMTP,FTP) e permettono l’esecuzione di programmi (script CGI).Bisogna garantire quindi per questi motivi,che i vari servizi siano offerti in modo sicuro.

4

Aspetti generali di sicurezza per un Server HTTP

Possiamo quindi considerare:

Sicurezza del sistema su cui il server HTTP è installato

Sicurezza del server HTTP Sicurezza degli script CGI (o programmi

esterni )

5

Sicurezza del sistema su cui il server HTTP è installato

Un sistema sicuro deve soddisfare tre caratteristiche fondamentali:

Confidenzialità: le risorse che il sistema mette a disposizione devono essere fruibili solo da utenti autorizzati.

Integrità: le risorse di un sistema devono essere modificabili solo da utenti autorizzati e in modo autorizzato.

Disponibilità: le risorse che il sistema mette a disposizione devono essere accessibili da utenti autorizzati. La non soddisfazione di questa caratteristica è meglio conosciuta come la negazione del servizio (denial of service).

6

Sicurezza del sistema su cui il server HTTP è installato

Caratteristica molto importante è il sistema operativo che adottiamo.In genere, quanto più complesso e potente è un sistema operativo, tanto più esso è aperto ad attacchi dall'esterno. Quindi la sicurezza di un server HTTP parte da una corretta configurazione del sistema operativo su cui il server deve girare.

7

Sicurezza del sistema su cui il server HTTP è installato

Alcuni suggerimenti da eseguire:

Limitare il numero di account registrati sulla macchina dove il server è in esecuzione.

Assicurarsi che gli utenti con permessi di login sulla macchina scelgano buone password (password che siano abbastanza lunghe e non di senso compiuto).

Disabilitare i servizi non necessari, come ad esempio potrebbe essere l'FTP.

Rimuovere le shell e gli interpreti dei quali non si ha bisogno. Controllare accuratamente e periodicamente i log del server HTTP

per assicurarsi che non siano avvenuti eventuali attacchi, anche se non eseguiti con successo.

Essere sicuri che i permessi sul file system siano corretti, in particolar modo quelli che riguardano la parte di file system utilizzata dal server HTTP.

8

Sicurezza del server HTTPPer effettuare una corretta configurazione:

1. Eseguire il server con privilegi ristretti.2. Permessi sul filesystem: per fare in modo che

il server non possa leggere file e non vi possa accedere.

3. Facility avanzate: Listing automatico delle directory.

4. Soluzione con chroot per sistemi Unix-like: permette di restringere le operazioni del server in una certa sezione del filesystem.

5. Localizzazione degli script CGI: preferibilmente in una directory unica.

9

Sicurezza degli script CGI

Sono generalmente dei programmi eseguibili, installati sullo stesso server HTTP,che tramite l’interfaccia di comunicazione CGI permettono il passaggio di informazioni tra il server e il programma CGI, al fine di soddisfare una richiesta del client.

Sono dei potenziali punti deboli nella sicurezza di un sistema.

Bisogna quindi minimizzare i rischi dovuti a questi programmi per garantire la sicurezza.

10

Sicurezza degli script CGI

Possibili caratteristiche che possono portare alla debolezza di uno script CGI sono:

Scelta del linguaggio. Conoscenza degli strumenti. Input di uno script. Variabili d’ambiente.

11

Sicurezza degli script CGIScelta del linguaggio

La scelta del linguaggio con cui implementare un programma dipende dalle conoscenze del programmatore, però dovendo scegliere tra un linguaggio compilato ed uno interpretato è preferibile un linguaggio compilato.Questo perché:

Se si utilizza un linguaggio compilato e s’istalla il codice binario dello script, è più difficile interpretarne il funzionamento, anche riuscendo ad ottenerne il codice binario. Se si utilizza un linguaggio interpretato, il codice sorgente dello script è sempre potenzialmente disponibile.

essendo gli interpreti programmi di rilevanti dimensioni, è più facile che essi contengano dei bug, che possono essere sfruttati per compiere azioni non desiderate.

La maggior parte dei linguaggi interpretati permette di eseguire l’invocazione di comandi esterni all’interno dello script. Questo comporta che l’implementatore sia naturalmente portato ad utilizzare tali facilitazioni, introducendo più facilmente situazioni di potenziale pericolo.

12

Sicurezza degli script CGIConoscenza degli strumenti

Una cosa da non sottovalutare è che chi implementa dei programmi deve conoscere perfettamente il linguaggio e le relative problematiche di sicurezza, considerando anche, il software che lo circonda e con cui comunica.

Bisogna quindi avere tanta esperienza per scrivere dei programmi sicuri, soprattutto se questi fanno delle operazioni di lettura e scrittura.

Per precauzione bisogna quindi testare i programmi su una macchina protetta e dopo aver considerato le varie implicazioni sulla sicurezza installarli sul server, avendo sempre l’accortezza però di eseguire questi programmi sempre con il minore numero di privilegi possibili.

13

Sicurezza degli script CGI

Input di uno script

Bisogna controllare attentamente quello che viene fornito in input allo script. Quindi è necessaria una scansione dell’input, questa può essere effettuata tramite la definizione di un insieme, ben definito e di grandezza limitata, di caratteri accettabili.Prima di eseguire lo script, si esegue quindi questa scansione, e i caratteri che non appartengo alla lista vengono sostituiti con un underscore (“_”).

14

Sicurezza degli script CGI

Variabili d’ambiente

Altro punto dolente della sicurezza degli script CGI è la gestione delle variabili d’ambiente. Queste ultime sono di solito ereditate dal processo padre, quindi per gli script, dal server HTTP. Se un eventuale nemico riuscisse in qualche modo a modificare il contenuto di alcune di queste variabili, potrebbe in qualche caso manipolare il comportamento dello script.

Esistono, ad esempio, alcune variabili d’ambiente che sono pericolose in quanto controllano librerie e programmi in modo non determinabile

15

Sicurezza degli script CGI

Possibili attacchi

Considerando di aver configurato correttamente il server ecco cosa si potrebbe riuscire a fare sfruttando script CGI non sicuri:

16

Sicurezza degli script CGI Inviare via e-mail il file /etc/passwd contenente le password

degli utenti della macchina su cui il server è istallato. Anche se il file contiene delle password che sono cifrate, potrebbe comunque essere utilizzato per un eventuale intrusione non autorizzata nel sistema. Anche avere un sistema di password shadow non è una soluzione al problema. In tale approccio il campo password del file passwd contiene il carattere 'x' o '*' mentre le password vere e proprie sono contenute in un file separato, /etc/shadow, i cui permessi di lettura e scrittura sono riservati solo al superuser. Infatti in questo caso l'invio tramite mail del file /etc/passwd non fornisce le password cifrate degli utenti, ma comunque dà informazioni su tutti gli account presenti sulla macchina, informazioni che comunque potrebbero essere usate per tentare un accesso non autorizzato.

17

Sicurezza degli script CGI Inviare via e-mail una mappa del filesystem che

potrà essere utilizzata per la pianificazione di ulteriori attacchi.

Inviare via e-mail informazioni sulla configurazione utilizzabili in seguito per la pianificazione di successivi attacchi.

Eseguire applicazioni che richiedono molte risorse (find sull'intero filesystem o simili) sovraccaricando il sistema e impedendogli di espletare le sue normali funzioni (tipo di attacco denial of service).

Cancellare o alterare i file di log del server HTTP.

18

Aspetti di sicurezza per un Client HTTP

Consideriamo ora i problemi di sicurezza in cui può incorrere un normale utente che tramite il suo browser (il client appunto) si collega ad Internet per visualizzare pagine web ed usufruire dei relativi servizi messi a disposizione.

Questi sono alcuni: Rilascio inavvertito delle informazioni. Vulnerabilità di documenti e programmi.

19

Rilascio inavvertito delle informazioni

Autenticazione di base

Generalmente i server contengono delle informazioni che non si vogliono rendere pubbliche a tutti, ma solo ad utenti autenticati.

Purtroppo l’autenticazione di default che viene usata è quella chiamata di base, dove noi immettiamo in una form il nostro nome utente e la password, e questi dati vengono mandati in chiaro al server.

20

Rilascio inavvertito delle informazioni

Autenticazione di base

Il problema principale di questo approccio consiste nel reale pericolo che i nostri dati finiscano nelle mani di alcuni malintenzionati, o perché riescono ad intercettare la comunicazione, oppure perché riescono ad introdursi nel database del server; o ancora peggio il server le immagazzina in luoghi non indicati (dietro manipolazione).

21

Rilascio inavvertito delle informazioni

Autenticazione di base Una soluzione può essere quella di usare una

connessione di tipo HTTPS, assicurandosi che questa avvenga prima di immettere dati sensibili.(Ad esempio se si devono fare transazioni bancarie ecc..)

Oppure, nel caso di dati poco rilevanti e su cui non possiamo usufruire di HTTPS,è importante assicurarsi comunque di usare password differenti per ogni sito web e non usare le stesse per proteggere anche dati particolarmente importanti.

22

Rilascio inavvertito delle informazioni

Cookies

Sono un sistema inventato dalla Netscape e largamente supportato dai siti per tracciare alcune informazioni mentre noi navighiamo tra le vari pagine.

Possono contenere informazioni che riguardano un periodo, memorizzando quindi le nostre preferenze sul sito visitato, e permettendo così di caricare delle pagine personalizzate.

Oppure possono contenere le informazioni di quello che si è appena fatto, ad esempio quello che si è voluto comprare nella transazione corrente.

23

Rilascio inavvertito delle informazioni

Cookies

Il cookie è un oggetto abbastanza semplice; vi è immagazzinata una piccola quantità di informazione con associata una data di scadenza, una stringa identificatrice, e un modello URL che indica chi ci ha spedito il cookie.

24

Rilascio inavvertito delle informazioni

Cookies

Ogni volta che si visita un sito web, il browser controlla se vi sono dei cookies che non siano scaduti e che si accoppino con il modello URL, e in questo caso, li spedisce con la sua richiesta.

Le informazioni che sono in un cookie non sono di rilievo per il browser. I cookies tendono a contenere solo l’identificazione o l’elenco delle preferenze del client, utili comunque solo al sito che ha inserito il cookie.

25

Rilascio inavvertito delle informazioni

Cookies

Siccome i cookies passano non crittografati, e possono essere intercettati in qualsiasi punto, non è buona norma usarli per applicazioni critiche, ma molti siti lo fanno.

I cookie potrebbero essere utilizzati anche per tenere traccia delle nostre visite: ad esempio, alcuni siti si sono messi d'accordo per spedire cookie tra loro compatibili in modo che, ogni volta che l'utente visita uno dei siti, il browser automaticamente e a sua insaputa gli notifichi quali altri siti del gruppo sono già stati visitati. Il rischio consiste quindi nella ricostruzione della nostra provenienza.

26

Rilascio inavvertito delle informazioni

Cookies

Vi è qualche controllo sull’uso dei cookie. Alcuni browsers non danno i cookies a tutti; altri permettono di controllare la situazione quando si deve ricevere un cookie, scegliendo di respingerli tutti, chiedendo prima il consenso se accettarli o meno, o accettarne solo alcuni. Il cookie specifica il nome dell’host che deve ritornare e può dare un hostname specifico oppure una serie di hostname. Alcuni browser possono esser configurati in modo che accetteranno solo cookies che ritorneranno all’host che in origine lo aveva inserito.

27

Vulnerabilità di documenti e programmi

I server HTTP possono fornire dati in qualsiasi tipo di formati: semplici file di testo, file HTML, documenti di tipo PostScript, file di immagini(JPEG, GIF), file video (MPEG), file audio, e molti altri.

Gli utenti generalmente non cercano di capire tutti questi tipi di formati diversi.

Riconoscono alcuni tipi ( come HTML, file di testo, JPEG, e GIF ), e si affidano ai programmi esterni che fanno il tutto.

Questi programmi esterni si occupano di visualizzare, eseguire, stampare e fare tutto ciò che è appropriato per il tipo di formato.

28

Vulnerabilità di documenti e programmi

Per esempio, i browser web confrontano i file PDF e generalmente chiameranno Acrobat Reader.

Può succedere però che all’interno del documento che noi vogliamo visualizzare vi sia del codice nascosto che esegue dei comandi non richiesti come ad esempio cancellare dei file.

29

Vulnerabilità di documenti e programmi

Può capitare di scaricare un programma che oltre a fare le prerogative richieste, esegua anche altre operazioni non desiderate:

Virus Spy …

30

Vulnerabilità di documenti e programmi

Deve essere quindi l’utente a controllare le risorse a cui accede e che esegue.

Una corretta configurazione del browser Applicazioni d’ appoggio utili ed aggiornate

(antivirus …)

31

Securing HTTP (SHTTP)

Fornisce privacy attraverso crittografia ed una forte autenticazione

Proteggere gli oggetti individuali Vantaggi per il consumatore nel

commercio elettronico

32

HTTP Securing (HTTPS)

Come SHTTP Non protegge gli oggetti ma il canale di

comunicazione Usa TSL e SSL

33

Bibliografia

http://hoohoo.ncsa.uiuc.edu/cgi/mailtocgi.html

Building internet firewall – Zwicky; Cooper; Chapman

www.dia.unisa.it Telemat.die.unifi.it