La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Sicurezza di Server WEB e firma di componenti. Overview n Analisi dei tipi di attacco n Aspetti di security dei servizi web n Protezione del server web.

Presentazioni simili


Presentazione sul tema: "Sicurezza di Server WEB e firma di componenti. Overview n Analisi dei tipi di attacco n Aspetti di security dei servizi web n Protezione del server web."— Transcript della presentazione:

1 Sicurezza di Server WEB e firma di componenti

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

3 HTTP evoluto HTTP classico Scenario di riferimento SERVER WEB Browser WEB GET HTML page/document Ricezione di pagine HTML Browser 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)

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

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

6 Tipi di attacco n 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 n 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 n E’ possibile attivare un’autenticazione basata sull’indirizzo o sul nome di dominio –Si tratta di un metodo d’autenticazione insicuro n 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 fugini.focalink.comTRUE/FALSE SB_ID netscape.comTRUE/FALSE NS_REG SHA1=%9B%E8%7B%DA%9Fy%F4%C4%0B%12%98C%86%B3229% 5D%90%5F[-]UR%5F =dallagno%40elet%2Epolimi%2Eit[- ]UR%5FREG%5FID= %3ASWDv1.nscp-partners.comTRUE/FALSE NS_REG SHA1=%b9K%bd%d4kp%ed%0b%b5TY%94z%94%2dX%0a%06%81%c9[- ]UR%5F =fugini%40elet%2Epolimi%2Eit[- ]UR%5FREG%5FID= %3ASWDv1 fugini.focalink.comTRUE/FALSE SB_ID netscape.comTRUE/FALSE NS_REG SHA1=%9B%E8%7B%DA%9Fy%F4%C4%0B%12%98C%86%B3229% 5D%90%5F[-]UR%5F =dallagno%40elet%2Epolimi%2Eit[- ]UR%5FREG%5FID= %3ASWDv1.nscp-partners.comTRUE/FALSE NS_REG SHA1=%b9K%bd%d4kp%ed%0b%b5TY%94z%94%2dX%0a%06%81%c9[- ]UR%5F =fugini%40elet%2Epolimi%2Eit[- ]UR%5FREG%5FID= %3ASWDv1 ESEMPIO

10 I COOKIES n 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 n Servono principalmente a memorizzare variabili di sessione, informazioni sull’utente, siti visitati n 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) n E’ possibile disabilitarli, ma le pagine che li utilizzano non funzionerebbero correttamente n 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 n Minimi privilegi ai processi attivati dal server n Protezione del file system del server n Confinamento dei singoli servizi n Script attivati con minimo privilegio n Autiding del server ad un fine livello di granularità

12 Protezione del server WEB n 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 Protezione del server WEB PROCESSO ASCOLTATORE PROCESSO ESECUTORE HTTP HTML UID = superuser (massimi privilegi) UID = user http (minimi privilegi) PORT < 1024 PORT > 1024

14 n 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 Protezione del server WEB

15 n 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 n Script attivati con minimo privilegio –Devono essere attivati con gli stretti privilegi necessari a compiere la loro funzione n 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 Crittografia SERVER WEB Browser WEB Protezione del canale di comunicazione n 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 HTTP

18 n 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,... n Nell’utilizzo di http sicuro si attiva sulla porta TCP/443 e gli è stata dedicata la URL https://…… n Utilizza algoritmi a chiave pubblica per lo scambio delle chiavi di sessione (RSA, Diffie Hellman, Fortezza-KEA) SSL

19 SSL n Utilizza algoritmi simmetrici per instaurare il canale crittografico (RC2, RC4, DES, 3DES, IDEA) n 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 n La versione 2.0 utilizza certificati X.509 v1, mentre la 3.0 certificati X.509 v3 n Negoziazione dei protocolli crittografici e del tipo di chiave

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

21 Certificato a chiave pubblica n Che cos’è? –Una struttura dati per legare in modo sicuro una chiave pubblica ad alcuni attributi n 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: version1 serial number1430 signature algorithmRSA with MD5, 1024 issuerC=IT, O=PoliMi validity1/1/ /12/2000 subjectC=IT, O=PoliMi CN=MariagraziaFugini subjectpubickeyinfoRSA, 1024, xxxx…xxx digital signatureyy…..yyy Campi:Esempio: version1 serial number1430 signature algorithmRSA with MD5, 1024 issuerC=IT, O=PoliMi validity1/1/ /12/2000 subjectC=IT, O=PoliMi CN=MariagraziaFugini subjectpubickeyinfoRSA, 1024, xxxx…xxx digital signatureyy…..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 n Come verificare che un certificato a chiave pubblica (firmato da Ca1) sia autentico? n ….occorre il certificato della chiave di CA1 (che sarà firmato da CA1) n … e così via … fino a raggiungere la CA di root n occorre un’infrastruttura (gerarchia?) di certificazione e distribuzione

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

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

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

28 COM & DCOM ServerClient COM Remote object on any server Object running on client COM

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

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

31 Utilizzo nei browser Java Applet JavaScript™ VBScript ActiveX Control HTML Document Non-HTML Document

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

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

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

35 Livelli di sicurezza n Per il livello di sicurezza definito dall’utente è possibile definire una propria policy di security (IE 4.X) n Su ogni componente (sia controllo activeX che applet Java) è possibile associare con appositi tool un livello di security predefinito (High, Medium, Low) n 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 n Si identifica la zona di sicurezza a cui appartiene il server da dove il componente è scaricato (in base all’indirizzo IP) n Si utilizza il livello di security definito per tale zona n 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 n Nel caso del livello di sicurezza personalizzato, l’utente stabilisce la propria politica di security indipendentemente dal livello di security associato al componente n 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 n Si opera analogamente ai controlli ActiveX per i livelli di security High, Medium e Low. n 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. n All’utente compare comunque allo scaricamento anche un messaggio di warning con elencati i privilegi richiesti dall’applet.

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

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

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

44 Firma del codice n Si aggiungono al codice Java una serie di istruzioni per accedere alle Java Capabilities API di Netscape n 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 n 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) n l’applet (possono essere più d’una) è ora pronta per essere scaricata

45 Java n 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) n 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 del JDK è stato inglobato il JIT Symantec –introduzione dei JavaBeans e API per la sicurezza (controllo degli accessi e crittografia) n JDK 1.2 appena rilasciato

46 Modello di sicurezza Java n Applicazioni Java: nessuna restrizione n 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) n Un’applet deve passare i 3 check (tutti) per essere eseguita dal browser

47 Sandbox Page.html Server WEB JVM Java Virtual Machine Internet 1 Bytecode Verifier 2 Class Loader 3 DBApplet.class Name space 4 Security Manager 56

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

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

50 Security Manager n Controlla i metodi prima che siano eseguiti basandosi su: –la classe di provenienza –un SET di regole predefinite n 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 Security Exception n Se una condizione viene violata è sollevata una Security Exception n Ogni browser implementa una propria versione

51 Evoluzione del modello di sicurezza Java n Sandbox del JDK 1.02: modello valido (controllo e validazione codice) ma rigido n A partire dal JDK 1.1 allentamento delle restrizioni imposte dalla Sandbox per Applet con firma digitale n JDK futuri: ancora più flessibilità per Applet e Applicazioni in base a firma digitale, provenienza, tipo di azione svolta dal codice

52 Evoluzione del modello di sicurezza Java Opzionale: l’utente può scegliere da browser quali restrizioni della Sandbox allentare se l’applet è firmata Selezionabile: modello per assegnare privilegi ad applicazioni e applet in modo più flessibile

53 JDK 1.2 Security Overview


Scaricare ppt "Sicurezza di Server WEB e firma di componenti. Overview n Analisi dei tipi di attacco n Aspetti di security dei servizi web n Protezione del server web."

Presentazioni simili


Annunci Google