Sicurezza di Server WEB Sicurezza di Server WEB e firma di componentie firma di componenti

OverviewOverview

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

HTTP evoluto

HTTP classico

Scenario di riferimentoScenario di riferimento

SERVERWEB

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)

Punti d’attaccoPunti d’attacco

SERVERWEB

Browser WEB

Attacchi al server WEB

Attacchi al browser WEB

Attacchi al canale di comunicazione

Tipi di attaccoTipi 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

Tipi di attaccoTipi 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)

Autenticazione del server WEBAutenticazione 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

Autenticazione del server WEBAutenticazione 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).

I COOKIESI COOKIES

www.omnitel.it FALSE /sito FALSE 935532272 usernamefugini

.focalink.com TRUE / FALSE 1293796841 SB_ID092278129800007154441241518571

.netscape.com TRUE / FALSE 978307388 NS_REGSHA1=%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 978307239NS_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

www.omnitel.it FALSE /sito FALSE 935532272 usernamefugini

.focalink.com TRUE / FALSE 1293796841 SB_ID092278129800007154441241518571

.netscape.com TRUE / FALSE 978307388 NS_REGSHA1=%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 978307239NS_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

ESEMPIOESEMPIO

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

SERVERWEB

Protezione del server WEBProtezione 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à

Protezione del server WEBProtezione 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

Protezione del server WEBProtezione del server WEB

PROCESSO ASCOLTATORE

PROCESSO ESECUTORE

HTTP

HTML

UID = superuser(massimi privilegi)

UID = user http(minimi privilegi)

PORT < 1024

PORT > 1024

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 WEBProtezione del server WEB

Protezione del server WEBProtezione 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)

Protezione del server WEBProtezione 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

CrittografiaSERVERWEB

Browser WEB

Protezione del canale di comunicazioneProtezione 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

HTTP

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)

SSLSSL

SSLSSL 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

SSLSSL

SERVERWEB

Browser WEB

https://www.securesite… (1)

(2) Server Certificate

Client Certificate (3)

(4) Attivazione sicurezza

Canale SSL

HTTP

Certificato a chiave pubblicaCertificato 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

Esempio di certificatoEsempio 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

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

Infrastruttura pubblica per la Infrastruttura pubblica per la certificazione di chiavicertificazione 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)

Funzionamento di una PKIFunzionamento 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

Revoca dei certificatiRevoca 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

Dove si utilizzano le chiavi Dove si utilizzano le chiavi pubbliche e i certificati?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

Active XActive 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)

COMObject

COM & DCOMCOM & DCOM

ServerServerClientClient

CO

MC

OM

Remote object onRemote object onany server any server

Object runningObject runningon clienton client

Object runningObject runningon clienton client

COM

COM & DCOMCOM & DCOM

ComponentComponent

InprocessInprocess

ClientClient

LocalLocal

LPCLPC

COMCOMrun timerun time

COMCOMrun timerun time

SecuritySecurityproviderprovider RPCRPC SecuritySecurity

providerprovider RPCRPC

RemoteRemote

Protocol stackProtocol stack Protocol stackProtocol stack

DCOM network-DCOM network-protocolprotocol

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

Utilizzo nei browserUtilizzo nei browser

JavaApplet

JavaApplet

JavaScript™JavaScript™

VBScriptVBScript ActiveXControl

ActiveXControl

HTMLDocument

HTMLDocument

Non-HTMLDocument

Non-HTMLDocument

Security in IExplorerSecurity 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

Authenticode (TM)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

Zone di sicurezzaZone 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

Livelli di sicurezzaLivelli 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.)

Livelli di sicurezza sul browserLivelli di sicurezza sul browser

HIGH

Applet - Livello di massima sicurezzaimposto dalla SANDBOXActiveX - A nessun controllo saràconsentito di funzionare

MEDIUM

Applet - Livello di massima sicurezzaimposto dalla SANDBOX + 1 MB discratch spaceActiveX - All'utente viene richiesto seaccettare il controllo

LOW

Applet - Nessun limite imposto dallaSANDBOX. Tutto è concessoActiveX - All'utente viene richiesto seaccettare il controllo

Livelli di sicurezza sul Livelli di sicurezza sul componente firmatocomponente firmato

HIGHNon si richiedono permessiparticolari. Con le applet si operaall'interno della SANDBOX

MEDIUMCome il livello HIGH, ma con lapossibilità di operazioni di I/O nellazona di scratch (1MB)

LOWRichiesta di permessi d'accessoparticolari. Le applet richiedonol'allentamento della SANDBOX

Procedura seguita per decidere se Procedura seguita per decidere se accettare un controllo ActiveXaccettare 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:

File CAB firmato con questo livelloHIGH MEDIUM LOW

HIGH Funziona inHigh

Query (Sì = Funz. in Medium) Query (Sì = Funz. in Low)

ZoneLevel

MEDIUM Funziona inHigh

Funziona in Medium Query (Sì = Funz. in Low)

LOW Funziona inHigh

Funziona in Medium Funziona in Low

Procedura seguita per decidere se Procedura seguita per decidere se accettare un controllo ActiveXaccettare 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.

Procedura seguita per decidere se Procedura seguita per decidere se accettare un’applet Javaaccettare 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.

Repository dei certificati di Repository dei certificati di IExplorerIExplorer

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

I contro di ActiveXI 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)

I contro di ActiveXI 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

Firma del codiceFirma 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

JavaJava 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

Modello di sicurezza JavaModello 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

SandboxSandbox<APPLET <APPLET

CODE=DBApplet.CODE=DBApplet.class … class …

/APPLET>/APPLET>

Page.htmlPage.html

Server WEB

JVM

Java Virtual Machine

Internet

1

Bytecode

Verifier

2Class

Loader

3

DBApplet.classDBApplet.class

Name space 4

Security

Manager5 6

Bytecode verifierBytecode 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)

Class LoaderClass 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 CLASSPATHCLASSPATH acquisiscono massimi privilegi (non sono controllate)

Security ManagerSecurity 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 ExceptionSecurity Exception

Ogni browser implementa una propria versione

Evoluzione del modello Evoluzione del modello di sicurezza Javadi sicurezza Java

Sandbox del JDK 1.02: modello valido (controllo e validazione codice) ma rigido

A partire dal JDK 1.1 allentamento delle restrizioni imposte dalla Sandbox per Applet con firma digitale

JDK futuri: ancora più flessibilità per Applet e Applicazioni in base a firma digitale, provenienza, tipo di azione svolta dal codice

JDK 1.02 JDK 1.1 JDK futuriApplet Applicaz. Applet Applicaz. Applet Applicaz.

Lettura/scritturasu disco locale

no sì opzionale sì selezionabile selezionabile

Accesso aqualunque URL

no sì opzionale sì selezionabile selezionabile

Chiamata dicodice nativo

no sì opzionale sì selezionabile selezionabile

Firma del codice no no sì no sì sì

Evoluzione del modello Evoluzione del modello di sicurezza Javadi 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

JDK 1.2 Security OverviewJDK 1.2 Security Overview