Tesi laurea Andrija Ciric

1. UNIVERSITÀ DEGLI STUDI DI TRIESTE
Dipartimento di Ingegneria e Architettura
Laurea Triennale in Ingegneria Elettronica ed Informatica
SESAMO (application login automator):
evoluzioni applicative e considerazioni di
sicurezza su aggiornamento automatico
driver selenium
Laureando: Relatore:
Andrija Ciric Prof. Alberto Bartoli
Correlatore:
Phd. Ing. Marco D’Orlando

2. Indice
Introduzione 3
.1 SESAMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
.2 Evoluzioni applicative . . . . . . . . . . . . . . . . . . . . . . 3
.3 Aggiornamento chromedriver . . . . . . . . . . . . . . . . . . . 3
.4 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
.5 Struttura tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1 SESAMO: stato attuale 6
1.1 Sesamo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1 Lato client . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.2 Lato Server . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Prerequisiti 9
2.1 Strumenti utilizzati per lo sviluppo . . . . . . . . . . . . . . . 9
2.2 Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . 9
3 Estensione di SESAMO per reparto Testing Centre 11
3.1 Analisi automazione procedure PUTTY . . . . . . . . . . . . . 11
3.2 Aggiunta procedure citrix-ssh reparto TC . . . . . . . . . . . . 11
3.3 Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 Cos’è Selenium . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2 Uso e problematiche di Selenium in SESAMO . . . . . 12
4 Sviluppo per aggiornamento chromedriver 13
4.1 Sintesi della soluzione scelta per gli
aggiornamenti . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1 Check compatibilità ed eventuale stream del driver . . 13
4.1.2 Il confronto dello hash come controllo dell’integrità del
driver . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Implementazione Python lato Client . . . . . . . . . . . . . . . 14
1

3. INDICE
4.2.1 Il package updateDriver: ChromeDriverControl.py 14
4.2.2 Gestione delle eccezioni . . . . . . . . . . . . . . . . . . 16
4.3 Lato Server Implementazione codice Java . . . . . . . . . . . . 17
4.3.1 Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.2 Il package update: Introduzione al Design Patterning . 17
5 Security 22
5.1 Forme di attacco . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 Il TOCTTOU . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Conlusioni e sviluppi futuri 23
Appendices 24
a Esempio procedura citrix-ssh . . . . . . . . . . . . . . . . . . . 25
b Chromedriver update: lato client . . . . . . . . . . . . . . . . 25
b.1 Classe ChromeDriverControl.py . . . . . . . . . . 25
b.2 Classe App.py modifiche aggiunte . . . . . . . . . . . 28
b.3 Eccezioni . . . . . . . . . . . . . . . . . . . . . . . . . 29
b.4 Il default.yaml . . . . . . . . . . . . . . . . . . . . 29
c Chromedriver update: lato server . . . . . . . . . . . . . . . . 30
c.1 Il controller . . . . . . . . . . . . . . . . . . . . . . . . 30
c.2 Il bean . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
c.3 L’interfaccia . . . . . . . . . . . . . . . . . . . . . . . . 31
c.4 Il Default Façade . . . . . . . . . . . . . . . . . . . . . 32
Bibliografia 35
Ringraziamenti 36
2

4. Automazione e Security
Introduzione
.1 SESAMO
Il single sign-on (SSO)[2] è un meccanismo per l’autenticazione che permette
all’utente di accedere a diversi servizi tramite un’unica credenziale. YOROI
S.R.L. ha ideato per una Telco un software che utilizza una filosofia da SSO
dal punto di vista dell’utente, mentre in realtà ha un meccanismo non central-
izzato. Il software ideato prende il nome di SESAMO. SESAMO permette,
in estrema sintesi, di automatizzare il processo di autenticazione su appli-
cazioni eterogenee (web e non), permettendo all’utente finale di concentrarsi
sulle sue attività quotidiane.
.2 Evoluzioni applicative
Uno dei reparti di una Telco, il reparto Testing Centre (TC), per le pro-
prie esigenze operative deve collegarsi ogni giorno su decine di apparati ed
applicazioni. Ognuno di essi richiede specifiche credenziali di accesso. Per
automatizzare l’accesso a queste applicazioni ed apparati è stato necessario
predisporre l’automazione di alcune procedure di accesso.
.3 Aggiornamento chromedriver
Per accedere agli apparati ed alle applicazioni c’è stato il bisogno di accedere
su Citrix Workspace (software che consente di virtualizzare i server, i desktop
e le applicazioni) via web. Successivamente si è acceduto a PUTTY tramite
le procedure di automazione. Durante uno degli primi accessi si è notato un
problema di compatibilità tra le versioni di uno specifico driver (chiamato
3

5. .4. SICUREZZA
chromedriver) di un programma chiamato Selenium (usato per automatiz-
zare le procedure di login sui browser) e Chrome. Questa incompatibilità tra
le versioni bloccava il processo automatico di login su Citrix. Il driver ag-
giornato si è dimostrato indispensabile per il corretto avvio e uso del browser
Chrome. Nelle prima versione di SESAMO l’aggiornamento del driver veniva
fatto manualmente dal personale YOROI S.R.L. per i dipendenti della Telco.
Quando l’aggiornamento veniva effettuato il personale di YOROI S.R.L. ri-
lasciava una nuova versione del software che doveva essere installata sui PC
dei dipendenti della Telco. Il procedimento richiedeva tempo anche a causa
delle complessità dei rigidi processi di rilascio del software presenti nella
Telco. Gli utenti che utilizzano SESAMO, infatti, in presenza di aggior-
namenti del driver, dovevano fare la segnalazione ed attendere il personale
di supporto di YOROI S.R.L., il personale doveva aggiornare il driver alla
versione compatibile e fare una nuova release del software SESAMO. Si è
pensato quindi di cercare di trovare un modo per rendere l’aggiornamento
del driver automatico, senza dover richiedere supporto dall’esterno.
.4 Sicurezza
Durante il lavoro di sviluppo si è dovuto pensare a meccanismi di controllo
in modo da cercare di garantire l’integrità del driver. Sono stati analizzati
i possibili scenari d’attacco e sono state proposte ed implementate alcune
soluzioni per la risoluzione del problema che verranno dettagliate di seguito.
.5 Struttura tesi
Il documento è strutturato come segue:
ˆ Capitolo 1: descrizione del software di automazione SESAMO
ˆ Capitolo 2: descrizione degli strumenti di sviluppo utilizzati per le
attività
ˆ Capitolo 3: descrizione del lavoro svolto per aggiungere le procedure di
accesso ai server via PUTTY
ˆ Capitolo 4: illustrazione della logica utilizzata per l’aggiornamento
semi-automatico del driver Selenium e dettagli dell’implementazione
nel codice sorgente
ˆ Capitolo 5: analisi dei possibili scenari di attacco per bypassare i mec-
canismi di protezione di SESAMO
4

6. .5. STRUTTURA TESI
ˆ Conclusioni e possibili sviluppi futuri
5

7. Capitolo 1
SESAMO: stato attuale
Il lavoro di tirocinio si è focalizzato sullo studio di un software di automazione
all’accesso sviluppato da YOROI S.R.L. chiamato SESAMO.
SESAMO automatizza le procedure di connessione e login ad applicazioni
eterogenee per risparimiare time-work agli operatori della Telco. Le appli-
cazioni ed i servizi sono eterogenei e non è possibile accedervi con un’unica
credenziale di dominio Active Directory (AD) aziendale. Le applicazioni
utilizzate dai dipendenti della Telco sono sia di tipo web che stand-alone.
Alcune applicazioni richiedono l’utilizzo di strumenti come Putty o Multi-
Putty, alcune sono client custom (costruiti ad-hoc dai fornitori della Telco
negli anni), altre ancora necessitano di essere utilizzate attraverso sistemi di
desktop virtualizzati come Citrix.
1.1 Sesamo
1.1.1 Lato client
SESAMO è un’applicazione Windows based contenente le procedure per
l’accesso automatico a diverse applicazioni target. Una volta avviata l’applicazione,
il servizio client-backend verrà avviato automaticamente e sarà consultabile
tra i servizi di sistema. Il client interagisce con le API di Password Safe,
sbloccando il DB che contiene le password applicative. Il client interagisce
anche con un server remoto per verificare che le applicazioni target siano usate
in una Trusted Zone solo dagli utenti autorizzati. Se ciò è vero, l’operatore
deve eseguire l’accesso inserendo la password di sblocco di Password Safe. Se
l’operazione va a buon fine l’operatore viene abilitato all’uso delle procedure
per accedere alle applicazioni target supportate.
6

8. 1.2. UTILIZZO
Per ogni utente saranno abilitate e usabili unicamente le procedure di ac-
cesso ai target autorizzati. Dopo che l’utente avrà selezionato un’applicazione
target, il client avvierà i tool necessari e interagirà per accedere automatica-
mente al target. Se la procedura richiede di utilizzare e accedere via citrix,
in certi casi ci potrà essere il bisogno di un’autenticazione di tipo 2FA o di
risolvere un CAPTCHA, SESAMO in quel caso resterà in attesa dell’input
da parte dell’operatore per la risoluzione del CAPTCHA o del PIN.
1.1.2 Lato Server
Il Server si integra con i sistemi di dominio e di Inventory del cliente Telco per
garantire l’utilizzo del servizio ai soli utenti autorizzati. L’integrazione con
il sistema di Inventory è stato realizzato per consentire ad ogni utilizzatore
del servizio di utilizzare le sole procedure di accesso alle applicazioni e, in
generale, ai target di propria pertinenza.
1.2 Utilizzo
Allo stato attuale SESAMO viene usato dai gruppi operativi della Telco e
gli consente di accedere a diverse applicazioni permettendo loro di utilizzare
servizi eterogenei, come per esempio: applicazioni web, applicazioni custom
client based, terminali come PUTTY, ecc. E’ stato rilevato che quando
Chrome si aggiorna il driver Selenium non funziona correttamente e non è
possibile automatizzare le procedure di accesso sui siti web tramite SESAMO.
La tesi consisteva nell’evolvere SESAMO ed estenderlo anche ad altri reparti
della Telco, facilitando l’accesso alle applicazioni da parte degli utenti. Il
lavoro si è dopo evoluto in quanto per accedere tramite Citrix ad una specifica
applicazione, c’era il bisogno di fare un login tramite browser. Il login non
è potuto avvenire in quanto il browser Chrome non era compatibile con la
versione del driver Selenium, usato per l’automazione dei siti web. Si è
proceduto quindi con lo sviluppo di un sistema automatico di aggiornamento
del driver con successiva analisi di meccanismi di protezione dell’integrità del
driver stesso.
7

9. 1.2. UTILIZZO
Figure 1.1: Schema della struttura di SESAMO.
8

10. Capitolo 2
Prerequisiti
2.1 Strumenti utilizzati per lo sviluppo
Per poter predisporre un ambiente di lavoro adatto dove poter ricreare e
simulare SESAMO, sono stati necessari i seguenti strumenti:
ˆ Windows 10 con la versione 3.7 di Python per il backend, è stata usata
l’IDE PyCharm per la parte di sviluppo del codice. Per il frontend è
stato utilizzato il framework Electron (sviluppato in node.js) per poter
avviare la GUI locale. Inoltre è stato installato Citrix Workspace e
Cisco AnyConnect e vari certificati di sicurezza per potersi collegare
via VPN alla network della Telco, usato sopratutto per poter verificare
l’accesso delle applicazioni target con PUTTY tramite SESAMO;
ˆ macchina virtuale con l’ultima versione LTC di Linux Ubuntu, all’interno
della VM è stata installato OpenJDK con Java 1.8 con Maven;
ˆ accesso ai repositori gitLab per poter usufruire del codice sorgente di
tutti i componenti.
2.2 Reverse Engineering
Dopo l’installazione dei vari componenti si è verificato il corretto funziona-
mento di SESAMO. C’è stato il bisogno di studiare il codice sorgente sia di
Sesamo Client che di Sesamo Server. Il processo di studio si è effettuato con il
metodo del reverse engineering per comprenderne l’architettura, la struttura
e il funzionamento del software.
9

11. 2.2. REVERSE ENGINEERING
Sono state utilizzate due versioni di SESAMO:
ˆ La prima versione è quella utilizzata in PROD, è stata usata per ag-
giungere le procedure ssh per il reparto di testing e poterne verificare
il funzionamento.
ˆ La seconda è una versione modificata del client e del server, la modifica
è stata fatta per poter far funzionare in locale il software end to end
sia dal lato client che dal lato server e poter permettere di fare le ap-
propriate implementazioni per l’aggiornamento del driver su entrambi
i lati.
10

12. Capitolo 3
Estensione di SESAMO per
reparto Testing Centre
3.1 Analisi automazione procedure PUTTY
SESAMO è un software che permette l’autenticazione automatica a vari
servizi distinti fra di loro, supporta in particolare procedure di login per Cit-
rix, SSH, applicazioni custom web. Supporta inoltre, tra le altre, procedure
di autenticazione a macchine che utilizzano l’applicazione Putty esposte da
ambiente virtualizzato Citrix. Consultando il reparto di testing della Telco
è emerso il problema della proliferazione delle credenziali per i singoli server
ed apparati. Si è notato che per ogni apparato di rete o applicazione esistono
credenziali diverse e possono essere quindi gestite da SESAMO.
3.2 Aggiunta procedure citrix-ssh reparto TC
Il lavoro consisteva nell’aggiunta di procedure di collegamento tramite
l’interfaccia di SESAMO o tramite un file di formato yaml utilizzato per
le procedure. L’obiettivo era di permettere ai colleghi del TC di operare
rapidamente recuperando tempo. Le procedure aggiunte erano procedure di
tipo citrix-ssh per connettersi tramite PUTTY a diversi apparati o server via
SSH, tramite appunto Citrix. Il codice di automazione per l’autenticazione
sui target era già disponibile nel codice sorgente del client di SESAMO,
quindi non ci sono state modifiche di alcun tipo all’interno del codice sorgente
per questa attività. Una volta aggiunte le procedure per connettersi ai vari
apparati sono state inserite le credenziali in Password Safe per accedere agli
ultimi, successivamente si è verificato il corretto funzionamento per l’accesso.
Durante la verifica del funzionamento delle procedure si è notato che per
11

13. 3.3. SELENIUM
funzionare correttamente ci deve essere la compatibilità fra la versione del
driver Selenium e quella del browser Chrome. Non si ha alcun controllo sul
browser Chrome che, com’è noto, si può aggiornare automaticamente quando
è disponibile una sua nuova versione.
3.3 Selenium
3.3.1 Cos’è Selenium
Selenium[3] è uno dei tool più diffusi per l’automazione di browser. La ver-
sione odierna di Selenium consente agli sviluppatori di testare e registrare le
interazioni con un’applicazione web, per poi ripeterle a piacere in modo au-
tomatico. Uno dei componenti chiave che rendono possibile questo processo
è il Selenium WebDriver. SESAMO utilizza come browser Google Chrome e
il driver Selenium associato a Chrome, chiamato chromedriver, viene usato
per le sue attività di automazione interna.
3.3.2 Uso e problematiche di Selenium in SESAMO
Quando il target della procedura di SESAMO è un sito web o richiede
un’accesso su browser, viene utilizzato Selenium, che contiene accessori e li-
brerie per supportare l’automazione durante la navigazione. Quando Chrome
si aggiorna sul PC è necessario cambiare anche il chromedriver all’ultima
versione compatibile, in quanto la retrocompatibilità non è garantita quando
viene fatta partire una navigazione. Ad oggi questa operazione viene fatta
per l’azienda Telco manualmente dal team di sviluppo, con l’interfacciamento
tramite desktop remoto da parte di uno degli operatori di supporto. Questo
scarica e sostituisce all’interno dell’apposita cartella il file .exe del driver. Nel
seguente capitolo è stato descritto il metodo per eseguire questa operazione.
12

14. Capitolo 4
Sviluppo per aggiornamento
chromedriver
4.1 Sintesi della soluzione scelta per gli
aggiornamenti
4.1.1 Check compatibilità ed eventuale stream del driver
L’idea è stata di creare una logica di controllo in modo che ogni volta che viene
richiamata una procedura che utilizza Selenium, venga effettuato un check
nel sistema tra le versioni di Chrome e del chromedriver. Se dal check risulta
che le due versioni non combaciano si effettua una richiesta di tipo GET al
server di Sesamo. La richiesta contiene all’interno dell’URL un parametro
con la versione attuale installata del browser Chrome sul client. Il server ha
al suo interno una cartella specifica con tutte le versioni dei chromedriver.
All’interno di ogni sotto cartella si trova l’ultimo aggiornamento della rispet-
tiva versione. Quando il GET arriva al server, quest’ultimo effettua un con-
trollo per identificare se ha disponibile la versione del chromedriver corrispon-
dente. Una volta trovata la versione, viene mandato uno stream del driver che
viene prelevato dal client, sostituendo il driver attuale nell’apposita cartella
situata in AppData/Yoroi/Sesamo. Se la versione non è presente sul server,
quest’ultimo lancia un’eccezione che viene recuperata dal client, il messag-
gio ricevuto viene subito dopo mostrato sulla GUI all’utente, indicandogli
l’errore.
13

15. 4.2. IMPLEMENTAZIONE PYTHON LATO CLIENT
4.1.2 Il confronto dello hash come controllo dell’integrità
del driver
Dopo che il driver viene scaricato, il client manda un’altra richiesta di tipo
GET al server in cui viene richiesto lo hash del file ricevuto (in questo caso
è stato scelto l’algoritmo MD5) e manda una stringa di risposta contentente
lo hash del file stesso al client. Questo procedimento serve per verificare
l’integrità del file una volta ricevuto. Il client calcola anch’esso lo hash sul
chromedriver ricevuto e fa il confronto con la stringa dello hash fatto sul
chromedriver dal server. Se il confronto va a buon fine viene avviata la
procedura che utilizza il chromedriver, facendo riprendere SESAMO da dove
si è fermato. Se il confronto non va a buon fine viene lanciata un’eccezione con
un determinato messaggio che indica che non si può procedere con l’utilizzo
dell’applicazione target selezionata a causa del chromedriver non corretto.
Anche quando il check del driver rileva che le versioni sono compatibili, lo
hash viene effettuato ogni volta che viene selezionato un target che utilizza
Selenium, non solo dopo l’aggiornamento. Questa operazione viene fatta per
garantire l’integrità del driver ogni volta che deve essere utilizzato.
4.2 Implementazione Python lato Client
4.2.1 Il package updateDriver: ChromeDriverControl.py
Per risolvere il problema si è deciso di creare un package dedicato per la
gestione dei problemi legati al chromedriver modificando le classi Python sul
Client. Il client è scritto in Python[6] ed il package che è realizzato contiene
la classe ChromeDriverControl.py e delle Exception legate ai relativi
errori da gestire.
La classe App.py
All’interno della classe App.py si è pensato di istanziare ChromeDriverControl.py.
Tramite App.py SESAMO riesce ad identificare in base alle informazioni
ricevute qual è l’applicazione target per la quale bisogna far partire la rispet-
tiva procedura. Istanziare ChromeDriverControl.py nel costruttore di
App.py e richiamare i metodi ogni volta che si sarebbe attivato un target
che utilizza Chrome è risultata una buona soluzione.
14

16. 4.2. IMPLEMENTAZIONE PYTHON LATO CLIENT
Il confronto tra le versioni
Come primo passo c’è stato il bisogno di capire come recuperare le versioni
di Chrome e del chromedriver, ci sono due semplici metodi che prelevano le
rispettive versioni ed un metodo che fa il confronto fra esse:
ˆ driverVersion(): la versione utilizzata del driver viene prelevata
tramite dei comandi su terminale e messa su stringa;
ˆ chromeVersion(): la versione utilizzata di Chrome viene prelevata
dal registro di sistema e messa su stringa;
ˆ control(): vengono richiamati i due metodi che restituiscono le
rispettive versioni. All’interno del metodo si effettua un semplice con-
fronto con le cifre significative delle versioni, per verificare la loro com-
patibilità. In base all’esito del confronto verrà restituito un boolean che
indicherà in un’altro metodo se procedere con l’operazione di stream
del driver dal server.
Lo stream del driver
Il metodo che invoca lo stream è stato chiamato nella classe App.py prima
che vengano richiamate le applicazioni target che utilizzano Selenium.
All’interno del metodo checkDriver() viene richiamato il metodo control(),
se il controllo della versione in quest’ultimo non va a buon fine, fa partire il
codice che interagisce con il server per poter ricevere lo stream del driver cer-
cato. Più in dettaglio il metodo si fa passare le credenziali per poter accedere
alle procedure della Telco, richiama il metodo control() che ritorna un
boolean. Se quest’ultimo ritorna un False, il metodo manda una richiesta di
tipo GET specificando al server la versione del chromedriver che gli serve.
Se l’utente non si è loggato, le credenziali per il root per la Telco (conservate
in Password Safe) vengono utilizzate per effettuare il login. Quando viene
effettuato il login viene rimandata una richiesta GET e se il server contiene
il driver desiderato, manda lo stream che viene ricevuto dal client e salvato
in formato .exe nella cartella di AppData/Yoroi/Sesamo del PC locale.
L’MD5
Gli ultimi due metodi controllano l’integrità del file scaricato, vengono atti-
vati nella classe App.py, prima che vengano richiamate le applicazioni target
che utilizzano Selenium. Il check è diviso in due classi:
ˆ hash(): questo metodo ha il compito di fare l’hash vero e proprio del
file;
15

17. 4.2. IMPLEMENTAZIONE PYTHON LATO CLIENT
ˆ checkHash(): questo metodo effettua uno scambio di messaggi https
con il server. Il server infatti manda una risposta https con lo hash del
rispettivo driver, sul client viene fatto il confronto, se è integro permette
al software di utilizzare Selenium sulla macchina.
4.2.2 Gestione delle eccezioni
Sono stati identificati tre tipi di eccezioni da gestire che sono elencati nei
seguenti paragrafi con la loro rispettiva descrizione.
DriverNotFoundException()
L’eccezione DriverNotFoundException() è un’eccezione che viene fatta
partire nel caso in cui la risposta https del server generi un errore 404, ovvero
il server non ha nella sua repository la cartella associata a quella versione del
chromedriver. L’eccezione genera una risposta che viene passata al frontend,
che grazie ad una semplice implementazione sul codice JavaScript, fa apparire
sulla GUI un messaggio d’errore all’utente.
MD5Exception()
L’eccezione MD5Exception() viene fatta avviare nel caso in cui l’MD5
fatto sul chromeDriver del client non combaci con l’MD5 fatto sul chromedriver
del server. Viene generato un messaggio d’errore che viene passato al fron-
tend che fa uscire un messaggio d’errore indicando che il driver presente sul
PC è corrotto e di conseguenza non può essere avviata la navigazione.
UnknownHashException()
Quest’ultima eccezione viene richiamata nel momento in cui si decida di
utilizzare metodi Hash diversi, ma l’hash fatto sul server non è supportato
o è errato. In quel momento il server manda un messaggio di errore 405. Il
backend lo recupera passandolo al frontend che farà in modo di mandare il
messaggio arrivato dal server all’utente.
Note sulle eccezioni
Sono state create eccezioni dedicate per fare in modo di propagare in modo
più chiaro e possibile le problematiche sul codice. Le eccezioni vengono ril-
evate in un’altra classe chiamata Server.py, qualsiasi errore non previsto
verrà comunque gestito in default e passato ad una generica Exception pre-
sente sempre nella classe citata.
16

18. 4.3. IMPLEMENTAZIONE JAVA LATO SERVER
Frontend
Sul lato frontend vengono mandati direttamente dal backend i messaggi di
errore registrati qualora una delle tre eccezioni venissero sollevate. Il frontend
recupera il messaggio e lo visualizza sulla GUI in caso di errore.
4.3 Implementazione Java lato Server
4.3.1 Spring Boot
Spring Boot[5] è il framework utilizzato su SESAMO Server che facilita
la scrittura del codice, riducendo notevolmente il tempo impiegato per la
scrittura di quest’ultimo. Utilizza un sistema di annotazioni indicate con
il simbolo ”@”. Le annotazioni sono un elemento sintattico utilizzato per
etichettare degli elementi di codice come classi, interfacce, variabli o metodi.
Ogni strumento o ambiente sa interpretare le annotazioni di propria compe-
tenza, ignorando tutte le altre.
4.3.2 Il package update: Introduzione al Design Pat-
terning
Sul Server si è applicato un design pattern[1] approfondito in azienda. Si è
deciso di creare un nuovo package che abbia una struttura come di seguito:
ˆ Controller: il suo scopo fondamentale è quello di creare una distinzione
tra il modo in cui il software gestisce i dati e il modo in cui il software
interagisce con l’utente.
ˆ Façade: nasconde la complessità di un sistema e offre un’interfacca ai
client che vogliono accedere ad esso
Il tipo di approccio che è stato adottato per scrivere il codice sul Server
si può riassumere nella seguente frase:
”prendere le parti del programma che variano ed encapsularle in modo che
successivamente si possono estendere le parti del codice che subiscono vari-
azioni, senza affliggere le parti di codice statiche.”
Questo approccio viene detto ”OPEN TO EXTENSION, CLOSED TO MOD-
IFY”.
17

19. 4.3. IMPLEMENTAZIONE JAVA LATO SERVER
Il controller
Il ReceiveVersionController è la classe controller utilizzata nel pack-
age. Il metodo costruttore utilizza l’annotazione @Controller, in modo da
passare al codice le informazioni necessarie affinchè la classe si comporti
come un effettivo controller.
La classe istanzia un oggetto del ReceiveVersioneFacade (l’interfaccia) al
suo interno, la classe contiene due metodi:
ˆ getDriverByVersion(@PathVariable String selenium
DriverVersion): ritorna un oggetto del tipo ResponseEntity<?>
in quanto può ritornare lo stream del driver, ma potrebbe anche tornare
una stringa dovuta a un’eccezione;
ˆ getHash(@PathVariable String seleniumDriverVersion):
ritorna un oggetto del tipo ResponseEntity<String>. Contiene
la risposta con lo hash del driver. Nei prossimi paragrafi verranno
descritti nel dettaglio i metodi della façade che vengono richiamati
all’interno del controller.
Si può notare l’annotazione @PathVariable, questa preleva dall’url la
versione del browser Chrome che gli viene mandata e la passa per verificare
nei metodi della classe DefaulfVersionFacade l’esistenza del driver as-
sociato. Entrambi i metodi inoltre richiamano tre tipi di annotazioni che
stanno in ascolto:
ˆ @GetMapping(value=/api/sesamo/driver/{seleniumDri
verVersion}): utilizzato per lo stream, all’interno delle parentesi
viene specificato l’URL grazie al quale il rispettivo metodo viene richiam-
ato. All’interno dell’URL viene specificata la versione tra le parentesi
graffe;
ˆ @GetMapping(value=/api/sesamo/hash/{seleniumDri
verVersion}): utilizzato per lo hash, all’interno delle parentesi viene
specificato l’URL grazie al quale il rispettivo metodo viene richiamato.
All’interno dell’URL viene specificata la versione tra le parentesi graffe;
ˆ @ResponseBody: è un’annotazione che mappa il body delle richieste
HTTP, indica che il valore restitutito dal metodo del controller costi-
tuisce il body della response.
18

20. 4.3. IMPLEMENTAZIONE JAVA LATO SERVER
Il Bean
F All’interno della classe ReceiveVersionConfiguration() viene is-
tanziato il Java Bean. Il Bean è un componente software esterno scritto
in linguaggio di programmazione Java secondo una particolare convenzione.
E’ usato per incapsulare molti oggetti in un singolo oggetto, cosı̀ da poter
passare il bean invece degli oggetti individuali. Le annotazioni utilizzate
sono @Configuration, che serve ad indicare che una classe dichiara uno o
più metodi di tipo @Bean, e che potrebbe essere processato dal contenitore
Spring per generare bean e servizi richiesti da questi durante il runtime.
La Façade: l’interfaccia
La classe ReceiveVersionFacade è un interface che contiene i metodi del
DefaultReceiveVersionFacade che vengono richiamati nel controller.
I due metodi hanno lo stesso nome dei metodi del controller, e sono:
ˆ getDriverByVersion(String version);
ˆ getHash(String version).
I metodi verranno descritti nel prossimo paragrafo dedicato al cuore del
package, che contiene tutta la logica che serve per eseguire le operazioni del
server ai fini di trasferire il chromedriver o mandare lo rispettivo hash.
La logica del package
Il DefaultReceiveVersionFacade è la classe del package che contiene
tutta la logica nascosta che viene richiamata dall’interfaccia e quindi dal
ReceiveVersionController. La prima cosa che viene notata all’interno
della classe è una variabile privata di tipo stringa chiamata chromeDriverFolder,
preceduta dall’annotazione @Value("$(chrome.drivers.folder)")
che indica il valore di default del path per arrivare alle sottocartelle con
le rispettive versioni. Il valore di default del path si trova nel file applica-
tion.yml sotto la voce: ”chrome: drivers: folder: /tmp/chromedriversfolder”.
A seguire l’elenco dei metodi con la relativa descrizione:
ˆ findDriver(String chromeVersion): il metodo ritorna un oggetto
di tipo Optitional<File>. Crea al suo interno un oggetto fi-
nal di tipo File, chiamato driver. Se il file esiste ritorna un’oggetto
Optional.of(driver), altrimenti Optional.empty();
19

21. 4.3. IMPLEMENTAZIONE JAVA LATO SERVER
ˆ getDriverByVersion(String chromeVersion): il metodo ri-
torna un ResponseEntity<?>, istanzia al suo interno un oggetto
di tipo Optional<File> maybeDriver che prende il suo valore
dal metodo findDriver(String chromeVersion). Dopodichè
viene fatto un controllo in cui si verifica se il file driver è esistente, se
la risposta è affermativa si procede con il return che manderà tramite
il controller lo stream al client. Il return contiene tutte le informazioni
per la risposta https, quindi:
– ResponseEntity.ok() per mandare il codice di 200-OK al
client;
– ResponseEntity.header() con gli header per la risposta;
– ResponseEntity.contentLength (driver.length()) in
cui viene passata la lunghezza del driver;
– ResponseEntity.contentType (MediaType.APPLICATION
OCTET STREAM) in cui viene indicato il tipo dicontenuto della
risposta;
– ResponseEntity.body(new InputStreamResources(new
FileInputStream(driver)) il driver.
In alternativa se durante il controllo il driver non è stato trovato, verrà
inviato un return con status code NOT FOUND, ovvero codice 404 con
seguente messaggio: "Required Chrome driver file for version
%s not found", con %s indicato dal chromeVersion, che verrà mandato
tramite il controller al client.
ˆ md5DriverResponse(File chromeDriver): ritorna una stringa,
svolge un try/catch in cui nel try istanzia due oggetti final di tipo
byte[], il primo oggetto chiamato semplicemente ”b” legge i bytes del
File chromedriver passatogli, mentre il secondo oggetto di tipo byte
denominato ”digest” svolge lo hash vero e proprio del chromedriver.
Se l’operazione va a buon fine viene fatto un return all’interno del try,
il return è un DatatypeConverter.printHexBinary(digest).
Se l’operazione non va a buon fine nel catch viene fatto il throw di
un’eccezione del tipo FileNotFoundException() e viene salvato
nel log del server l’errore che è avvenuto;
ˆ getHash(String chromeVersion); ritorna una risposta Respon
seEntity(String), fa un controllo come nel metodo getDriverBy
Version, in cui verifica l’esistenza del file passatogli dal metodo find-
Driver(chromeVersion). Se il driver esiste crea una risposta http da
20

22. 4.3. IMPLEMENTAZIONE JAVA LATO SERVER
mandare al client, in cui all’interno del body verrà inserita la stringa
dell’hash effettuato un return ResponseEntity.ok() .body(md5Hash);
dove l’md5Hash è la variabile di tipo stringa contenente il valore dell’hash
effettuato. Se il controllo dell’esistenza del file non va a buon fine, verrà
mandato un codice di errore 404.
Durante lo sviluppo del codice Java si è consultato il libro citato nella
bibliografia [7].
21

23. Capitolo 5
Security
5.1 Forme di attacco
Le forme di attacco al driver possono avvenire in diversi modi, alcuni dei
quali altamente improbabili ma non per questo impossibili. Il driver potrebbe
essere soggetto ad attacchi di tipo MITM (Man In The Middle) se all’avvio
della connessione con l’applicazione Server l’attaccante riesce a istanziare una
connessione con il client. Ciò può avvenire ingannando il client e facendogli
pensare di comunicare con il server, grazie ad una forma di attacco detta
DNS poisoning, con la quale l’attaccante potrebbe reindirizzare le richieste
a se stesso e fingersi il server. Un’altra forma di attacco è riuscire a trovare
la chiave della sessione TLS tra il Client ed il Server. Un’altro metodo di
attacco che si è ipotizzato possa essere più probabile e più efficace per cercare
di corrompere il driver è il TOC to TOU.
5.2 Il TOCTTOU
Una forma di attacco trovata, che potrebbe essere efficiente, è il TOCT-
TOU[8]. L’acronimo sta per Time-of-check To Time-of-use, questo metodo
di attacco viene utilitzzata quando un software fa un check sullo stato di una
risorsa prima di utilizzarla. In questo caso viene fatto il check sull’integrità
del chromedriver confrontando l’hash MD5 del driver ricevuto con quello che
è sul server. Il problema nasce in quanto lo stato del driver può cambiare tra
il momento in cui viene fatto il check e il momento in cui si usa effettivamente
il driver. L’attacco infatti può avvenire in questo spazio di tempo, che anche
se può essere molto breve, può essere sufficiente iniettare un malware e farlo
partire. Nel momento in cui avviene una forma di attacco del genere non c’è
modo di evitarla e molte delle volte può passare inosservata.
22

24. Conlusioni e sviluppi futuri
Con il presente lavoro è stato possibile contribuire alla realizzazione di un
uso più pratico ed esteso di un software enterprise sviluppato dall’azienda. Il
reparto di testing potrà usufruire dell’automazione dei login realizzata, men-
tre in generale non ci saranno più problemi con la compatibilità dei driver. Ci
sarà solo un’operazione che dovrà essere fatta manualmente, ovvero bisognerà
mettere manualmente i driver sul server quando escono. L’automazione per-
metterà agli utenti che usufruiscono del servizio di non perdere più tempo a
contattare supporto per gli aggiornamenti, ma avranno già una funzionalità
integrata nel software e2e che automaticamente svolgerà gli aggiornamenti
del driver. In genere possono avvenire forme di attacco al software solo se
l’attaccante ha grandi conoscenze sul funzionamento del programma. Uno
sviluppo futuro che possa far evolvere il codice è la scelta di un hash più ro-
busto dello hash MD5, come lo SHA256[4]. Un’altra soluzione che potrebbe
essere ottima da adottare per evitare forme di attacco TOC to TOU è di cari-
care il driver aggiornato direttamente sulla memoria RAM. Questa soluzione
fa in modo che quando viene avviato il check, anche se il driver viene utiliz-
zato in un momento successivo, viene già caricato nella memoria e non può
venir modificato (in realtà può venir modificato in tutti i casi, anche nel caso
venga caricato nella memoria, ma è molto più complesso che uno scenario
del genere possa avvenire). Un’altra soluzione, la migliore, che può essere
adottata per escludere qualsiasi forma di attacco è l’uso della firma digitale.
Personalmente mi ritengo soddisfatto del lavoro svolto, ho sentito una crescita
dal punto di vista delle conoscenze sui temi affrontati e l’aver contribuito
seppur in minima parte ad un progetto in azienda mi ha dato ancora più
ispirazione e voglia di crescere in questo settore.
23

25. Appendice
24

26. Codice implementato
a Esempio procedura citrix-ssh
procedures:
- address: 10.130.23.201
authentication: CDSQM
config:
ipAddress: 10.130.23.201
port: "22"
windowNameApp: PuTTY Configuration
env: citrix-ssh
networkuseraccess: false
protocol: citrix-ssh
target: CDSQM1
b Chromedriver update: lato client
b.1 Classe ChromeDriverControl.py
import hashlib
import os
import winreg
import shutil
from update import MD5Exception
from update import DriverNotFoundException
from update import UnknownHashException
from requests import Session
from src.Logger import Logger
from credentials.CredentialsRepository import
CredentialsRepository
25

27. B. CHROMEDRIVER UPDATE: LATO CLIENT
from src.absolute_project_path import BASE_DIR
class ChromeDriverControl:
def __init__(self, serverUrl: str, credentials:
CredentialsRepository, http_session: Session,
vfRootHolder,
ldapUrl, driverUrl: str, hashUrl: str,
driverLocation, logger: Logger):
self.serverUrl = serverUrl
self.credentials = credentials
self.http_session = http_session
self.vfRootHolder = vfRootHolder
self.ldapUrl = ldapUrl
self.driverUrl = driverUrl
self.hashUrl = hashUrl
self.driverLocation = driverLocation
self.driverPath = os.path.join(os.path.expanduser
("˜"),
self.driverLocation)
self.logger = logger
if not os.path.exists(self.driverPath):
self.driverPath = os.path.join(BASE_DIR,
"resources", "chromedriver.exe")
self.chrome_key_path =
winreg.OpenKey(winreg.HKEY_CURRENT_USER, "SOFTWARE
GoogleChromeBLBeacon")
command = winreg.QueryValueEx(self.chrome_key_path,
"version")
self.chr_version = command[0]
def driverVersion(self):
self.selenium_version = self.driver.capabilities[’
chrome’
[’chromedriverVersion’].split(’ ’)[0]
return self.selenium_version
def chromeVersion(self):
if self.chrome_key_path:
return self.chr_version
def control(self):
self.logger.info(f"Selenium version{self.
26

28. B. CHROMEDRIVER UPDATE: LATO CLIENT
driverVersion()}:Chrome version {self.
chromeVersion()}")
if not os.path.exists(self.driverPath) or self.
chromeVersion().rsplit(’.’, 3)[0] != self.
driverVersion().rsplit(’.’, 3)[0]:
return False
else:
return True
def hash(self):
localHash = hashlib.md5(open(self.driverPath, ’rb’).
read()).hexdigest().replace("’", "")
return localHash
def checkDriver(self):
creds = self.credentials.get(’vf-root’)
if self.fakeAuthEnabled:
creds = self.credentials.get(’fake-root’)
if not self.control():
versionResponse = self.http_session.get(self.
driverUrl + self.chromeVersion().rsplit(’.’, 3)
[0])
if ’/login’ in versionResponse.url:
self.vfRootHolder.login(self.ldapUrl, creds)
with self.http_session.get(self.driverUrl + self.
chromeVersion().rsplit(’.’, 3)[0], stream=True)
as versionResponse:
with open(self.driverPath, ’wb’) as fileDriver:
shutil.copyfileobj(versionResponse.raw,
fileDriver)
if versionResponse.status_code == 404:
raise DriverNotFoundException(versionResponse.
content)
self.logger.info(f"Driver updated")
def checkHash(self):
creds = self.credentials.get(’vf-root’)
if self.fakeAuthEnabled:
creds = self.credentials.get(’fake-root’)
hashResponse = self.http_session.get(self.hashUrl +
self.chromeVersion().rsplit(’.’, 3)[0])
if ’/login’ in hashResponse.url:
self.vfRootHolder.login(self.ldapUrl, creds)
27

29. B. CHROMEDRIVER UPDATE: LATO CLIENT
hashResponse = self.http_session.get(self.hashUrl +
self.chromeVersion().rsplit(’.’, 3)[0])
serverHash = str(hashResponse.content).replace("’",
"")
serverHash = serverHash.replace("b", "")
if hashResponse.status_code == 405:
raise UnknownHashException(hashResponse.content)
if self.hash() != serverHash.lower():
raise MD5Exception(hashResponse.content)
self.logger.debug(f"Driver’s MD5 intact")
b.2 Classe App.py modifiche aggiunte
self.driverLocation = self.config.get(’sesamo-server’).get
(’driverPath’)
self.browser = Browser(self.driverLocation, True)
self.asIe11Browser = ChromeAsIe11Browser(self.
driverLocation, True)
self.driverCheck = ChromeDriverControl(
self.config.get(’sesamo-server’).get(’targetsUrl’)
,
self.credentials,
self.http_session,
self.vfRootHolder,
self.config.get(’sesamo-server’).get(’ldapUrl’),
self.config.get(’sesamo-server’).get(’
fakeAuthEnabled’),
self.config.get(’sesamo-server’).get(’driverUrl’),
self.config.get(’sesamo-server’).get(’hashUrl’),
self.driverLocation,
logger
)
In ogni procedura che richiamava un login su siti web si è aggiunto:
if self.driverCheck.checkDriver():
self.browser.driver.quit()
self.browser._initializeIfNecessary()
self.driverCheck.checkHash()
28

30. B. CHROMEDRIVER UPDATE: LATO CLIENT
b.3 Eccezioni
class DriverNotFoundException(Exception):
def __init__(self, message="Driver_not_found"):
self.message = message
super().__init__(self.message)
class MD5Exception(Exception):
def __init__(self, message="MD5s_driver_corrupted"):
self.message = message
super().__init__(self.message)
class UnknownHashException(Exception):
def __init__(self, message="Unknown_hash_method"):
self.message = message
super().__init__(self.message)
b.4 Il default.yaml
driverUrl: "https://faf.vodafone.it/api/sesamo/driver/"
hashUrl: "https://faf.vodafone.it/api/sesamo/hash/"
driverPath: AppDataYoroiSesamochromedriver.exe
29

31. C. CHROMEDRIVER UPDATE: LATO SERVER
c Chromedriver update: lato server
c.1 Il controller
package it.cybaze.sesamoserver.update;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.security.NoSuchAlgorithmException;
import org.springframework.stereotype.Controller;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable
;
import org.springframework.web.bind.annotation.ResponseBody
;
@Controller
public class ReceiveVersionController {
public final ReceiveVersionFacade receiveVersionFacade;
public ReceiveVersionController(ReceiveVersionFacade
receiveVersionFacade) {
this.receiveVersionFacade = receiveVersionFacade;
}
@GetMapping(value = "/api/sesamo/driver/{
seleniumDriverVersion}")
@ResponseBody
public ResponseEntity<?> streamFile(@PathVariable String
seleniumDriverVersion) throws FileNotFoundException{
return receiveVersionFacade.getDriverByVersion(
seleniumDriverVersion);
}
@GetMapping(value = "/api/sesamo/hash/{
seleniumDriverVersion}")
@ResponseBody
public ResponseEntity<String> getHash(@PathVariable
String seleniumDriverVersion) throws IOException,
FileNotFoundException {
30

32. C. CHROMEDRIVER UPDATE: LATO SERVER
return receiveVersionFacade.getHash(
seleniumDriverVersion);
}
}
c.2 Il bean
package it.cybaze.sesamoserver.update;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration
;
@Configuration
public class ReceiveVersionConfiguration {
@Bean
public ReceiveVersionFacade receiveVF() {
return new DefaultReceiveVersionFacade();
}
}
c.3 L’interfaccia
package it.cybaze.sesamoserver.update;
import java.io.FileNotFoundException;
import org.springframework.http.ResponseEntity;
public interface ReceiveVersionFacade {
ResponseEntity<?> getDriverByVersion(String version)
throws FileNotFoundException;
ResponseEntity<String> getHash(String version) throws
FileNotFoundException;
}
31

33. C. CHROMEDRIVER UPDATE: LATO SERVER
c.4 Il Default Façade
package it.cybaze.sesamoserver.update;
import java.io.*;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Optional;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.xml.bind.DatatypeConverter;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.core.io.InputStreamResource;
import org.springframework.core.io.Resource;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.http.ResponseEntity;
public class DefaultReceiveVersionFacade implements
ReceiveVersionFacade {
@Value("${chrome.drivers.folder}")
private String chromeDriversFolder;
@Override
public ResponseEntity<?> getDriverByVersion(String
chromeVersion) throws FileNotFoundException {
final Optional<File> maybeDriver = findDriver(
chromeVersion);
if (maybeDriver.isPresent()) {
final File driver = maybeDriver.get();
final HttpHeaders headers = new HttpHeaders();
headers.add(HttpHeaders.CONTENT_DISPOSITION, "
attachment; filename=chromedriver.exe");
return ResponseEntity.ok()
.headers(headers)
.contentLength(driver.length())
.contentType(MediaType.
APPLICATION_OCTET_STREAM)
32

34. C. CHROMEDRIVER UPDATE: LATO SERVER
.body(new InputStreamResource(new
FileInputStream(driver)));
}
return ResponseEntity.status(HttpStatus.NOT_FOUND).
body(String.format("Required Chrome driver file
for version %s not found", chromeVersion));
}
@Override
public ResponseEntity<String> getHash(String
chromeVersion) throws FileNotFoundException {
try {
final Optional<File> maybeDriver = findDriver(
chromeVersion);
if (maybeDriver.isPresent()) {
final File driver = maybeDriver.get();
final String md5Hash = md5DriverResponse(driver
);
return ResponseEntity.ok()
.body(md5Hash);
}
return ResponseEntity.status(HttpStatus.NOT_FOUND)
.body(String.format("Required Chrome driver
file for version %s not found", chromeVersion))
;
} catch (NoSuchAlgorithmException ex) {
return ResponseEntity.status(HttpStatus.
METHOD_NOT_ALLOWED).body("Unknown hash method")
;
}
}
private Optional<File> findDriver(String chromeVersion)
{
final File driver = new File(String.format("%s/%s/
chromedriver.exe", chromeDriversFolder,
chromeVersion));
if (driver.exists()) {
return Optional.of(driver);
}
return Optional.empty();
}
33

35. C. CHROMEDRIVER UPDATE: LATO SERVER
private String md5DriverResponse(File chromeDriver)
throws FileNotFoundException,
NoSuchAlgorithmException {
try {
final byte[] b = Files.readAllBytes(Paths.get(
chromeDriver.getAbsolutePath()));
final byte[] digest = MessageDigest.getInstance("
MD5").digest(b);
return DatatypeConverter.printHexBinary(digest);
} catch (IOException ex) {
Logger.getLogger(DefaultReceiveVersionFacade.class
.getName()).log(Level.SEVERE, null, ex);
throw new FileNotFoundException();
}
}
}
}
}
}
34

36. Bibliografia
[1] Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra. ”Head First
Design Pattern”, O’Reilly Media, Inc. 2nd edition, 2004.
[2] ”SSO”, ”https://web.archive.org/web/20090225231552/http://www.openaselect.org/trac/open
[3] ”Selenium”, ”https://vitolavecchia.altervista.org/che-cose-e-come-
funziona-selenium-per-lautomazione-dei-test/”
[4] MD5 vs SHA256: Which is Better?. ”https://infosecscout.com/md5-
vs-sha256/#: :text=is%20100%25%20safe.-
,MD5%20vs%20SHA%2D256%3A%20Which%20is%20better%3F,a%20bit%20better%20than%
[5] ”Spring Boot”, ”https://spring.io/projects/spring-boot/
[6] Bonaventura Di Bello. ”Programmare con Python for dummies”, Ulrico
Hoepli Editore S.p.A., 2020
[7] Giuseppe Maggi. ”Programmare con Java Guida completa”, Edizioni
LSWR*, 2020
[8] Wei, Jinpeng; Pu, Calton. ”TOCTTOU Vulnerabilities in UNIX-Style
File Systems: An Anatomical Study”. USENIX.
35

37. Ringraziamenti
Vorrei dedicare questo spazio a chi, con dedizione e pazienza, ha contribuito
alla realizzazione di questo elaborato.
Voglio ringraziare la mia famiglia, che mi ha sempre incoraggiato a resistere
e non mollare durante la carriera universitaria, nonostante tutte le difficoltà
incontrate nel percorso.
Ringrazio i miei amici e compagni di studio in questi anni, che mi hanno
dato sempre un forte sostegno e siamo riusciti a spingerci avanti esame dopo
esame.
Ringrazio il mio relatore, il Prof. Alberto Bartoli, grazie a Lei ho migliorato le
mie conoscenze e le mie competenze. Un sentito ringraziamento infine al mio
correlatore di YOROI, il Phd. Ing. Marco D’Orlando che ha saputo guidarmi,
con suggerimenti pratici, nelle ricerche e nella stesura dell’elaborato. Grazie
a voi ho migliorato le mie conoscenze e le mie competenze.
36