Sicurezza di Server WEB e firma di componenti

1. Sicurezza di Server WEB e firma di componenti

2. Overview • Analisi dei tipi di attacco • Aspetti di security dei servizi web • Protezione del server web • Protezione del browser • Sicurezza in Explorer e Netscape • Firma elettronica dei componenti

3. HTTP classico GET HTML page/document Browser WEB Browser WEB Ricezione di pagine HTML SERVER WEB Download di componenti software (Applet o controlli ActiveX) o instanziazione di componenti software sul server da pilotare mediante scripting Attivazione di un canale tra client web e applicazione server (Server web attivi e passivi) HTTP evoluto Scenario di riferimento

4. SERVER WEB Browser WEB Punti d’attacco Attacchi al browser WEB Attacchi al canale di comunicazione Attacchi al server WEB

5. Tipi di attacco • SUL SERVER WEB • SHADOW SERVER • DENIAL OF SERVICE • UTILIZZO DELLA MACCHINA SERVER PER FAR PONTE SU ALTRI SISTEMI • SUL CANALE DI COMUNICAZIONE • CONNECTION HIJACKING • ATTACCHI REPLAY • SNIFFING DI RETE

6. Tipi di attacco • SUL BROWSER WEB • VIOLAZIONE PRIVACY (COOKIES) • ESECUZIONE DI COMPONENTI ATTIVI FRAUDOLENTI: • Macro VBA • Script, Applet e Controlli ActiveX maliziosi • Spy Component / Back Doors • Trojan Horse • Esecuzione mediante plug-in di codice malizioso (es. documenti PDF artefatti) • ACCESSO A RISORSE DEL S.O. (HD, I/O, connessioni di rete o risorse condivise)

7. Autenticazione del server WEB • La protezione delle pagine WEB si basa su un meccanismo debole se utilizzato da solo • Si utilizzano delle ACL gestite dal server WEB e associate alle singole pagine • Nel protocollo HTTP 1.0 si utilizza una BASE AUTHENTICATION dove l’utente dal browser manda tramite URL una stringa USERNAME:[PASSWD]CodeBase64/UUEncode facilmente intercettabile e manipolabile • Username e password, codificate come sopra, sono mantenute in un semplice file di testo e manipolate con tools appositi (con interfaccia GUI o a caratteri) del server WEB

8. Autenticazione del server WEB • E’ possibile attivare un’autenticazione basata sull’indirizzo o sul nome di dominio • Si tratta di un metodo d’autenticazione insicuro • Si devono utilizzare altre forme di autenticazione • Autenticazione tramite gli account di sistema operativo (forma di autenticazione molto pericolosa in quanto espone ad attacchi l’intero sistema) • Autenticazione tramite sistemi a sfida o password usa e getta (mediante moduli software che estendono le capacità d’autenticazione del server) • Autenticazione mediante certificati a chiave pubblica (SSL e suoi derivati).

9. I COOKIES ESEMPIO www.omnitel.it FALSE /sito FALSE 935532272 username fugini .focalink.com TRUE / FALSE 1293796841 SB_ID 092278129800007154441241518571 .netscape.com TRUE / FALSE 978307388 NS_REG SHA1=%9B%E8%7B%DA%9Fy%F4%C4%0B%12%98C%86%B3229%5D%90%5F[-]UR%5FEMAIL=dallagno%40elet%2Epolimi%2Eit[-]UR%5FREG%5FID=17266063%3ASWDv1 .nscp-partners.com TRUE / FALSE 978307239 NS_REG SHA1=%b9K%bd%d4kp%ed%0b%b5TY%94z%94%2dX%0a%06%81%c9[-]UR%5FEMAIL=fugini%40elet%2Epolimi%2Eit[-]UR%5FREG%5FID=17266063%3ASWDv1

10. I COOKIES • Sono semplici file di testo di piccole dimensioni che i server WEB generano e memorizzano in un preciso direttorio all’interno di ogni browser web • Servono principalmente a memorizzare variabili di sessione, informazioni sull’utente, siti visitati • Il loro utilizzo più frequente è quello di supporto all’immissione iterata di dati nei form di input (che andrebbero persi passando da una pagina all’altra) • E’ possibile disabilitarli, ma le pagine che li utilizzano non funzionerebbero correttamente • Esistono dei gestori di cookies che ne filtrano il contenuto rendendo disponibili ai server web solo alcune delle informazioni contenute

11. SERVER WEB Protezione del server WEB • Minimi privilegi ai processi attivati dal server • Protezione del file system del server • Confinamento dei singoli servizi • Script attivati con minimo privilegio • Autiding del server ad un fine livello di granularità

12. Protezione del server WEB • Minimi privilegi ai processi attivati dal processo principale del server WEB • Il processo principale, che si pone in ascolto sulla porta 80, è purtroppo attivato dagli attuali S.O. con privilegi massimi (root in Unix, administrator in NT). Situazione a cui non si può porre rimedio. • E’ il responsabile dell’attivazione dei processi figli inerenti i servizi offerti dal server WEB (es. collegamento con fonti di dati) • Questi servizi devono essere attivati associandoli ad un utente virtuale a cui siano assegnati minimi privilegi --> si impedisce così a processi con possibili bug di aggredire l’intero sistema

13. HTTP UID = superuser (massimi privilegi) PORT < 1024 PROCESSO ASCOLTATORE HTML UID = user http (minimi privilegi) PORT > 1024 PROCESSO ESECUTORE Protezione del server WEB

14. Protezione del server WEB • Protezione del file system del server • Agli utenti connessi al server web devono essere concessi privilegi minimi (read per le pagine html, execute per gli script o applicativi) • Ai WEB administrator sono invece concessi anche i privilegi di modifica sulle pagine html e sui file di configurazione (write) • E’ buona norma impedire agli utenti la visualizzazione e la navigazione delle cartelle contenenti pagine html, script e applicativi. Non conoscere la versione e le informazioni degli script presenti sul server, impedisce lo sfruttamento dei loro possibili BUG a scopo fraudolento

15. Protezione del server WEB • Confinamento dei singoli servizi • E’ consigliata l’adozione di un server da dedicare esclusivamente a server WEB, spostando ogni altro servizio o applicativo su altri elaboratori • Nel caso ciò non sia possibile e servizi diversi utilizzino il medesimo file system, è buona prassi adottare una politica di security volta a gestire separatamente gli account di ciascun servizio limitandosi a fornire ai singoli utenti i soli privilegi strettamente necessari • Per i server WEB è consigliabile tenere separati i direttori contenenti rispettivamente le pagine html e gli script (diritti di esecuzione limitati a questo direttorio)

16. Protezione del server WEB • Script attivati con minimo privilegio • Devono essere attivati con gli stretti privilegi necessari a compiere la loro funzione • Auditing del server ad un fine livello di granularità • Si devono attivare tutte le forme di auditing possibili e tenere sotto costante monitoraggio i vari file di LOG • Si devono applicare al server tutti gli aggiornamenti e le patchs che si rendano necessari

17. HTTP Crittografia SERVER WEB Browser WEB Protezione del canale di comunicazione • si protegge il flusso dati tra server WEB e browser mediante: • l'instaurazione di un canale crittografico: • utilizzo di SSL • utilizzo di moduli crittografici ad hoc lato client e server • facendo della crittografia a livello d’applicazione • utilizzo di S-HTTP (oggi non particolarmente utilizzato) che estende l’HTML base con TAG specifici

18. SSL • SSL (Secure Socket Layer): protocollo per la crittografia di canale (realizzato da Netscape) • SSL 2.0 (autent. Server) • SSL 3.0 (autent. Server + Client) • garantisce autenticazione, integrità e confidenzialità • Instaura un canale crittografico sicuro tra il layer di trasporto e quello applicativo • Supporta i protocolli: http, nntp, smtp,ftp, telnet,... • Nell’utilizzo di http sicuro si attiva sulla porta TCP/443 e gli è stata dedicata la URL https://…… • Utilizza algoritmi a chiave pubblica per lo scambio delle chiavi di sessione (RSA, Diffie Hellman, Fortezza-KEA)

19. SSL • Utilizza algoritmi simmetrici per instaurare il canale crittografico (RC2, RC4, DES, 3DES, IDEA) • Utilizza chiavi simmetriche da 128 bit (Stati Uniti e Canada) o da 40 bit (altri paesi) e chiavi pubbliche da 512, 1024, 2048, 4096 bit • La versione 2.0 utilizza certificati X.509 v1, mentre la 3.0 certificati X.509 v3 • Negoziazione dei protocolli crittografici e del tipo di chiave

20. HTTP https://www.securesite… (1) (2) Server Certificate Client Certificate (3) (4) Attivazione sicurezza SERVER WEB Browser WEB Canale SSL SSL

21. Certificato a chiave pubblica • Che cos’è? • Una struttura dati per legare in modo sicuro una chiave pubblica ad alcuni attributi • Caratteristiche: • tipicamente lega chiave a persona • firmato in modo elettronico dall’emettitore: l’autorità di certificazione (CA) • con scadenza temporale • revocabile sia dall’utente che dall’emettitore

22. Esempio di certificato • Campi: Esempio: • version 1 • serial number 1430 • signature algorithm RSA with MD5, 1024 • issuer C=IT, O=PoliMi • validity 1/1/2000 - 31/12/2000 • subject C=IT, O=PoliMi • CN=MariagraziaFugini • subjectpubickeyinfo RSA, 1024, xxxx…xxx • digital signature yy…..yyy

23. Infrastruttura pubblica per la certificazione di chiavi • Non c’è ancora una vera PKI (Public Key Infrastructure) • Lotta accanita tra vari standard • X.509v1 (ISO) • X.509v3 (ISO + IETF) • PKCS (RSA, in parte compatibile con X.509v3)

24. Funzionamento di una PKI • Come verificare che un certificato a chiave pubblica (firmato da Ca1) sia autentico? • ….occorre il certificato della chiave di CA1 (che sarà firmato da CA1) • … e così via … fino a raggiungere la CA di root • occorre un’infrastruttura (gerarchia?) di certificazione e distribuzione

25. Revoca dei certificati • Un certificato può essere revocato prima della sua scadenza naturale • dal soggetto • dall’emettitore • un certificato revocato viene inserito in una CRL (Certification Revocation List) • quando si riceve un messaggio si deve verificare che il certificato non sia incluso nella CRL dell’emettitore • le CRL sono mantenute dagli emettitori dei certificati

26. Dove si utilizzano le chiavi pubbliche e i certificati? • Scambio di messaggi di E-mail (PEM, PGP, S/MIME) • Applicazioni proprietarie (per controllo remoto, per realizzare moduli di sicurezza) • Per apparecchiature hardware (router, HW di rete) • Per applicazioni di e-commerce • Per realizzare siti WEB sicuri

27. COMObject Active X • Nome commerciale di un insieme di tecnologie e servizi per lo sviluppo di applicazioni basate su componenti riutilizzabili • Fondata sul modello COM (Component Object Model) di Microsoft e sue estensioni (DCOM) • Permette lo sviluppo di componenti client, server e di middleware in un’ottica di programmazione in ambiente distribuito • Oggetti ActiveX: • applicazioni (*.exe) • servizi sw a caricamento dinamico (*.dll) • componenti sw (*.ocx e prima *.vbx) • applicazioni documento (internamente a IE *.exe, *.dll)

28. Client Server Object runningon client Remote object onany server COM COM Object runningon client COM & DCOM

29. Client Component Protocol stack Protocol stack LPC Inprocess DCOM network- Local protocol COMrun time COMrun time Remote Security Security RPC RPC provider provider COM & DCOM

30. Controlli ActiveX • Sono oggetti COM utilizzati come: • componenti run-time ( forniscono classi di oggetti e funzioni) • interfaccia GUI (da utilizzare in applicativi e web) • Per il programmatore sono oggetti con: • eventi • proprietà • metodi • Possono richiamare API di sistema • Si utilizzano per realizzare pagine WEB attive (scaricati tramite browser) • Utilizzati da altri componenti o pilotati da script (VB Script e Jscript) • Fuzionano con IE 3.X e 4.X e Netscape munito di appositi Plug-in

31. Utilizzo nei browser JavaApplet HTMLDocument JavaScript™ Non-HTMLDocument VBScript ActiveXControl

32. Security in IExplorer • I controlli activeX non hanno un modello di sicurezza intrinseco (Java), ma vengono presi “a scatola chiusa” • Solo le credenziali che questi portano con sé (certificati e firma elettronica) vengono valutate per decidere se accettare o no il componente • L’utente può definire le proprie politiche di sicurezza (scegliere quali componenti attivare e scaricare a diversi livelli di granularità) • E’ sempre l’utente l’ultimo arbitro della propria security

33. Authenticode (TM) • Codice wrappato in un file *.CAB e firmato elettronicamente • Politiche diverse per controlli ActiveX e Applet Java • Utilizzo di certificati secondo lo standard di certificazione X.509 • Identificazione dell’autore • Validazione dell’integrità del codice • Accountability del software scaricato

34. Zone di sicurezza • Suddivisione dello spazio degli indirizzi in 4 zone di sicurezza • Area Internet • Area Intranet • Area siti attendibili • Area siti con restrizioni • A ciascuna zona si associa un livello di sicurezza cui corrisponde un profilo di security • Sono 3 i livelli di sicurezza con policy predefinite • Un livello è personalizzabile dall’utente

35. Livelli di sicurezza • Per il livello di sicurezza definito dall’utente è possibile definire una propria policy di security (IE 4.X) • Su ogni componente (sia controllo activeX che applet Java) è possibile associare con appositi tool un livello di security predefinito (High, Medium, Low) • Solo sulle applet Java è possibile associare un profilo di security personalizzato includendo richieste d’accesso esplicite (I/O, accesso a funzioni di S.O, r/w HD, etc.)

36. Livelli di sicurezza sul browser

37. Livelli di sicurezza sul componente firmato

38. Procedura seguita per decidere se accettare un controllo ActiveX • Si identifica la zona di sicurezza a cui appartiene il server da dove il componente è scaricato (in base all’indirizzo IP) • Si utilizza il livello di security definito per tale zona • Nel caso dei 3 livelli predefiniti (High, Medium, Low) il comportamento è quello dettagliato in tabella:

39. Procedura seguita per decidere se accettare un controllo ActiveX • Nel caso del livello di sicurezza personalizzato, l’utente stabilisce la propria politica di security indipendentemente dal livello di security associato al componente • Per ogni tipo di componente da scaricare si può impostare il browser ad agire secondo tre diverse modalità: • ATTIVA: si accetta il componente senza nessun messaggio di warning all’utente; • DISATTIVA: si rifiuta il componente (che perciò non verrà eseguito) senza alcun messaggio di warning all’utente; • RICHIEDI: all’utente è mostrato un messaggio di warning con la richiesta di decidere se accettare o no il componente.

40. Procedura seguita per decidere se accettare un’applet Java • Si opera analogamente ai controlli ActiveX per i livelli di security High, Medium e Low. • Se si usa un profilo di security personalizzato, il profilo di security impiegato nella firma dell’applet è confrontato con quello impostato nel browser. In base al confronto, il browser decide automaticamente senza l’intervento dell’utente quali permessi concedere e quali negare. • All’utente compare comunque allo scaricamento anche un messaggio di warning con elencati i privilegi richiesti dall’applet.

41. Repository dei certificati di IExplorer • I certificati di autori ritenuti attendibili sono inseriti in un repository • I certificati per la firma del software sono rilasciati da apposite autorità di certificazione

42. I contro di ActiveX • Non si è assicurati sui bugs e sul codice malizioso contenuto nei controlli scaricati - Nessuna verifica del codice • I controlli possono chiamare API di sistema - Grande rischio • Possono contenere cavalli di troia o possono instaurare back-door • Problema di IE: assegnazione dei siti alle zone di security in base al loro indirizzo (address spoofing)

43. I contro di ActiveX • Incapsulamento del codice (controlli black-box) • non si può testare la bontà del controllo • Possibilità per controlli ostili di interferire con applicazioni server (COM/DCOM) quali gestori di transazioni o business critical • Si è costretti a firmare il software per utilizzarlo in IE

44. Firma del codice • Si aggiungono al codice Java una serie di istruzioni per accedere alle Java Capabilities API di Netscape • Le Java Capabilities API permettono di definire: • chi è abilitato a svolgere una data azione (identificato dalla firma elettronica apposta in seguito) - CLASS PRINCIPAL • con che privilegi - CLASS PRIVILEGE • su quali risorse del sistema - CLASS TARGET • Si wrappa poi il codice in un file *.JAR e poi lo si firma con degli appositi tool (bisogna possedere: una chiave privata e la rispettiva chiave pubblica con il certificato della CA che l’ha validata) • l’applet (possono essere più d’una) è ora pronta per essere scaricata

45. Java • Java: il linguaggio di programmazione di Sun • portabilità grazie alla codifica bytecode e VM per ogni piattaforma • linguaggio object -oriented puro • adatto all’implementazione di applicazioni di internetworking • sviluppo di Applicazioni o Applet (applicazioni che si scaricano da un server tramite la rete e si eseguono in locale) • JDK 1.1: è il core implementato nei browser • oggi implementato in Netscape 4.04 (Symantec) e IExplorer 4.01 (implementazione proprietaria secondo le specifiche SUN) • dalla versione 1.1.5 del JDK è stato inglobato il JIT Symantec • introduzione dei JavaBeans e API per la sicurezza (controllo degli accessi e crittografia) • JDK 1.2 appena rilasciato

46. Modello di sicurezza Java • Applicazioni Java: nessuna restrizione • Applet Java: adottano il modello chiamato SANDBOX che prevede: • controllo del bytecode Java (Bytecode verifier) contenuto nei file *.class • controllo delle classi Java caricate in memoria (Class Loader) • controllo della correttezza dei metodi secondo un set di regole (Security Manager) • Un’applet deve passare i 3 check (tutti) per essere eseguita dal browser

47. Internet <APPLET CODE=DBApplet.class … /APPLET> 1 2 Class Loader Bytecode Verifier 3 Page.html JVM Java Virtual Machine 4 Name space DBApplet.class 5 6 Security Manager Sandbox Server WEB

48. Bytecode verifier • Verifica il bytecode alla ricerca di comportamenti illeciti • Viene controllato il formato di ogni porzione di codice • Utilizzo di un dimostratore di teoremi che: • controlla gli oggetti istanziati • verifica l’incremento dei puntatori • verifica restrizioni d’accesso • Il bytecode ha una semantica più ricca di Java: la si può sfruttare per operazioni non ammesse dal linguaggio (minaccia)

49. Class Loader • Determina se, in run-time, può essere aggiunta una classe all’ambiente Java • Le classi sono caricate in zone di memoria separate (name space) • Le classi fondamentali del CORE Java stanno in name space a cui sono assegnati i massimi privilegi (classi protette da corruzioni esterne) • Tutte le classi inserite nella variabile d’ambiente CLASSPATH acquisiscono massimi privilegi (non sono controllate)

50. Security Manager • Controlla i metodi prima che siano eseguiti basandosi su: • la classe di provenienza • un SET di regole predefinite • Controlla: • conflitti nell’assegnazione dello spazio dei nomi • chiamate ai processi del SO • l’accesso alle classi • operazioni di lettura/scrittura su HD • operazioni di I/O su socket • Se una condizione viene violata è sollevata una Security Exception • Ogni browser implementa una propria versione