Introduzione alle problematiche di sicurezza nei Web Services
I Web Services sono applicazioni software modulari descritte, pubblicate, individuate ed utilizzabili attraverso il Web utili a supportare l’interoperabilità in un ambiente distribuito. I consorzi OASIS (Organization of Structured Information Standards) e W3C (World Wide Web Consortium) sono i principali responsabili dell’architettura e della standardizzazione al fine di migliorare l’interoperabilità tra le diverse implementazioni.
L’idea fondante è quella di mettere a disposizione un set definito di tecnologie basate su standard industriali che siano in grado di facilitare l’interoperabilità tra sistemi eterogenei. Obiettivo è sfruttare al meglio le risorse distribuite senza preoccupazioni per il tipo di applicazioni, linguaggi di programmazione o sistemi operativi coinvolti. I Web services si basano su un’interfaccia descritta in un formato processabile da un elaboratore, il WSDL (Web Services Description Language), scambiano messaggi SOAP (Simple Object Access Protocol) con i sistemi che li invocano e tipicamente si basano su una comunicazione HTTP.
Tra i grandi vantaggi dei Web services vi è la possibilità di disaccoppiare l’interfaccia esposta dall’effettiva implementazione permettendo un’evoluzione della logica lato consumer o provider che non impatti sull’altro lato, agevolando sia l’instaurazione di sistemi complessi e architetture orientati ai servizi che il riuso e l’integrazione di sistemi e applicazioni precedentemente realizzati.
L’approccio alla base del design dell’architettura dei Web services ha avuto successo e conseguentemente questi ultimi si sono diffusi e sono diventati di uso comune. Tutto ciò ha portato alla richiesta di un’adeguata sicurezza di utilizzo.
Instaurare un livello di sicurezza adeguato al contesto d'adozione è fondamentale per proteggere le risorse e consentirne l’impiego. E’ importante riconoscere che la sicurezza è la strada da percorrere e non la destinazione finale. Infatti occorre analizzare l’infrastruttura e le applicazioni per identificare e monitorare potenziali minacce e valutarne il rischio potenziale, valutandone l’impatto sui sistemi sviluppati, o in sviluppo, e studiare apposite contromisure. Limitarsi a utilizzare le più svariate tecnologie non è un modo efficace di instaurare la sicurezza se non vi è una adeguata cultura volta a far comprendere le vulnerabilità insite nei sistemi e nelle infrastrutture.
Si riassumono di seguito le principali criticità e le possibili contromisure:
| Criticità | Soluzione |
|---|---|
| Integrità del messaggio | Utilizzare una firma può evitare il rischio di processare messaggi modificati lungo il tragitto. |
| Confidenzialità | Occorre evitare che entità non autorizzate siano in grado di ottenere accesso a informazioni contenute nei messaggi. |
| Man in the middle | Tramite meccanismi di mutua autenticazione si può evitare che un attaccante si frapponga tra mittente e destinatario alterando i messaggi. |
| Spoofing | Tramite tecniche di autenticazione avanzate si può evitare che un attaccante assuma l’identità di un’entità fidata. |
| Replay Attacks | Utilizzando timestamp e numerando le richieste, si può evitare che attacchi basati su reinvio di richieste di elaborazione vadano ad intasare i servizi. |
Vi sono quindi diversi tipi di minacce cui fare fronte con l’obiettivo di creare un ambiente sicuro. La tabella di seguito riassume i principali requisiti di un simile ambiente.
| Requisiti | Descrizione |
|---|---|
| Autenticazione | Il processo che consente di identificare univocamente l’utente di un’applicazione o un servizio. |
| Non ripudio | Auditing e logging sono gli aspetti chiave delle politiche di non ripudio che garantiscono che l’utente non possa negare di avere cominciato e/o concluso operazioni o transazioni. |
| Autorizzazione | Il processo che governa l’accesso a risorse e operazioni da parte di utenti autenticati. |
| Confidenzialità | Il processo che garantisce che i dati rimangano privati e non possano essere acceduti da terze parti non autorizzate. |
| Integrità | Il processo che garantisce che i dati siano protetti da modifiche accidentali o deliberate. |
| Integrità e confidenzialità End-to-End | Integrità e confidenzialità vanno garantite anche in presenza di intermediari. |
| Disponibilità | Mantiene il sistema utilizzabile per utenti legittimati, evitando che venga messo fuori servizio tramite crash o attacchi volti a minarne l’accessibilità (come gli attacchi DOS). |
In un ambito SOA, la sicurezza si riflette su pratiche che includono varie misure, quali il coordinamento tra persone, processi e tecnologie, integrazione di diversi standard a livelli differenti (standard generici per la sicurezza, standard per la sicurezza nell’XML, standard per la sicurezza nei Web services), integrazione tra dati e ruoli, trade-offs tra esperienza e prospettive di business.
Per garantire un elevato livello di sicurezza per i servizi occorre individuare degli obiettivi, il che implica l’identificazione dei requisiti di sicurezza, analizzare lo spettro delle possibili minacce e in base agli obiettivi dare il giusto grado di priorità alle vulnerabilità, applicare principi, patterns, pratiche collaudate e misure di sicurezza valide all’intero ciclo di vita delle applicazioni.
Fin qui i possibili attacchi e i principali requisiti per stabilire un ambiente sicuro. Possiamo disporre di un set di soluzioni che garantiscano sicurezza a vari livelli. Un primo approccio alla sicurezza può essere basato su tecnologie di sicurezza punto-punto come il Transport Layer Security (SSL/TLS), ma ciò può non essere sufficiente per contesti di sicurezza del tipo End-to-End. Infatti, a differenza delle comunicazioni punto-punto, un messaggio può passare attraverso diversi intermediari prima di arrivare a destinazione ed essere consegnato a diversi utenti, probabilmente tra domini di sicurezza dotati di regole differenti, per cui alle più classiche tecnologie di sicurezza a livello trasporto si sono andate aggiungendo tecnologie a livello messaggio. Di conseguenza si sono sviluppati una serie di standard destinati a garantire la sicurezza ad un livello superiore, quello applicativo.
L’idea è quella di dotare i Web services di una sicurezza a livello messaggio. La soluzione naturale verrebbe dal fornire al messaggio SOAP un’estensione in grado di consentire la gestione della sicurezza alle implementazioni dello stack dei Web services. Ci si è chiesti se l’adozione di un tale meccanismo debba andare a impattare o meno sul WSDL, che per definizione dovrebbe rimanere un linguaggio di interfaccia, e come questa eventuale estensione debba impattare sui frameworks che offrono l’implementazione dello stack dei Web services. Occorrono standard in grado di facilitare e supportare l’interoperabilità e che siano indipendenti da sistemi operativi, infrastrutture applicative e linguaggi di programmazione.
Da queste discussioni sono nate una serie di soluzioni, tra tutte WS-Security, un’estensione di SOAP che consente di stabilire regole di sicurezza a livello messaggio permettendo di sfruttare la granularità dell’XML, e WS-SecurityPolicy, estensione del WSDL che tramite una serie di policy permette di descrivere nel WSDL quali meccanismi di sicurezza vengono implementati nei messaggi scambiati, con una ricchezza espressiva tale da avere un impatto non indifferente sui frameworks che implementano i Web services, per esempio CXF. Tra i risultati, quello di richiedere spesso l’utilizzo di ulteriori librerie per potere implementarne le politiche dichiarate.
Organizzazione della guida e principali strumenti utilizzati
Nella prima parte della guida si introdurrà il Web service alla base degli esempi descritti. Seguendo l’approccio top-down, se ne fornirà il WSDL, i progetti per la relativa implementazione e un semplice client d’esempio, con i quali imposteremo l’organizzazione alla base di tutti i progetti mostrati successivamente. Di seguito si effettueranno delle prove di invocazione del servizio da remoto e si effettuerà lo sniffing del traffico con Wireshark, osservando la portata dei problemi di sicurezza connessi ai Web services. Si metteranno poi a confronto le due principali soluzioni a livello trasporto e a livello messaggio.
La seconda parte presenterà un approfondimento della sicurezza a livello trasporto, migreremo su HTTPS adoperando il protocollo TLS e vedendo come generare dei certificati self-signed, ossia creati in proprio senza agenzie di garanzia. Nello specifico, si forniranno le informazioni per mettere in esercizio ed utilizzare OpenSSL e per sfruttare gli strumenti della JDK per la creazione e gestione dei certificati e dei relativi archivi.
Nella terza parte approfondiremo la sicurezza a livello messaggio, lo standard WS-Security per l’estensione dei messaggi SOAP e WS-SecurityPolicies per l’estensione del WSDL, accennando alla presenza di altri standard.
Nel quarto capitolo vedremo infine come impostare un’infrastruttura di sicurezza integrando eventualmente nel processo le agenzie terze di rilascio dei certificati. La guida è rivolta alla sicurezza per Web services, per i Web services RESTful valgono le soluzioni indicate a livello trasporto, mentre a livello di applicazione non vi sono soluzioni strutturali come quelle descritte nel terzo capitolo.
Si forniranno note sugli aspetti riguardanti i Web services, ma si consiglia di affrontare gli argomenti esposti dopo aver preso dimestichezza con l’argomento. Le seguenti risorse costituiscono un’introduzione alla materia:
Al fine di fornire degli esempi pratici utilizzeremo un Application Server, JBoss AS 6, basandoci su un IDE Eclipse. Negli esempi mostrati verrà utilizzato un IDE versione Juno JEE (e una versione Luna JEE per attività da remoto), ma in generale è sufficiente una qualsiasi versione dell’IDE Eclipse JEE con i JBossAS Tools installati. In alternativa, è possibile evitare di utilizzare i JBossAS Tools ed effettuare il deployment manuale degli archivi dei progetti, lanciando manualmente il server JBoss.
Si utilizzeranno sia lo stack nativo Java JAX-WS che lo stack CXF con un’estensione Spring, descrivendo le procedure per integrare Spring in JBoss. La piattaforma utilizzata è la JVM 6 con relativo JDK 6. Pur utili, si eviteranno riferimenti a tools di build automation e software management come Ant e Maven, in modo da concentrarci sugli argomenti della guida e presentare esempi che non richiedono troppe configurazioni addizionali.
I concetti introdotti sono generali, per cui applicabili su altri Application Server, stack e/o IDE, salvo tenere presente i limiti delle specifiche combinazioni e configurazioni. Verranno mostrati esempi di creazione di certificati, chiavi e più in generale quanto occorre per la realizzazione dei keystores richiesti, per i quali verranno utilizzati gli strumenti messi a disposizione dalla JDK, oltre a presentare cenni su appositi tools come OpenSSL. Utilizzeremo infine Wireshark per lo sniffing dei pacchetti veicolati in rete.
