Una volta introdotto il WSDL alla base dei nostri esempi e organizzati i progetti di base, possiamo effettuare delle prove di invocazione del servizio da remoto. Tramite Wireshark osserveremo cosa viaggia effettivamente sulla rete, in modo da vedere con i nostri occhi perché il problema della sicurezza è tanto pressante e richiede soluzioni robuste.
In primo luogo, provvediamo a lanciare l’Application Server con il progetto PresentazioneServer deployato. Nell’esempio mostrato viene utilizzato un server JBoss di tipo "default vanilla", ossia senza configurazioni personalizzate. Volendo eseguire una prova di connessione da un computer remoto, sarà necessario lanciare il server su un un generico 0.0.0.0 o l’host utilizzato dalla scheda di rete (individuabile tramite comando ipconfig /all su sistemi Windows o ifconfig su sistemi Linux).
In JBoss il parametro è impostabile tramite la scheda del server nell’interfaccia grafica messa a disposizione da Eclipse (vista Java EE), o in caso di lancio dell’AS da console tramite opzione –b. Ipotizziamo di lanciare il server su 0.0.0.0, come da immagine seguente.
Una volta completato l’avvio del server, se tutto è andato a buon fine lo troveremo presso l’URL:
http://localhost:8080/Presentazione/PresentazioneService/ServizioPresentazioneIF?wsdlEventualmente si potrà sostituire a “localhost” l’host corretto per individuarlo da remoto. Utilizzando da remoto il client creato, e impostando l’host relativo alla macchina ospitante il server, se non dovessero sorgere altri problemi (come l'irraggiungibilità del server) dovremmo ottenere la risposta all’invocazione operata. A questo punto, appurato che tutto è funzionante, avviamo Wireshark e cominciamo a “sniffare” il traffico sulla rete, magari impostando un filtro per discriminare il traffico cui siamo effettivamente interessati (ad esempio un filtro del tipo ip.src==192.168.1.100 o ip.dst==192.168.1.100 con il quale indicare che siamo interessati al solo traffico che ha origine o destinazione nell’host indicato).
Nelle immagini proposte possiamo osservare la sequenza di messaggi sniffati, con evidenziati i messaggi di invocazione dell’operazione e di risposta, entrambi su protocollo HTTP/XMI (XMI, XML Metadata Interchange, è un protocollo standard OMG per lo scambio, definizione, manipolazione e integrazione di informazioni tramite l’XML).
In particolare, per entrambi i messaggi possiamo facilmente ricavare l’origine e la destinazione dalla riga relativa al protocollo in uso (Internet Protocol Version 4, Src e Dst), i porti origine e destinazione (nel nostro caso il servizio è in attesa sul porto 8080, ma anche se lanciato su altri porti si può filtrare senza problemi), ma soprattutto l’intero messaggio SOAP in chiaro.
Esplorando il contenuto dell’Envelope SOAP è semplice ricavare l’operazione invocata, i parametri di invio, la successiva risposta e in generale tutto quanto può servire per carpire informazioni, creare pacchetti fasulli, sostituirsi agli effettivi attori. Da notare che la situazione descritta è semplicemente riproducibile su Web services RESTful, sia che i dati viaggino come XML che come JSON.
Tutto ciò che è stato descritto è ottenibile con uno sniffer free e Open Source scaricabile in qualsiasi momento. Risulta evidente il grosso rischio derivante dall’utilizzo di Web services privi di misure di sicurezza. I Web services basano lo scambio di dati sull’XML e su protocolli di uso comune come HTTP. Ciò da un lato ha permesso di semplificare l’interoperabilità e l’elaborazione dei dati grazie a messaggi testuali che contengono meta-informazioni strutturate utili a identificare cosa sta viaggiando, dall’altro l’invio di dati in chiaro agevola falle nella gestione della sicurezza. Nella prossima lezione si fornirà un resoconto delle soluzioni ai problemi fin qui evidenziati.
