Sicurezza di server web e firma di componenti
This presentation is the property of its rightful owner.
Sponsored Links
1 / 53

Sicurezza di Server WEB e firma di componenti PowerPoint PPT Presentation


  • 63 Views
  • Uploaded on
  • Presentation posted in: General

Sicurezza di Server WEB e firma di componenti. 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. HTTP classico. GET HTML page/document. Browser WEB.

Download Presentation

Sicurezza di Server WEB e firma di componenti

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Sicurezza di server web e firma di componenti

Sicurezza di Server WEB e firma di componenti


Sicurezza di server web e firma di componenti

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


Sicurezza di server web e firma di componenti

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


Sicurezza di server web e firma di componenti

SERVER

WEB

Browser WEB

Punti d’attacco

Attacchi al browser WEB

Attacchi al canale

di comunicazione

Attacchi al server WEB


Sicurezza di server web e firma di componenti

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


Sicurezza di server web e firma di componenti

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)


Sicurezza di server web e firma di componenti

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


Sicurezza di server web e firma di componenti

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


Sicurezza di server web e firma di componenti

I COOKIES

ESEMPIO

www.omnitel.itFALSE/sitoFALSE935532272usernamefugini

.focalink.comTRUE/FALSE1293796841SB_ID092278129800007154441241518571

.netscape.comTRUE/FALSE978307388NS_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.comTRUE/FALSE978307239NS_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


Sicurezza di server web e firma di componenti

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


Sicurezza di server web e firma di componenti

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à


Sicurezza di server web e firma di componenti

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


Sicurezza di server web e firma di componenti

HTTP

UID = superuser

(massimi privilegi)

PORT < 1024

PROCESSO ASCOLTATORE

HTML

UID = user http

(minimi privilegi)

PORT > 1024

PROCESSO ESECUTORE

Protezione del server WEB


Sicurezza di server web e firma di componenti

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


Sicurezza di server web e firma di componenti

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)


Sicurezza di server web e firma di componenti

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


Sicurezza di server web e firma di componenti

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


Sicurezza di server web e firma di componenti

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)


Sicurezza di server web e firma di componenti

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


Sicurezza di server web e firma di componenti

HTTP

https://www.securesite… (1)

(2) Server Certificate

Client Certificate (3)

(4) Attivazione sicurezza

SERVER

WEB

Browser WEB

Canale SSL

SSL


Certificato a chiave pubblica

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


Esempio di certificato

Esempio di certificato

  • Campi:Esempio:

  • version1

  • serial number1430

  • signature algorithmRSA with MD5, 1024

  • issuerC=IT, O=PoliMi

  • validity1/1/2000 - 31/12/2000

  • subjectC=IT, O=PoliMi

  • CN=MariagraziaFugini

  • subjectpubickeyinfoRSA, 1024, xxxx…xxx

  • digital signatureyy…..yyy


Infrastruttura pubblica per la certificazione di chiavi

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)


Funzionamento di una pki

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


Sicurezza di server web e firma di componenti

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


Dove si utilizzano le chiavi pubbliche e i certificati

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


Active x

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)


Com dcom

Client

Server

Object runningon client

Remote object onany server

COM

COM

Object runningon client

COM & DCOM


Com dcom1

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


Controlli activex

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


Utilizzo nei browser

Utilizzo nei browser

JavaApplet

HTMLDocument

JavaScript™

Non-HTMLDocument

VBScript

ActiveXControl


Security in iexplorer

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


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 sicurezza

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


Livelli di sicurezza

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


Sicurezza di server web e firma di componenti

Livelli di sicurezza sul browser


Sicurezza di server web e firma di componenti

Livelli di sicurezza sul componente firmato


Sicurezza di server web e firma di componenti

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:


Sicurezza di server web e firma di componenti

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.


Sicurezza di server web e firma di componenti

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.


Repository dei certificati di iexplorer

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


I contro di activex

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)


I contro di activex1

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


Firma del codice

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


Sicurezza di server web e firma di componenti

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


Modello di sicurezza java

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


Sandbox

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


Bytecode verifier

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)


Class loader

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)


Security manager

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


Evoluzione del modello di sicurezza java

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


Evoluzione del modello di sicurezza java1

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


Jdk 1 2 security overview

JDK 1.2 Security Overview


  • Login