XML: testo dolce e insidioso

Quando si parla di XML o Web Service (WS) si sottointende che il protocollo di comunicazione sia l’HTTP: non è l’unica scelta possibile ma sicuramente la più adottata; gli standard XML quindi sono sottoposti a tutte le debolezze dell’HTTP.

Mi scuso subito perché molte volte parlo direttamente di messaggi SOAP (vale a dire messagi XML nel caso di WS) anche quando dovrei parlare di XML in generale.

I messaggi HTTP ‘bucano’ i firewall senza problemi. Il consorzio W3C specifica che un’architettura sicura per i web service deve garantire:

La maggior parte degli attacchi a cui vengono sottoposti i WS sono di tipo Denial of Service (DoS) mediante interruzione della disponibilità del servizio stesso oppure tecniche più evolute mediante cattura e manipolazione dei messaggi SOAP. La caratteristica più importante per i WS è anche quella più pericolosa: i WS possono invocare metodi ma non solo. Poco tempo fa ascoltavo un’intervista fatta ad un ingegnere della Microsoft che diceva che ogni programma (eseguibile) inWindows LongHorn sarà un WS. I WS infatti possono essere visti come un ottimo metodo di comunicazione tra programmi, quelli che ‘una volta’ erano i veri e cari socket. Ma se WS significa anche eseguibile allora devono esistere dei meccanismi, o meglio dobbiamo stabilire delle procedure, in modo tale da renderne sicuro ed affidabile il loro utilizzo.

Una prima suddivisione dei meccanismi di sicurezza puo’ essere di carattere temporale:

Del presente e del passato parleremo subito, i prossimi capitoli invece saranno centrati sugli standard del futuro.

HTTP basic authorization (BASIC-AUTH) è un meccanismo molto semplice usato per proteggere l’accesso ad un WS: l’utente deve possedere username e password. Il web server ha una lista di account validi e le corrispettive risorse a cui possono accedere, il client all’atto dell’invocazione del WS deve fornire la coppia username-password. Ad esempio Apache Axis realizza tale caratteristica in maniera immediata, nel listato 1.1 è mostrata l’invocazione di un WS dal lato client con le credenziali d’autenticazione dell’utente.

Listing 1.1: Invocazione WS con BASIC-AUTH

Il server cattura username e password con i metodi sotto indicati; l’handler, ossia la gestione e il controllo delle informazioni, deve essere realizzato ad-hoc oppure ci si deve appoggiare all’application server come ad esempio Tomcat.

Listing 1.2: BASIC-AUTH: lato server

Nel documento SOAP le informazioni dell’utente vengono codificatema il resto del messaggio rimane in chiaro quindi un ‘hacker’ potrebbe benissimo catturarlo, modificarne il contenuto e rispedirlo: si capisce quindi come questo meccanismo, se usato da solo, non offra alcun livello di sicurezza.

TLS (Transport Layer Security) è uno standard IETF specificato nel RFC 2246, deriva dal protocollo SSL (Secure Socket Layer); TLS è un protocollo che lavora tra il livello 4 (trasporto) e il livello 5 (sessione). Le caratteristiche fornite sono: riservatezza, integrità dei dati e autenticazione.

L’applicazione più diffusa è quella legata ai browser nella trasmissione sicura di pagine web o di dati provenienti da form HTML: si pensi ad esempio quando si controlla la mail con yahoo.it o si inviano login e password oppure quando si inserisce il numero di carta di credito per un acquisto su amazon.com (lì è un po’ più evoluto grazie al loro sistema proprietario ma la base è quella). Ora pensate che i messaggi SOAP/XML sono trasmessi di solito tramite il protocollo HTTP, unite il tutto e cosa ottenete?

Per la prima generazione di WS molti sviluppatori non usano quindi modelli ad-hoc (come quelli descritti nei capitoli successivi) ma usano sessioni SSL/TLS per fornire confidenzialità e autenticazione one-way (raramente two-way) come nel caso dei browser.

Ipotizziamo di connetterci al sito mail.yahoo.it per controllare la mail, e di scegliere la modalità di connessione sicura, verremo reindirizzati ad un indirizzo https:// ossia verrà creato un tunnel SSL/TLS tra il nostro pc e un server di Yahoo.it effettuando un’autenticazione one-way poiché noi (il client) non abbiamo un certificato valido.

Listing 1.3: Configurazione Tomcat SSL/TLS

Anche se non assicura una sicurezza paragonabile alla autenticazione two-way il tunnel SSL/TLS ‘stile-browser’ permette di aggiungere un livello di sicurezza sufficiente con un costo amministrativo quasi nullo poichè i protocolli sono integrati perfettamente all’interno di qualsiasi web/application server.

Un esempio in JAVA-Axis-Tomcat

La prima cosa da confiurare è Tomcat in modo tale che accetti connessioni SSL/TLS: deve essere creato un certificato per il server tramite l’utility di Java: keytool; successivamente si deve configurare il web server in modo tale che accetti connessioni https sulla porta 8443 modificando il file di impostazioni server.xml (listato 1.3).

Ora ci sono due possibilità come annunciato: autenticazione one side o two side. Nella prima il client in linea di massima crea una chiave di sessione, la cifra con la chiave pubblica del server. Il server una volta ricevuta la decifra con la propria chiave privata. Tutte la comunicazioni d’ora in poi avvengono cifrate con la chiave di sessione appena inviata.

Dal lato client si deve innanzitutto implementare l’interfaccia di Java X509TrustManager per accettare certificati self-signed poiché il server usa un certificato firmato da se stesso e non viene usata la mutua autenticazione (non generiamo quindi il certificato del client). E’ sufficiente riscrivere i metodi della classe checkClientTrusted e checkServerTrusted lasciandoli vuoti in modo tale da accettare le connesioni non trusted e quindi non causare eccezioni di tipo

CertificateException.

Infine è necessario modificare l’url del web services modificando la porta di connessione e il protocollo (https):

https://+ipServer+:+8443+/axis/+nameWS

E’ importante notare che una soluzione che comprenda esclusivamente SSL/TLS e WS non è ottimale, può essere adeguata in contesti dove la sicurezza non sia fondamentale ma sicuramente non lo è nelle transazioni B2B (Business to Business) o in applicazioni particolarmente critiche.

E’ possibile effettuare anche la mutua autenticazione usando il tool di Java keytool per generare i certificati per la sessione SSL/TLS. L’installazione e l’uso del certificato sul lato client è molto semplice: è sufficiente copiare il file .keystore in una directory a piacere (ad esempio nella home in Linux o nel profilo in Windows XP) e specifare nell’invocazione del WS:

Listing 1.4: WS con HTTPS

La Spire Security LLC and Forum Systems hanno stilato poco tempo fa la lista delle cinque più importanti vulnerabilità dei web service (consiglio la lettura di ‘Attacking and Defending Web Services’, veramente un ottimo documento).

Firma e cifratura: travestimento XML

Analizziamo gli standard principali per la sicurezza dei file XML, nella maggior parte dei casi sono l’immediata applicazione delle metodologie di crittografia assimetrica e simmetrica.

In questo e negli altri capitoli successivi farò una panoramica di questi protocolli dando per scontato conoscenze base di crittografia: quindi ovviamente sapete cosa intendo quando parlo di PKI o di X.509, di Kerberos and so on come dicono gli ammmmerriccani.

La flessibilità dell’XML è un vantaggio importante però introduce alcune problematiche: due documenti possono contenere le stesse informazioni ma avere differenti strutture; la differenza non riguarda la logica, ossia la struttura dei tag, ma ad esempio gli spazi all’interno dei tag, i delimitatori di riga, i commenti. . .Per un parser che deve interpretare un documento XML ciò non è rilevante ma per uno strumento di signature è fondamentale firmare esattamente e solamente i dati. Per ovviare a tale inconveniente viene introdotto il concetto di canonizzazione; la canonizzazione è un processo che consiste nell’applicare al documento XML un insieme di trasformazioni in modo da rappresentare le informazioni variabili in maniera standard. Due documenti logicamente equivalenti devono quindi avere la stessa forma canonica.

Ci sono tre tipi di XML signature: enveloping,enveloped e detached.

Quando la firma raccoglie tutti i dati si dice enveloping, quando fa parte del documento (diventandone un elemento) si dice enveloped, infine quando la firma è tenuta separata dai dati è detta detached. Il processo di signature si compone di cinque fasi:

Si deve quindi, in fase di ‘firma’, provvedere alla creazione dell’elemento Signature che contiene tre elementi:

Listing 2.1: Esempio XML Digital Signature

La procedura di validazione del messaggio è semplice ed è composta tipicamente da tre passi:

XML Encryption soddisfa la raccomandazione del W3C sulla condifenzialità.

La cifratura può riguardare il documento nella sua interezza, un elemento del documento, il contenuto di un elemento, gli attachment.

La cifratura dell’intero documento (in ogni caso) produce un file piuttosto semplice e dalla struttura sempre uguale, un esempio è indicato nel listato sequente.

Listing 2.2: Esempio XML Encryption

Viene indicato il tipo di algoritmo usato, l’identificatore della chiave (opzionale) ed infine il risultato dell’operazione di cifratura. La cifratura di un elemento invece va a riscrivere solo la parte che rigurda quell’elemento inserendo tutti i ‘campi’ del caso precedente; il resto del documento XML rimane intatto. Naturalmente verranno aggiunte le informazioni di cifratura nell’envelope nel messaggio XML. Le estensioni negli altri casi sono banali: nella cifratura del valore dell’elemento rimarrà invariato il tag, verrà modificato esclusivamente il valore (aggiungendo le stesse informazioni del caso precedente); la cifratura dell’attachment produrrà un allegato cifrato mentre le informazioni sull’algoritmo saranno contenute nel messaggio XML

XML Key Management Specification (XMKS) provvede ad un interfaccia XML per i servizi di PKI, specifica quindi la distribuzione, la validazione e la revoca delle chiavi.

Un servizio XKMS è in tutto e per tutto un WS che permette agli utenti di registrare e revocare le loro chiavi usando un dialetto XML.

E’ formato da due protocolli:

XML Access Control Markup Language (XACML) è sviluppato dall’OASIS e fornisce una sintassi per la gestione delle informazioni di autorizzazione; descrive inoltre un linguaggio di policy. La tipica applicazione riguarda il caso in cui un utente A voglia eseguire un’operazione su una risorsa, A dovrà richiedere l’autorizzazione (il permesso) a chi ‘controlla’ questa risorsa; l’organo controllore è detto Policy Enforcement Point (PEP). Il PEP forma una richiesta (request) composta: dagli attributi dell’utente A, dalla risorsa in questione, dal tipo di azione e provvede ad inviarla ad un’altra entità chimata Policy Decision Point (PDP); il compito di PDP è quello di controllare le policy e inviare a PEP il risultato (response). PEP comunicherà ad A il permesso (in caso positivo) di uso della risorsa.

Le entità PEP e PDP devono essere tenute concettualmente separate ma nessuno vieta di implementarle nella stessa applicazione.

Nonostante XACML sia molto giovane (appena uscita la versione 2.0) ha la caratteristica di poter integrarsi perfettamante con SAML (lo vedremo più avanti), LDAP e con molti altri protagonisti delle nostre notti insonni.

Web Service sicuri

1. XML firewall

I concetti visti permettono di introdurre una nuova entità nell’universo della sicurezza detta XML firewall: esso è un firewall che si occupa del controllo dei file XML, quando riceve ad esempio un documento SOAP provvede a verificare che sia firmato e cifrato correttamente e che le informazioni all’interno sia coerenti. Agisce nei livelli più alti del modello ISO/OSI o meglio del modello TCP/IP, e può essere sia di tipo hardware che software.

Come detto in altre occasioni uno dei motivi dell’insicurezza dei WS è il fatto che siano trasparenti ai firewall; con il concetto di XML Firewall eviteremo tale inconveniente: è necessario però che a tutti i documenti sia applicato XML Digital Signature e XML Encryption.

Fig. 1 Web Service sicuri

1. WS Security

Le specifiche WS-Security (WSS) indicano uno standard per l’uso delle tecnologie XML-Encryption e XML Digital Signature nei messaggi SOAP.

WS-Security precisa che l’header SOAP contenga i dati relativi alla protezione; non specifica il formato della firma o della crittografia, ma come incorporare le informazioni sulla protezione definite in base ad altre specifiche.

Uno degli aspetti fondamentali di WSS è l’uso del concetto di Security Token. Un SecurityToken è simile ad una carta d’identità o meglio ad un pass che deve essere mostrato per usufruire di un determinato WS. I token possono essere sia in formato testo che binario, vengono suddivisi in 6 tipi:

• UsernameToken: coppia login e digest della passoword

• certificato X.509: è il più usato tra quelli binari, viene definito come BinarySecurityToken

• ticket Kerberos: il Kerberos è un sistema di autenticazione nato nel 1993 ad opera del MIT, un ticket in questo contesto è un ‘insieme di dati’ che permette ad un servizio di identificare un client. Nonostante Kerberos non sia un server di AAA (assicura solo l’autenticazione) è usato in varie implementazioni di UNIX e

  come default in Windows 2000/2003

• SAML assertion: vedi capitolo successivo

• documento XCBF: nel caso di dati biometrici

• documenti XrML (eXtensible rights Markup Language): gestione diritti digitali

Se il client usa lo UsernameToken deve inviare, nella richiesta di esecuzione del web service, la sua password sottoposta ad hash e firmare il messaggio usando tale password; in caso di X.509 (PKI) il messaggio può essere firmato con la chiave privata.

Listing 3.1: UsernameToken e BinarySecurityToken

Nel listato 3.2 viene mostrato un esempio di applicazione della XML Encryption all’interno del WSS. Il body del messaggio SOAP è esattamente identico a quello del listato 2.2 mentre, come detto, nell’header vengono aggiunte altre informazioni. Altri livelli della WSS o altre specificazioni che di solito risiedono al di sopra dello standard principale sono:

• WS Trust: rende sicura e gestisce la ‘fiducia’ in un’architettura distribuita;

• WS SecureConversation: usa WSS e WS Trust che permette la negoziazione di un contesto per l’instaurazione di una connessione sicura come lo scambio delle chiavi di sessione;

• WS Federation: per lo scambio e la condivisione di informazioni sensibili tra differenti organizzazioni;

• WS SecurityPolicy: è un’aggiunta allo standard WSS, specifica policy e requisiti di sicurezza.

Listing 3.2: XML Encryption e WS Security

L’autenticazione del futuro

Il Single Sign-On (SSO) consente ad un utente di autenticarsi una sola volta per accedere a differenti risorse. Nelle sua implementazione di base permette di scambiare il securityToken in maniera sicura tra diverse entità.

Alla fine

Implementare XML Encryption (e XML-Sig) in Java non è difficile, in rete sicuramente troverete qualche articolo interessante (consiglio di partire da webservices.xml.com.L’architettura .NET offre delle discrete (mai usate personalmente, ma almeno così sembra) librerie, mamma Microsoft pensa sempre a voi. Progetti Open Source sono ad esempio XML Security di Apache, offre l’implementazione degli standard sia per C++ che per Java.

Per SAML affidatevi pure all’ottimo OpenSAML (i pacchetti che iniziano con Open sono sempre marchio di qualità), anche qui c’è sia Java che C++. A XACML ci pensa Sun con il suo SunXacml, lo trovate su sourceforge.

Il JavaWeb Services Developer Pack (versione 1.4) implementa WSS, maggiori info le trovate sul sito di Java. C’è un ottimo progetto individuale chiamato Axis-wsse che guarda caso implementa le specifiche Web Service Security per Apache Axis. Infine soluzioni proprietarie serie le offrono ad esempio Verisign, Netegrity e Entrust, per il sito googlate.

Nonostante sia decisamente più SW che HW finisco questa disordinata lista con un dispositivo hardware veramente interessante: il XS40 XML Security Gateway della DataPower.

Ricapitoliamo brevemente.

Se siete un utente qualsiasi o se avete bisogno di usare XML o i WS all’interno di una rete privata vi consiglio l’uso delle tecniche basate su SSL/TLS (o al massimo uno dei miei standard preferiti l’IPsec).

Se volete fare i fighi applicate pure XML Encryption e XML Signature.

Se siete veramente advanced allora usate SAML e usate SSO anche solo per controllarvi la posta.

Il resto inventatelo.

Copyright @2004 Verago Rudi.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being ‘Perché’, with no Front-Cover Texts, and with no Back-Cover Texts.