Capitolo 4
S
PECIFICHE
DI
PROGETTO
ED
IMPLEMENTAZIONE
4.1
L’architettura di alto livello
L’architettura dell’applicazione si suddivide su più livelli.
La comunicazione di informazioni avviene tra diversi sottosistemi (Figura 4.1):
Sottosistema Autenticazione Sottosistema Servizi
Figura 4.1 Sottosistemi dell'applicazione
4.1.1
Sottosistema Autenticazione
Lo scopo di questo sottosistema, come dice il nome stesso, è quello di garantire e permettere l’autenticazione di uno o più utenti.
L’autenticazione viene eseguita per mezzo di due componenti del sottosistema (Figura 4.2):
Figura 4.2 Componenti sicurezza
Il sottosistema autenticazione ha il ruolo di filtrare gli accessi all’applicazione. Riceve in ingresso le credenziali master e le credenziale one time e tramite queste compie l’autenticazione dell’utente (Figura 4.3).
4.1.2
Input credenziali Master
Primo passo è quello di richiedere le informazioni basilari per l’ autenticazione, lo username e la password master (Figura 4.3).
Queste, dopo un’analisi del problema, abbiamo riscontrato che possono essere assegnate dal fornitore dei servizi, nello specifico l’amministrazione universitaria, o tramite materiale cartaceo quindi a mezzo di lettera o tramite dispositivi mobili quali appunto sms su telefoni cellulari.
Una volta che il client ha a disposizione lo username, liberamente scelto, e la password master, assegnatagli dall’amministratore del servizio, è individuato univocamente all’interno del database degli utenti.
Vedremo poi successivamente come il sistema riceva e processi tali informazioni.
4.1.3
Input credenziali One Time
Il secondo passo richiede nuovamente altre informazioni di sicurezza che questa volta dureranno solamente per la durata della sessione; quindi l’utente è sollecitato ad inserire lo username master ed in più una nuova password, la password one time(Figura 4.3).
La trasmissione della password OTP viene effettuata per mezzo del gateway Kannel.
Le informazioni per la trasmissione e quindi il numero di cellulare del client autenticato nel primo livello, sono prelevate dal database.
La generazione della password, come dopo vedremo approfonditamente, è compito di un insieme di moduli detti APG (Automated Password Generator). In Figura 4.4 è possibile vedere nel suo insieme tutto il percorso seguito dalle informazioni di sicurezza nel sistema.
4.1.4
Sottosistema Servizi
Il sottosistema Servizi svolge il ruolo centrale nell’interesse dell’utente che utilizza la web application. E’ costituito dall’insieme di tutte le operazioni disponibili nel sistema come mostrato precedentemente (Figura 3.3).
4.1.5
Sottosistema Database
Cuore e contenitore delle informazioni è il database.
Questo viene acceduto sia in fase di autenticazione che in fase di richiesta servizi.
Tutte le informazioni presenti in esso rimangono in vita oltre la durata della web application. Il database costituisce appunto un container di informazioni persistenti.
Le informazioni di sicurezza, eccetto la password master e il numero di cellulare che possono essere modificate anche dall’utente autenticato, sono memorizzate dall’amministratore di sistema. La password one time viene memorizzata unicamente nelle variabili di sessione e quindi non ne rimane alcuna traccia nel database.
Internet Web Server Gateway Provider dispositivo mobile Telefono Cellulare Browser Client
Flusso delle informazioni
Credenziali master e one time
One time password generata
Database
4.2
Applicazione “Votionline”
L’applicazione Votionline permette all’utente, in particolare nell’ambiente universitario ad un professore, di effettuare la registrazione degli statini degli esami con un processo completamente informatizzato e con elevate garanzie di sicurezza. Tutti i dispositivi e le piattaforme di sviluppo utilizzate sono quelle fino ad ora analizzate. Vediamo adesso di addentrarci più nella specifico del sistema.
4.2.1
Autenticazione di primo livello con Jaas
L’utente richiama il servizio offerto dall’applicazione tramite web browser richiamando il nome dell’applicazione:
http://localhost/~federico/votionline
questo indirizzo viene processato dal web server tramite il file di configurazione associando alla request la JavaServer Page index.jsp .
Questa pagina genera un form che richiede all’utente le credenziali, username e password master, e tramite metodo Post le invia alla servlet Autenticazione, residente nel file Autenticazione.java nel package sicurezza:
public class Autenticazione extends HttpServlet{ }
La classe Autenticazione esegue il primo livello di sicurezza (3.1.2) usando la tecnologia Jaas (3.2.2)(Figura 4.7).
Il metodo processRequest() viene richiamato a seguito del form della pagina index.jsp; questo istanzia l’oggetto LoginContext.
Figura 4.7 Classi per autenticazione Jaas
new LoginContext(“Login”, new MyCallbackHandler(name,passwd))
Come visto nel paragrafo 3.2.2, creare il LoginContext corrisponde a ricercare il matching tra la stringa “Login” ed il LoginModule() corrispondente nel file di configurazione (Figura 3.5). Oltre a sollevare il LogModule() viene istanziato l’oggetto MyCallbackHandler(name,passwd) dove gli vengono passati come parametri lo username e la password master inserite dall’utente nella pagina index.jsp.
Una volta definito il LogModule() ed istanziato il MyCallbackHandler() si richiama il metodo login() del LoginContext. Questa chiamata di funzione nel
pacchetto Jaas genera automaticamente la chiamata del metodo login() questa volta però della classe LogModule (Figura 4.8).
Il metodo login() preleva le credenziali dal MyCallbackHandler() per mezzo del metodo handle(), e dopo aver effettuato la connessione a database, verifica l’esistenza di un utente con tali credenziali (Figura 4.8).
In caso negativo si genera un’eccezione, FailedLoginException(), l’autenticazione fallisce e la servlet reindirizza l’utente sulla pagina faildedautorization.jsp(Figura 4.11).
In caso affermativo il metodo login() che restituisce un booleano ritorna true e pone la variabile, privata del LogModule, succeeded a true.
Non essendosi verificate eccezioni il metodo commit() verifica il valore della variabile succeeded. Se la variabile è a true, come in questo caso, il metodo istanzia l’oggetto MyPrincipal(u,p,n,c) che associa al subject, appena creato con l’autenticazione, le credenziali passate nei parametri, username, password master, numero di cellulare e numero di codice presidente (Figura 4.8).
Il controllo ritorna alla servlet Autenticazione che crea una nuova sessione settando il valore di timeout per la sessione e istanzia l’oggetto InfoUser, contenitore di informazioni per tutta la durata della sessione.
4.2.2
Autenticazione di secondo livello con
OTP-APG
Una volta effettuata l’autenticazione di primo livello l’utente incontra una nuova pagina, login.jsp, che richiede l’immissione dello username e della password one time (Figura 4.12). Vedi paragrafo 3.1.3.
L’Automated Password Generator è organizzato con una procedura principale che utilizza due sottocomponenti:
• Una tabella di pesi dei caratteri.
• Una subroutine generatrice di password.
Il random password generator lavora formando sillabe pronunciabili e concatenandole per formare una parola. Le regole di pronunciabilità sono memorizzate in una tabella tridimensionale, dove appunto sono presenti i pesi per ogni combinazione di due caratteri che formano una sillaba. Le regole sono utilizzate per determinare se una certa combinazione è legale o no. I pesi sono predefiniti all’applicazione, sono stabiliti in base alla lingua utilizzata, facendo si che una password generata in una certa lingua non sia pronunciabile per un’altra. La posizione di una vocale o di una consonante è strettamente legata alle regole di pronunciabilità.
Il seme, primo input del nostro generatore random, è creato a partire da un numero random compreso tra [0,1] utilizzando la libreria SecureRandom della Sun:
ran = SecureRandom.getInstance(“SHA1PRNG”); pik = ran.nextDouble();
Una volta fornito il seme alla subroutine questa esegue un ciclo che verifica la possibilità di appendere sillabe a quelle già posizionate nella definizione della password.
Le password generate da questo algoritmo sono costituite da 8 caratteri. Sebbene gli spazi ed i caratteri speciali non siano contemplati nel dizionario, la spazio di password generabili è molto grande.Approssimativamente 18 millioni per 6-caratteri, 5.7 miliardi per 8-caratteri e 1.6 milioni di miliardi per password generate usando 10-caratteri.
La scelta del numero di caratteri è individuale e legata al livello di sicurezza che si vuol dare al sistema.
La servlet Autenticazione, porzione controller del sistema, prima di istanziare l’oggetto InfoUser iu e di indirizzare l’utente sulla pagina login.jsp istanzia l’oggetto apg AutoPwdGenerate().
La classe AutoPwdGenerate si trova nel package sicurezza.apg (Figura 4.10).
Figura 4.10 Classi per password OTP-APG
Questo insieme di classi si occupa di generare la password one time. Il costruttore della classe AutoPwdGenerate da prima inizializza la variabile privata data invocando il costruttore della classe ApgData:
data = new ApgData().
L’oggetto data costituisce il dizionario del generatore di password ed è rappresentato con una matrice tridimensionale di short inizializzata con i metodi fill() della classe ApgDataInit:
ApgDataInit.fill(this);
I valori con cui viene inizializzata la matrice sono i pesi corrispondenti ad ogni sillaba componibile dell’alfabeto; i pesi sono dati dalla variabile tris presente nella classe ApgDataInit,
final static short tris[][][],
e sono quindi dei valori preconfigurati rispetto all’applicazione.
Una volta confezionato il dizionario il costruttore della classe AutoPwdGenerate richiama il metodo generate(npw,pw1), passandogli come parametri il numero di password da generare e la lunghezza di tale password; tale metodo si occupa appunto di generare la password one time.
Figura 4.11 Pagina failedautorization.jsp
Facendo uso della classe predefinita della Sun, SecureRandom con algoritmo SHA1PRNG, viene generato un numero random cryptografato:
ran = SecureRandom.getInstance(“SHA1PRNG”)
L’unicità delle password generate è fortemente dipendente dalla randomicità del valore iniziale del numero ran che costituisce il seme da cui parte la
La disponibità di un nuovo seme random ad ogni nuovo accesso è la richiesta stringente del sistema. Sono inaccettabili generatori che basano l’implementazione delle loro password su time-clock based-system.
Il numero ran viene pesato con la somma delle frequenze delle varie sillabe. Successivamente si scorre tutta la matrice verificando che la somma delle frequenze della sillaba esima sia maggiore del numero pesato precedentemente.
In caso affermativo il carattere corrispondente all’indice trovato viene appeso alla stringa finale per generare la password. In caso negativo si continua a sommare i pesi fino a quando non si riesce a passare il controllo.
Una volta confezionata la password OTP il controllo torna alla servlet che si preoccupa di passarla come parametro all’oggetto creato InfoUser e di inviarla in formato testuale al Gateway Kannel:
URL(“http://iet.unipi.it:13013/cgi-bin/sendsms?...”+ apg.getOtp()); Per l’utilizzo del Gateway Kannel vedere il paragrafo Kannel - SMS GatewayKannel - SMS Gateway 2.1 e il paragrafo L’interfaccia Amministrativa 2.3.
4.2.3
Accesso e utilizzo della Web Application
Una volta inserite le credenziali queste vengono processate dalla servlet Autenticazione che ne verifica l’autenticità.
Il controllo viene eseguito tra le credenziali inserite e le informazioni di sessioni presenti nell’oggetto InfoUser.
Durante il controllo viene creato anche il JavaBean Logging (Figura 4.14) nel quale si immagazzinano le informazioni immesse vere o false che siano. Questi dati verranno utilizzati per creare una storia dei log effettuati dall’utente.
Una volta effettuata anche l’autenticazione di secondo livello la servlet Autenticazione perde il controllo delle operazioni ed indirizza l’utente sulla pagina servizi.jsp.
Figura 4.13 Pagina servizi amministrativi
Una volta sulla pagina dei servizi amministrativi l’utente è completamente autenticato ed ha la possibilità di utilizzare tutti i servizi a disposizione. Le informazioni di sessione vengono mantenute tra una pagina jsp e l’altra ed il timeout di sessione viene settato al valore iniziale tutte le volte che si accede ad una nuova pagina eccetto quella di logout.
Come accennato precedentemente sulla pagina principale servizi.jsp viene visualizzata una story board dei logs al sistema effettuati dall’utente, vedi figura (Figura 4.13). Ciò è permesso grazie all’utilizzo del model JavaBean logging.java (Figura 4.14).
Del JavaBean, pilotato dalla servlet Autenticazione, si istanzia l’oggetto lg: Logging lg = new Logging();
e si setta il valore del codice presidente autenticato passandolo come parametro con il valore preso dalle informazioni di sessione presenti nell’oggetto InfoUser:
lg.setCod(iu.getCod());
Figura 4.14 Classi dei JavaBean
Stabilito il codice presidente, chiave nel database degli utenti, è possibile per il JavaBean identificare univocamente nella query l’utente. Richiamando il metodo:
lg.select(),
si memorizza, nella variabile privata resultset del tipo predefinito ResultSet, tutte le tuple dell’utente con codice presidente precedentemente settato. Infine richiamando il metodo:
lg.modifica(session.getId());
Come visto nell’analisi del paragrafo 373.1.4, i servizi disponibili sono: • Ricerca statino
• Inserisci statino
• Cambia Password Master • Cambia Numero Cellulare
La ricerca dello statino porta l’utente sulla pagina find_statino.jsp.
Figura 4.15 Pagina ricerca.jsp
In questa pagina, come nelle altre, è presente codice Javascript per la verifica dinamica dei dati inseriti. L’utente può scegliere se fare una ricerca dello statino usando come chiave il numero di matricola, la data dell’esame o il codice esame. Il form passa le informazioni, con metodo post, alla servlet Dbmodify (Figura 4.6).
La servlet istanzia l’oggetto JavaBean s Statino (Figura 4.14), setta le variabili private cod e query2 e richiama il metodo
s.ricerca().
Il metodo esegue l’operazione di query sul database ricercando eventuali statini registrati a nome del codice presidente associato all’utente. Finita l’operazione la servlet ridireziona il response sulla pagina view_statini.jsp per visualizzare il risultato.
L’inserzione dello statino porta l’utente sulla pagina statino.jsp.
Figura 4.17 Pagina statino.jsp
Tutti i dati inseriti, prima di essere inviati con metodo get alla servlet di controllo Dbmodify (Figura 4.6), vengono analizzati con funzioni Javascript. Ricevuti i parametri dal form, req.getParameter(“parametro”), la servlet istanzia l’oggetto JavaBean s Statino (Figura 4.14) e richiama il metodo
s.inserisci(),
che aggiorna il database con i dati voluti. Dopo questa operazione la servlet indirizza il response sulla pagina succeeded.jsp per visualizzare il successo dell’operazione.
Il servizio Cambia password master si trova sulla pagina chgpwd.jsp.
Figura 4.18 Pagina chgpwd.jsp
L’utente è costretto ad inserire la vecchia password e a digitare per due volte la seconda. Una funzione Javascript si occupa di verificare il match tra le due inserzioni della seconda password. Tutte e due vengono inviate con metodo post alla servlet Dbmodify (Figura 4.6). La servlet istanzia l’oggetto JavaBean m ModPwd e invoca il metodo
m.verifica().
Il metodo verifica(), controlla la password vecchia inserita con quella presente sul database ed in caso affermativo l’aggiorna con quella nuova passata come parametro alla servlet altrimenti fallisce l’operazione di modifica. A seconda dell’esito dell’operazione la servlet ridireziona il response sulla pagina succeeded.jsp o su errorform.jsp.
L’ultimo servizio Cambia numero di cellulare si trova sulla pagina chgpho.jsp.
Figura 4.19 Pagina chgpho.jsp
Per poter modificare il numero di cellulare è richiesta la password master. Inseriti i dati il controllo passa ancora una volta alla servlet Dbmodify. Questa istanzia l’oggetto JavaBean n ModNumber, setta le variabili private del Bean pwd,cod e number ed invoca il metodo
n.verifica().
Il metodo verifica(), controlla il match tra la password inserita con quella presente sul database ed in caso affermativo modifica il numero di cellulare dell’utente. A seconda dell’esito dell’operazione la servlet ridireziona il response sulla pagina succeeded.jsp o su errorform.jsp.
Dopo che l’utente ha compiuto tutte le sue operazioni deve effettuare il logout dal sistema (3.1.5). Questo comporta la perdita di tutte le informazioni registrate nella sessione.
L’avvenuta disconnessione dal sistema è visualizzata nella pagina logout.jsp.
Figura 4.20 Pagina logout.jsp
L’invalidazione della sessione e con essa di tutte le informazioni ad essa associate, tra queste l’oggetto InfoUser, contenitore della password one time generata ad inizio sessione, avviene invocando nella pagina logout.jsp il metodo
session.invalidate().
Nella figura Figura 4.21 è possibile visualizzare il diagramma di tutta la Web Application Votionline.
Capitolo 5
C
ONCLUSIONI
Il lavoro svolto “Progettazione e sviluppo di un sistema di sicurezza con
l’ausilio di dispositivi mobili” ha analizzato le varie problematiche legate alla
sicurezza web ed ha cercato di proporre una soluzione adottando strumenti di comunicazione mobili, il telefono cellulare, largamente diffusi nella vita odierna.
La mancanza di sicurezza si è evidenziata principalmente sul lato client, l’utente dell’applicazione, piuttosto che sul canale di comunicazione, risorsa fondamentalmente resa sicura già da numerose tecnologie. Proprio l’utente viene ad essere nello scenario analizzato, comunicazione di credenziali su web, l’anello debole della catena. Per questo è stata ricercata una soluzione che garantisse l’autenticità della sorgente delle credenziali senza rendere eccessivamente difficoltosa la fase di autenticazione.
La scelta di token hardware (telefono cellulare) ha permesso di aumentare il livello di sicurezza dell’applicazione assicurando allo stesso tempo che il sistema potesse essere utilizzato dal maggior numero di utenti possibile.
Per l’uso di questi dispositivi mobili all’interno del sistema di autenticazione è stato necessario uno studio preventivo del gateway Kannel, gateway SMS sfociato nella progettazione ed implementazione di una interfaccia amministrativa di quest’ultimo.
L’analisi ad alto livello del problema sicurezza ha suggerito lo sviluppo di un sistema web application basandosi su piattaforma J2EE aggiungendo flessibilità e completa portabilità del codice grazie al linguaggio di programmazione Java.
L’applicazione così sviluppata presenta le seguenti funzionalità:
• Effettua un primo livello di autenticazione con password “master”. • Effettua un secondo livello di autenticazione con password
“OneTime”.
• Fornisce un insieme di servizi.
• Chiude e conclude la sessione di sicurezza.
Un possibile sviluppo che per motivi di tempo non è stato possibile sarebbe quello di garantire una comunicazione sicura tra client e server utilizzando un canale di comunicazione sicuro SSL.
Bibliografia
1. The J2EE Tutorial,http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html
2. The Java Tutorial,
http://medialab.di.unipi.it/doc/tutorial/
3. Il Webserver,
http://freephp.html.it/guide/lezione.asp?id=145
4. Il Php,
http://www.php.net/
5. Developing for the J2EE Tomcat Platform,
http://j2ee.masslight.com/index.html
6. Le pagine JSP,
http://www.jspitalia.org/index.asp
7. Suggerimenti e spunti,
http://www.html.it/
8. JSP best practice: Combine JavaBeans components and JSP technology,
http://www-128.ibm.com/developerworks/library/j-jsp05133.html?ca=dnt-419
9. Databases and Tomcat,
http://www.developer.com/db/article.php/10920_2172891_1
10. Model View Controller,
http://java.sun.com/blueprints/patterns/MVC-detailed.html 11. JavaBeans, http://j2ee.masslight.com/Chapter2.html 12. Paradigma MVC, http://www.javaportal.it/libro_j2ee/mvc.htm 13. APG, http://www.itl.nist.gov/fipspubs/fip181.htm
14. Java Password generator,
http://www.multicians.org/thvv/gpw.html
15. Pattern MVC,
http://www.claudiodesio.com/ooa&d/mvc.htm
16. JAAS reference guide,
http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASRefGuide. html
17. Authentication from password to public keys – Richard E. Smith 18. Firewall e sicurezza in rete – W. Cheswick, S. Bellovin, A. Rubin 19. Sicurezza delle reti – William Stallings
