Analisi delle dipendenze architetturali dei servizi di autenticazione SPID

Analisi delle dipendenze architetturali
dei servizi di autenticazione SPID
Tesi di laurea in Ingegneria Elettronica ed Informatica
Candidato: Simonini Leonardo
Relatore: Bartoli Alberto
Dipartimento di Ingegneria e Architettura
Università degli studi di Trieste
Anno accademico 2020/2021

Introduzione 3
Capitolo 1 Gli Strumenti 4
Capitolo 2 Moduli Sviluppati 5
Capitolo 3 Configurazione 7
Capitolo 4 Utilizzo 8
Sezione 1 - Classe DomainDependence 9
Sezione 2 - Classe dbAnalyser 12
Sezione 3 - Procedura per l’analisi della tesi 17
Capitolo 5 Database 18
Capitolo 6 Analisi 22
Sezione 1- Insieme di siti considerati 22
Sezione 2 - Dati e analisi per la name resolution 23
Sezione 3 - Dati e analisi per il web access 27
Sezione 4 - Dati e analisi per gli script 30
Sezione 5 - Riepilogo analisi 36
Capitolo 7 Analisi dei siti dello SPID 37
Sezione 1- Insieme di IdP considerati 37
Sezione 2 - Dati e analisi per la name resolution 37
Sezione 3 - Dati e analisi per il web access 39
Sezione 4 - Dati e analisi per gli script 41
Sezione 5 - Riepilogo analisi 45
Conclusione 46
2

Introduzione
Il fatto che un server possa archiviare le informazioni dei suoi utenti e che
questo sia accessibile tramite Internet fa sì che possano esserci tentativi di attacchi
informatici con diversi fini. Gli attacchi possono rendere il servizio web inutilizzabile,
possono ridirezionare l’utente su un sito fraudolento, o possono perfino permettere
all’attaccante di impersonare un utente. I siti web, inoltre, spesso fanno uso di script
che possono essere scaricati da differenti server connessi ad Internet. È importante,
quindi, sottolineare che poiché una pagina web offre un servizio grazie alla
collaborazione di terzi, allora è possibile per un attaccante fare danni al servizio, o
agli utenti del servizio, sfruttando queste terze parti. In questo modo è possibile
portare a termine un attacco in modo che il servizio web di cui l’utente fa uso sia
inconsapevole. Diversi attacchi informatici possono essere eseguiti sfruttando
differenti vulnerabilità se gli incentivi e le risorse a disposizione dell'attaccante glielo
permettono.
Il servizio online che viene preso in considerazione in questa tesi è il servizio
di verifica dell'identità digitale in Italia, ovvero lo SPID, acronimo per Sistema
Pubblico di identità Digitale. Questo tipo di servizio permette di accreditare l’utente
su diverse piattaforme online perciò è di particolare importanza per chi ne
usufruisce. In particolare agli SPID è affidata una grande responsabilità poiché
l’autenticazione tramite questo servizio ha una validità legale che permette
all’amministrazione pubblica di identificare i suoi utenti. Un qualsiasi attacco a servizi
di questo genere significherebbe fermare, o per lo meno rallentare, un servizio dello
stato, nel caso peggiore l’attaccante potrebbe fare le veci di un utente e eseguire
operazioni legalmente riconosciute dallo Stato italiano.
Questa tesi si pone lo scopo di analizzare le dipendenze architetturali e
software dei siti SPID. Con l’analisi si è voluto evidenziare se ci siano elementi
nell’architettura delle reti che permettano ad un eventuale attaccante di impedire
l’accesso al servizio dei siti SPID o di prenderne il controllo. L’analisi si è basata su
tre gruppi di dati raccolti. Per primo sono state trovate le zone dirette in cui si trovano
i siti analizzati. Con zona diretta si intende il nome di zona DNS in cui si trova un
dominio, in pratica il più vicino sotto dominio che è un nome di zona. Poi sono stati
trovati i nameserver, le network dove si trovano i nameserver e gli autonomous
system che gestiscono queste network. In secondo luogo sono state trovate le
repliche del sito su diversi indirizzi IP, in quali network si trovano e da quali
autonomous system sono gestite queste network. Infine, le stesse informazioni dei
due gruppi precedenti sono state trovate per i server da cui vengono scaricati degli
script. Degli script sono stati considerati quelli che venivano scaricati da server che
non fossero lo stesso da cui proveniva la pagina web, e di questi quelli che non si
trovassero dentro un tag IFRAME. Questo perché questi script sono scritti da terzi e
possono eseguire codice nel browser dell’utente. Perciò, se non c’è modo di
verificare l’autenticità di questi script, un attaccante potrebbe essere in grado di far
3

scaricare un proprio script fraudolento dalle pagine web del servizio che usa l’utente.
L’analisi è stata fatta in due fasi: una prima fase in cui sono stati analizzati dei siti di
riferimento in maniera tale da avere una base per confrontare l’analisi svolta sui siti
SPID, e una seconda fase riguardante l’analisi dei siti SPID stessi. Del primo gruppo
sono stati presi in esame anche gli IdP della Spagna e del Regno Unito. IdP è
l’acronimo di Identity Provider, sistemi che creano, mantengono e gestiscono le
informazioni sull’identità degli utenti e offrono a questi ultimi la possibilità di
autenticarsi per altri servizi.
Nel’analisi sono stati evidenziate le somiglianze e le differenze tra i due gruppi
di siti presi in esame e non sono stati dati pareri o giudizi di alcun genere
sull’effettivo grado di sicurezza dei siti analizzati.
L’analisi ha fatto emergere, basandosi sui siti campione analizzati, come non
ci sia un modo di organizzare le architetture delle reti uguale per tutti. Sono emerse
però delle pratiche discutibili, una di queste è la mancata verifica dell’integrità degli
script scaricati dalle pagine web.
Capitolo 1 Gli Strumenti
Prima di iniziare lo studio è stato preso in considerazione uno strumento:
Maltego. Maltego è un software a pagamento per la raccolta di dati, per il data
mining e per l’analisi forense. Esiste una versione gratuita del software che è stata
usata per valutare lo strumento. L’utente del software deve avviare una ricerca ed
aspettare i risultati, ovvero le dipendenze tra diversi tipi di entità, che vengono
presentati in forma di grafico. Nella versione gratuita le entità da cui ne dipende
un’altra sono visualizzate in numero limitato. In più, Maltego non permetteva di
ottenere tutte le informazioni di interesse per l’analisi da svolgere in questa tesi
(queste informazioni sono elencate al capitolo 4, sezione 1). Per questo motivo
questo strumento non è poi stato preso in considerazione per il lavoro.
L’alternativa a Maltego è stata scrivere un software che permettesse di
trovare le dipendenze architetturali dato un dominio web. Il software sviluppato nel
corso di questa tesi è stato scritto in linguaggio Python. Python è un linguaggio che
permette di creare facilmente pacchetti che possono essere pubblicati e utilizzati da
altri sviluppatori. Questa modularità di Python permette anche, al contrario, di
sfruttare pacchetti già esistenti scritti da altri sviluppatori. Per questo motivo è stato
scelto questo linguaggio per la scrittura del software.
A differenza di Maltego che è un software già esistente, con Python è stato
necessario scrivere le classi che sono state utilizzate per estrarre i dati riguardanti
l’architettura delle reti che ospitano i server dei siti SPID e gli script che sono
scaricati dalle pagine web analizzate. In questo modo è stato possibile definire e
raccogliere in maniera puntuale e specifica le informazioni di interesse per l’analisi
effettuata in questa tesi.
4

Per la scrittura delle classi Python è stato fatto uso, nello specifico, dei
seguenti pacchetti scritti da terzi: dnspython, un pacchetto che permette di eseguire
query dns, selenium e requests, che permettono di accedere alle informazioni delle
richieste e risposte di un headless browser.
Per la scrittura del codice e il debugging è stato sfruttato il software di
JetBrains chiamato Pycharm. I dati raccolti sono stati salvati in un database su file
.sqlite che è stato possibile esplorare tramite un altro software di JetBrains chiamato
DataGrip.
Un ultimo strumento di cui è stato fatto uso è una repository di github su cui
sono stati caricate le classi in python che sono state scritte per la raccolta dati.
Questo strumento è stato scelto perché permette di condividere facilmente il codice
e permette agli utenti di contribuire ad esso commentandolo o correggendolo.
Capitolo 2 Moduli Sviluppati
Per quanto riguarda l’implementazione del codice in Python sono state scritte
diverse classi e metodi in maniera modulare, per fare in modo di rendere più facile la
modifica di singoli elementi senza dover cambiare la struttura completa delle diverse
classi. Il codice delle classi che sono state scritte può essere scaricato dalla
repository github: https://github.com/LeonardoSimonini/ThesisWork.
Vengono presentate brevemente le classi e i metodi principali al fine di
rendere più chiara la lettura del codice. Nel prossimo capitolo verrà poi discussa la
configurazione da fare da parte dell’utente per poter eseguire il codice di queste
classi.
La classe RRecord è una classe che ha l’obiettivo di rappresentare un
resource record. Un oggetto di questa classe ha infatti tre attributi: name, type e
values, che rispecchiano i valori di un resource record dns. Questa classe fa uso del
pacchetto dnspython a cui si è accennato al capitolo precedente.
La classe Resolver ha due metodi principali, il metodo findIPandCNAME e
findDNSInfo. Il primo dei due ricerca, dato un dominio in ingresso, i dns record di tipo
A di questo dominio ed eventualmente la catena di record di tipo CNAME che è stata
seguita per la risoluzione della query di tipo A. Il secondo ricerca invece le zone da
cui dipende il dominio in ingresso ed i nameserver di tali zone, facendo richieste
DNS di tipo NS. Se i sottodomini di un dominio sono nomi di zona allora si intende
che il dominio iniziale dipende da queste zone; se i nameserver di queste zone si
trovano in altre zone allora si intende che il dominio dipende anche da queste zone e
dai sottodomini di queste zone che sono a loro volta zone. Il discorso è replicato per
i nameserver di queste ultime zone.
5

Il costruttore di questa classe può prendere in ingresso un file .csv che possa
essere utilizzato come cache quando vengono risolti i nomi dns nei metodi di questa
classe. Questo file per ogni riga deve avere i valori di un resource record scritti nella
seguente sequenza: nome, tipo, valore. Se il resource record ha più valori allora
questi devono essere inseriti separati da virgole. Il terzo parametro può anche
assumere il valore “NXDomain” o “NoAnswer”, rispettivamente nel caso in cui il
dominio non esista oppure non sia del tipo specificato nella richiesta.
La classe NetNumberResolver ha un metodo resolver che permette, dato un
indirizzo IP, di trovare a quale range di indirizzi appartiene e quale autonomous
system gestisce tale range. Per farlo è necessario il database con queste
informazioni, come trovarlo e scaricarlo è discusso nel prossimo capitolo.
La classe LandingSite ha solo un costruttore che, dato un dominio web, ha il
compito di trovare il nome del sito web a cui si arriva dopo che sono state seguite le
eventuali redirezioni HTTP. L’implementazione della classe usa il pacchetto Python
requests. Se il sito a cui si arriva dopo le redirezioni HTTP non è trovato a causa di
un errore, per esempio un timeout, viene invece usato il pacchetto urllib3, facente
parte della Python Standard Library.
La classe ScriptOriginScraper ha un metodo getScriptOrigin che prende in
ingresso un URL (acronimo per Uniform Resource Locator) e, facendo uso del
pacchetto seleniumwire, tramite un headless browser, torna una lista di tuple
contenente: le origini degli script della pagina web caricata con l’URL passato come
argomento, un booleano che indica se lo script ha l’attributo integrity e un booleano
che indica se lo script si trova dentro un IFRAME. Questo metodo sfrutta Firefox
come headless browser, la configurazione più dettagliata è discussa nel prossimo
capitolo.
La classe ROVScraper ha un metodo loadASPage che apre un headless
browser per trovare quali network gestite dall’autonomous system passato in
ingresso fanno uso del sistema di difesa ROA (Route Origin Authorization) per il loro
BGP, acronimo per Border Gateway Protocol. Il metodo apre una connessione al sito
stats.labs.apnic.net in cui le informazioni riguardo alle network gestite dagli
autonomous system sono aggiornate costantemente.
Infine, la classe DomainDependence ha un metodo
multipleDomainDependencies che richiama le altre classi in maniera da trovare le
dipendenze dei domini passati in ingresso. Questo metodo fa uso del pacchetto
sqlite3 per generare un file .sqlite in cui salvare le informazioni trovate. Come è
strutturato questo file è discusso al capitolo 5 sul database.
6

Capitolo 3 Configurazione
Per usare il codice è necessario per l’utente eseguire qualche passaggio
prima di poter cominciare ad usare le classi implementate.
Innanzitutto è necessario che venga scaricato Python, per farlo basta
accedere al sito: https://www.python.org/downloads/, e scaricare la versione più
recente in base al proprio sistema operativo. In seguito basta seguire le istruzioni per
l’installazione che vengono fornite avviando l’eseguibile scaricato.
Il codice scritto fa uso dei pacchetti selenium, seleniumwire, dnspython e
requests che vanno scaricati, non facendo parte della Python Standard Library. Per
farlo, una volta che python è stato installato, basta aprire il terminale da pc ed
eseguire uno dopo l’altro i seguenti comandi:
pip install selenium
pip install selenium-wire
pip install dnspython
pip install requests
La classe NetNumberResolver necessita delle informazioni di network e
autonomous system, queste informazioni si trovano nel database salvato nel file .tsv
scaricabile dal sito web: https://iptoasn.com/. Questo sito viene aggiornato
periodicamente perciò è consigliabile scaricare nuovamente il file quando passa del
tempo tra un’esecuzione e l’altra del codice. Quando il costruttore o il metodo di una
classe richiede in ingresso il database contenuto nel file .tsv, va inserito il percorso in
cui è salvato il file nel pc. Per sapere quali sono i metodi che lo richiedono si rimanda
alla documentazione del codice, presente nella cartella pydoc_demo della repository
github da cui può essere scaricato anche il codice delle classi:
https://github.com/LeonardoSimonini/ThesisWork
Alcune classi e metodi necessitano di eseguire Firefox come headless
browser, per questo motivo è necessario scaricare da parte dell’utente questo
browser all’URL: https://www.mozilla.org/it/firefox/new/
Appena scaricato l’installer basta eseguirlo e seguire le istruzioni per
installare il browser di Mozilla. Quando un metodo o un costruttore richiede di
inserire il path di firefox va inserito come argomento il percorso del file di firefox (per
Windows di default dovrebbe essere: ‘C:/Program Files/Mozilla Firefox/firefox.exe’).
Per sapere quali sono i metodi e i costruttori che lo richiedono si rimanda alla
documentazione del codice.
Infine, per alcune classi o metodi è necessario scaricare il driver geckodriver.
Per farlo basta scaricare l’eseguibile, adeguato al proprio sistema operativo, che si
trova all’URL: https://github.com/mozilla/geckodriver/releases/tag/v0.29.1
7

Dopo il download bisogna estrarre il file compresso in una cartella a piacere,
poi il percorso al file geckodriver.exe dovrà essere inserito come argomento dei
metodi che richiedono il driver. Per sapere quali sono i metodi e i costruttori che
richiedono il percorso file di geckodriver si rimanda alla documentazione del codice.
Una volta completate tutte le operazioni sopra descritte è possibile eseguire il
file main.py, seguendo le istruzioni all’inizio del file per sapere quali percorsi di file
vanno inseriti dove all’interno del codice.
Capitolo 4 Utilizzo
In questo capitolo viene descritta la sequenza di operazioni eseguite per
raccogliere i dati discussi nei capitoli seguenti, in modo da permettere all’utente di
replicare la procedura.
La procedura prevede in ingresso:
● una lista di domini di cui un utente desidera trovare le dipendenze;
● il nome di un file .sqlite su cui desidera che i risultati vengano salvati; il file
può essere nuovo o può essere già stato usato in precedenza, in questo
secondo caso i dati saranno aggiunti in coda a quelli preesistenti.
● il percorso al file .tsv con le informazioni sulle network gestite dagli
autonomous system, scaricabile da: https://iptoasn.com/;
● il percorso al file eseguibile di geckodriver, scaricabile da:
https://github.com/mozilla/geckodriver/releases/tag/v0.29.1.
● il percorso al file eseguibile del browser Firefox, scaricabile da:
https://www.mozilla.org/it/firefox/new/;
● Opzionalmente l’utente potrà anche preparare un file da usare come cache in
ingresso al metodo multipleDomainDependencies (descritto nella Sezione 1 di
questo capitolo).
Una volta che la procedura è stata portata a termine in uscita ci saranno tre
file:
● il file .sqlite che contiene le informazioni sulle dipendenze trovate;
● un file “NewCache.csv” contenente tutti i resource records che sono stati
trovati durante l’esecuzione della procedura; questo file può essere usato
come ingresso per la classe multipleDomainDependencies in futuri utilizzi di
questa procedura.
● il file “Error.csv” contenente i log di errore che possono essere avvenuti
durante l’esecuzione della procedura. Se nel file “Error.csv” dovessero essere
salvati degli errori, nel log è indicato anche il dominio per cui non è stato
possibile ricavare le informazioni cercate, perciò è possibile richiamare il
metodo con in input solo il dominio che ha causato l’errore.
8

La procedura con cui sono stati estratti i dati per l’analisi è presentata con
maggiore dettaglio nella sezione 3.
Sezione 1 - Classe DomainDependence
Il primo passo della procedura prevede che venga invocato il costruttore della
classe DomainDependence. Il costruttore prende in ingresso il nome di un file .sqlite
che è il nome del file in cui saranno poi salvati i dati estratti. Se il nome del file non è
specificato nell’attributo allora di default il nome è “Results.sqlite”.
Viene riportata la definizione del costruttore:
def DomainDependence(self, dbname = “Results.sqlite”)
Una volta inizializzato un oggetto di questa classe va richiamato il metodo
multipleDomainDependencies che ha la seguente definizione:
def multipleDomainsDependencies(self, domains, csv=None,
path_ip2asn='C:/Users/Example/Desktop/ip2asn-v4.tsv',
path_geckodriver =
'/Users/Example/Desktop/geckodriver',path_firefox =
'C:/Program Files/Mozilla Firefox/firefox.exe')
Il metodo multiplDomainDependencies prende in ingresso cinque argomenti.
● L’argomento domains è una lista di stringhe dove ognuna di esse rappresenta
un dominio.
● L’ingresso csv è il nome di un file in formato csv che contiene una lista di
resource records, uno per ogni riga del file, scritti nella forma: nome, tipo,
sequenza di valori separati dalla virgola.
Un esempio di una lista di due resource records scritti nel file csv da
inserire in ingresso a questo metodo è il seguente:
webDomain, A, 123.123.123.123
zoneName, NS, nameserver.1, nameserver.2, nameserver.3
Questo file viene usato dal metodo come una cache per rendere
l’esecuzione dello stesso più rapida, come descritto al capitolo 2 Moduli
Sviluppati. Il valore di default dell’argomento csv è None, che significa che
non viene usato nessun file come cache.
● L’argomento path_ip2asn è una stringa che rappresenta il percorso file verso
il file contenente i dati delle network e da quali autonomous system sono
gestiti, scaricabile dal sito: https://iptoasn.com/.
9

● Gli argomenti path_geckodriver e path_firefox sono due strighe che
rappresentano il percorso file rispettivamente verso l’eseguibile di geckodriver
e del browser di Firefox.
Per quanto riguarda l’output, il metodo multipleDomainDependencies, non ha
un valore di ritorno, quello che esce è un file .sqlite contenente le informazioni
riguardo alle dipendenze trovate. Il modo con cui sono riportate queste dipendenze è
chiarito al prossimo capitolo sul database. Inoltre, il metodo crea due file, oppure li
sovrascrive se esistono già. Il primo file si chiama “NewCache.csv” che è un file che
contiene i resource records che sono stati trovati durante la ricerca delle dipendenze
DNS, questo file può essere utilizzato come cache in ingresso nell’attributo csv per
una successiva esecuzione del metodo. Il secondo file si chiama “Error.csv” che è un
file che contiene i log degli errori che possono essere capitati durante l’esecuzione
del metodo.
Il metodo multipleDomainsDependencies, ricerca le dipendenze di tutti i
domini della lista di domini in ingresso e salva questi risultati nel file .sqlite passato in
ingresso al costruttore di questa classe. Le dipendenze che vengono cercate sono le
seguenti:
● Dipendenze DNS: Si determina l’insieme di zone e di nameserver da cui
dipende il dominio direttamente o indirettamente. Per fare questo, i domini
sono divisi in sottodomini e se essi sono nomi di zone diciamo che il dominio
di partenza dipende da queste zone. Di queste zone poi sono ricercati i
nameserver e se questi name server si trovano in altre zone, diverse dalle
precedenti, allora sono considerate anch'esse zone da cui dipende il dominio.
Poi i nomi di queste ultime zone vengono divisi in sottodomini e se questi
sottodomini sono nomi di zona, diversi dai precedenti, allora diciamo che il
dominio di partenza dipende anche da queste zone. Questo ragionamento
prosegue allo stesso modo anche con i nameserver di queste ultime zone.
Tutte le zone e i nameserver trovati in questo modo sono considerati le
dipendenze DNS dei domini di partenza.
● Dipendenze di routing: Dei nameserver vengono poi cercati gli indirizzi IP, e
tramite il database scaricato dal sito https://iptoasn.com/ vengono identificate
le network di cui fanno parte gli indirizzi. Sempre dallo stesso database si
identificano gli autonomous system che gestiscono queste network.
● Dipendenze web: dei domini in ingresso vengono cercati i nomi dei siti web a
cui si arriva tramite, eventualmente, una serie di redirection sia nel caso di
accesso al sito tramite HTTP che tramite HTTPS. Vengono poi cercati gli
indirizzi IP del sito, tramite il database scaricato dal sito https://iptoasn.com/
sono individuate le networks di cui fanno parte gli indirizzi e gli autonomous
system che gestiscono queste network. Tutte queste informazioni sono
considerate le dipendenze web dei domini.
10

● Dipendenze software: accedendo al sito web sono ricercati i domini web
d’origine degli script che vengono scaricati dalla pagina web. Di questi script
vengono tenuti tutti e soli quelli che sono scaricati da un dominio web
differente da quello della pagina web di partenza e che facciano parte dello
stesso frame della pagina. Le stesse ricerche fatte per le dipendenze DNS e
web dei domini di partenza vengono fatte anche per i domini web d’origine
degli script. Tutte queste informazioni trovate riguardanti gli script sono
considerate le dipendenze software dei domini di partenza.
Nel caso in cui venga dato in ingresso al metodo
multipleDomainDependencies un dominio di cui erano già state trovate le
dipendenze e che sono salvate nel file .sqlite in uscita, il metodo ricerca nuovamente
le dipendenze ma salva nel file .sqlite solo quelle che non sono già presenti.
Il metodo multipleDomainDependencies trova le dipendenze DNS e di routing
facendo uso della classe Resolver che a sua volta sfrutta il pacchetto dnspython. Il
metodo fa uso poi della classe NetNumberResolver per ricercare le network in cui si
trovano gli indirizzi IP dal database scaricato da https://iptoasn.com/.
Per le dipendenze web questo metodo fa uso della classe LandingSite per
trovare il dominio web a cui si arriva tramite le eventuali redirection HTTP quando si
accede al sito web. Poi sfrutta la classe Resolver per trovare gli indirizzi IP del sito e
la classe NetNumberResolver per trovare le network in cui si trovano gli indirizzi IP
del sito e gli autonomous system che gestiscono queste network.
Per le dipendenze software, invece, viene sfruttata da questo metodo la
classe ScriptOriginScrape. Poi, una volta trovati i domini da cui sono scaricati gli
script, vengono cercate le dipendenze DNS e di routing anche per questi domini.
Una volta conclusa l’esecuzione del metodo multipleDomainDependencies
l’uso tipico da parte dell’utente prevede che questo richiami il metodo
lookForVerifiedRange sullo stesso oggetto della classe DomainDependence. Questo
è ciò che è stato fatto anche per la raccolta dei dati per questa tesi.
Il metodo lookForVerifiedRange è definito come segue:
def lookForVerifiedRange(self, dPath=
'/Users/leona/Desktop/TesiMagistrale/PythonProject/MyPackages/
geckodriver' , fPath= 'C:/Program Files/Mozilla
Firefox/firefox.exe'):
Gli argomenti dPath ed fPath sono rispettivamente i percorsi al file del driver
geckodriver e al file eseguibile del browser Firefox.
Questo metodo non torna nessun valore, aggiorna però il file .sqlite passato in
ingresso al costruttore della classe DomainDependence, aggiungendo le
informazioni riguardanti quali network supportano la verifica tramite ROA.
11

Infatti, questo metodo ricerca per quali network, nel database presente come
attributo dell’oggetto della classe DomainDependence, può essere verificata
l’appartenenza all’autonomous system che le gestisce. Questo può essere fatto
grazie alla presenza delle asserzioni di Route Origin Authorization (ROA). Per fare
questa ricerca il metodo lookForVerifiedRange fa uso della classe ROVScraper.
Il metodo lookForVerifiedRange non viene richiamato dal metodo
multipleDomainDependencies poiché l’esecuzione del primo risulta essere lenta.
Invece, in questo modo l’utente è in grado di richiamare il metodo
lookForVerifiedRange in un secondo momento. Questo permette all’utente di avere
già i dati sulle dipendenze trovati dal metodo multipleDomainDependencies a
disposizione per una prima elaborazione.
Sezione 2 - Classe dbAnalyser
L’uso tipico del software prevede che vengano poi richiamati una serie di
metodi della classe dbAnalyser che eseguono delle query nel database che si trova
nel file .sqlite passato come argomento al costruttore della classe
DomainDependence e poi elabora il risultato di queste query. Questa classe è stata
implementata per facilitare l’utente nella visualizzazione dei risultati.
Il costruttore è il seguente:
def dbAnalyser(self, dbName)
L’argomento dbName deve essere una stringa e corrispondere al nome del
file .sqlite su cui l’utente desidera eseguire le query.
La sequenza di metodi richiamati per l’analisi dei dati è la seguente:
nameResolutionDirectZoneProperties, sameZoneDependence,
sameNetworkandASDependence, HTTPSecureAnalysis,
webAccessPathRedundancyProperties, sameNetworkandASgivenIPs.
Il metodo nameResolutionDirectZoneProperties è definito come segue:
def nameResolutionDirectZoneProperties(self, startList, csv =
"architecturalProperties.csv")
Questo metodo prende in ingresso l’argomento startList che deve essere una
lista di stringhe che rappresentino il nome di un host, e csv che deve essere una
stringa che rappresenti il nome del file .csv su cui si desidera che venga salvato il
risultato di questo metodo, il valore di default è “architecturalProperties.csv”.
L’uscita di questo metodo è una tabella che viene salvata nel file .csv passato
in ingresso. La tabella contiene una riga per ogni elemento dell’argomento startList.
Per ogni riga è presente il nome della zona diretta in cui si trova il nome dell’host a
cui corrisponde la riga, il numero di nameserver presenti in tale zona, il numero di
network diverse in cui si trovano i nameserver ed il numero di autonomous system
12

che gestiscono queste network, e, infine, il numero di diversi country_code di cui
fanno parte gli autonomous system. I country_code sono i medesimi del database
contenente le informazioni sulle network e autonomous system, scaricabile da:
https://iptoasn.com/.
Un esempio di tabella è il seguente:
DirectZone #nameservers #networks #AS #AS_countries
example.zone.1 6 2 1 1
example.zone.2 3 2 2 2
Il metodo sameZoneDependence è definito nel seguente modo:
def sameZoneDependence(self, startList, csv =
"zoneDependence.csv")
L’argomento startList deve essere una lista di stringhe che rappresentino il
nome di un host mentre csv deve essere una stringa che rappresenti il nome del file
.csv su cui si desidera che venga salvato il risultato di questo metodo, il valore di
default è “zoneDependence.csv”.
L’output di questo metodo è un file .csv contenente una tabella descritta come
segue. Per ogni riga della tabella si ha il nome di una zona e il numero di quanti
host, di quelli passati in ingresso, dipendono direttamente da questa zona.
Zones HowManyDependsOnIt
example.com. 1
com. 2
Il metodo sameNetworkandASDependence è definito come segue:
def sameNetworkandASDependence(self, domainList,
csv="networkAndASDependencies.csv")
L’argomento domainList deve essere una lista di stringhe che rappresentino il
nome di una zona mentre csv deve essere una stringa che rappresenti il nome del
file .csv su cui si desidera che venga salvato il risultato di questo metodo, il valore di
default è “networkAndASDependencies.csv”.
Questo metodo ritorna un file .csv con due tabelle, una sotto l’altra. La prima
tabella indica per ogni riga il network number delle network in cui sono distribuiti i
13

nameserver delle zone passate in ingresso e a fianco il numero di zone passate in
ingresso che hanno almeno un nameserver che si trovi nella network alla stessa
riga.
La seconda tabella indica per ogni riga il codice identificativo di un
autonomous system e, per ognuno di essi, il numero di zone passate in ingresso che
hanno almeno un nameserver in una network gestita da tale autonomous system.
Network HowManyDependsOnIt
205.251.192.0/24 1
216.239.32.0/22 2
AS HowManyDependsOnIt
AS16509 1
AS15169 2
Il metodo HTTPSecureAnalysis è definito nel modo seguente:
def HTTPSecureAnalysis(self, startList, csv =
"HTTPSecureAnalysis.csv")
nome di un web host mentre csv deve essere una stringa che rappresenti il nome
del file .csv su cui si desidera che venga salvato il risultato di questo metodo, il
valore di default è “HTTPSecureAnalysis.csv”.
Questo metodo ritorna un file .csv con una tabella con una sola riga. Nella
riga sono indicate le percentuali di host passati in ingresso che si trovano in una
delle categorie di sicurezza dei siti web presenti in tabella 4.1.
Categoria Descrizione
secure+almost un web host appartiene a questa
categoria se è accessibile tramite
HTTPS o tramite HTTP ma con una
redirection su HTTPS ed implementa
come forma di protezione l’HSTS policy
14

https strip un web host appartiene a questa
HTTPS o tramite HTTP ma con una
redirection su HTTP ma non
implementa come forma di protezione
l’HSTS policy
no redirect un web host appartiene a questa
HTTPS e HTTP ma le connessioni
tramite HTTP non sono ridirezionate su
HTTPS
http only un web host appartiene a questa
categoria se è accessibile solo tramite
HTTP
Tabella 4.1 Categorie di sicurezza in cui sono suddivisi i siti web
Un esempio di questa tabella è il seguente:
http_only no_redirect https_strip secure+almost
0 60 20 20
Il metodo webAccessPathRedundancyProperties è definito in questo modo:
def webAccessPathRedundancyProperties(self, startList, csv =
"redundancyWebAccessPathProperties.csv")
valore di default è “redundancyWebAccessPathProperties.csv”.
Questo metodo ritorna un file .csv con una tabella. Per ogni riga di questa
tabella è indicato uno dei nomi di host passati in ingresso, il numero di repliche di
indirizzi IP dell’host, il numero di diverse network in cui si trovano gli indirizzi IP, il
numero di diversi autonomous system che gestiscono tali network, e il numero di
diversi country_code di cui fanno parte gli autonomous system. I country_code sono
i medesimi del database contenente le informazioni sulle network e autonomous
system, scaricabile da:https://iptoasn.com/.
Un esempio di questa tabella è il seguente:
15

Host #IP #networks #AS #AS_countries
host.example.1 3 2 1 1
host.example.2 8 2 1 1
Il metodo sameNetworkandASgivenIPs è definito come segue:
def sameNetworkandASgivenIPs(self, hostList, csv =
"networkAndASgivenIPs.csv"):
L’argomento hostList deve essere una lista di stringhe che rappresentino il
valore di default è “networkAndASgivenIPs.csv”.
Questo metodo ritorna nel file .csv due tabelle, una sotto l’altra. La prima
tabella indica per ogni riga il network number delle network in cui sono distribuiti gli
indirizzi IP degli host passati in ingresso con il numero di host che hanno almeno un
indirizzo IP nella network della riga corrispondente.
La seconda tabella indica per ogni riga il codice identificativo di un
autonomous system e per ognuno di essi il numero di host che hanno almeno un
indirizzo IP in una network gestita da tale autonomous system.
Network HowManyDependsOnIt
23.45.56.0/21 1
216.239.32.0/22 2
AS HowManyDependsOnIt
AS20940 1
16

AS15169 2
Nella sezione 3 di questo capitolo è presentata la procedura eseguita per
l’estrazione dei dati per questa tesi.
Sezione 3 - Procedura per l’analisi della tesi
Per l’estrazione dei dati che sono stati usati per l’analisi in questa tesi sono
stati seguiti i seguenti passi:
1. È stato creato un file “Domain.txt” contenente la lista di domini da analizzare.
2. È stato scritto un brevissimo script che legge i domini nel file “Domain.txt” e li
salva in una lista.
3. È stato inizializzato un oggetto della classe DomainDependence con attributo
dbName uguale a “Results.sqlite”
4. È stato richiamato il metodo multipleDomainsDependencies, con ingresso
all’argomento domains la lista al punto 2. L’argomento csv è rimasto quello di
default. Gli altri argomenti, cioè i percorsi file al database .tsv, a geckodriver e
all’eseguibile di Firefox sono stati inseriti come opportuni argomenti.
5. È stato eseguito il metodo lookForVerifiedRange sullo stesso oggetto della
classe DomainDependence.
Il codice risultante è presentato in figura 4.1:
Figura 4.1 Script per procedura
Nel caso in cui ci siano stati degli errori durante l’esecuzione dei passi
precedenti, questi sono stati riportati nel file “Error.csv”. Nei log del file “Error.csv” è
riportato anche cosa ha causato l’errore, per esempio un nome dns che non è stato
risolto a causa di un timeout. Per ottenere i dati mancanti a causa di questi errori è
17

bastato ripetere la procedura inserendo come input al metodo
multipleDomainsDependencies il dominio per cui non è stata trovata qualche
informazione. L’oggetto di classe DomainDependence su cui eseguire il metodo può
essere inizializzato con lo stesso nome del file .sqlite in modo che i nuovi dati siano
aggiunti allo stesso database. Le informazioni che erano eventualmente già state
trovate non vengono replicate più volte nel database.
Una alternativa nel caso ci sia stato un singolo errore è stata quella di
eseguire solo il metodo che cerca l’informazione mancante con in input il dominio
riportato nel log dell’errore. In questo caso però poiché è
multipleDomainsDependencies il metodo che salva le informazioni trovate nel file
.sqlite, è stata inserita manualmente nel database l’informazione trovata, tramite il
software DataGrip di JetBrains.
La stessa procedura è stata applicata due volte uno per l’analisi dei domini
del capitolo 6 e una per l’analisi dei domini del capitolo 7.
Una volta che sono stati trovati le informazioni sui domini di partenza, sono
state estratti manualmente dal database i domini delle dipendenze software ed è
stata creata una seconda lista con questi domini su cui è stata ripetuta la procedura
ai punti 1 e 5.
In un secondo momento è stato scritto uno script in cui è stato inizializzato un
oggetto della classe dbAnalyser ed è stato usato per richiamare i metodi presentati
alla sezione precedente.
Dai file .csv in uscita dai metodi della classe dbAnalyser tramite l’uso di
Microsoft Excel sono stati disegnati a mano i grafici presenti nei capitoli 6 e 7, e sono
state costruite le tabelle presenti sempre in questi due capitoli.
Capitolo 5 Database
Per la raccolta dei dati è stata usata la procedura presentata nell’ultima
sezione del capitolo precedente. I risultati della procedura portano ad avere in uscita
un file .sqlite contenente tutte le informazioni estratte dalla classe
DomainDependence. In questo file sono contenute le tabelle del database, il
diagramma del database è rappresentato in figura 5.1.
Le frecce in figura 5.1 indicano le chiavi esterne delle tabelle. Segue una
descrizione delle tabelle, per rendere più facile la comprensione della struttura del
database.
18

Figura 5.1. Descrizione della struttura del database
La tabella HostInformation ha lo scopo di mantenere le informazioni
riguardanti i web host di cui sono state ricercate informazioni durante l’esecuzione
del metodo multipleDomainDependencies. Ogni tupla di questa tabella corrisponde
ad un website ricercato dal metodo multipleDomainDependencies. Nel caso in cui le
informazioni sulle dipendenze di un website siano già presenti nel file .sqlite il
metodo multipleDomainDependencies non aggiungerà nuovamente le stesse,
aggiungerà solo le informazioni sulle dipendenze mancanti. L’attributo cname è una
chiave esterna che punta, tramite id, ad una tupla della tabella domain2cname,
tabella dove sono contenute le informazioni di eventuali alias dei domini. Se il
dominio non ha alias il valore di cname è 0. Gli attributi landing_site_http e
landing_site_https sono delle stringhe che rappresentano il web domain a cui si
arriva accedendo all’host dopo le eventuali redirezioni, nel caso di accesso
rispettivamente tramite HTTP o HTTPS. Gli attributi STS_present e is_redirected
sono due attributi booleani che indicano rispettivamente se il sito a cui si accede
rispetta la Strict Transport Security policy e se l’accesso al sito tramite HTTP viene
ridirezionato sul sito in HTTPS.
La tabella domain2cname ha una tupla per ogni alias di un dominio web tra
quelli esaminati dal metodo multipleDomainDependencies. In questa tabella sono
presenti due attributi: domain e cname. domain è una stringa che rappresenta un
alias di un dominio, cname è una chiave esterna che punta ad un altra tupla di
questa stessa tabella, nel caso che un dominio abbia più alias è possibile seguire
questa chiave in sequenza per trovare tutti gli alias di un dominio. Se il dominio non
ha alias il valore di cname è 0.
19

La tabella domain2Software_Dependencies contiene le informazioni
riguardanti le origini degli script che sono stati trovati accedendo alla pagina web dei
domini web in ingresso al metodo multipleDomainDependencies. Questa tabella ha
una tupla per ogni script che è stato scaricato da un server. Di queste, ai fini
dell’analisi, sono manualmente filtrate le tuple degli script la cui origine è diversa dal
dominio web che scarica questi script e solo quelle che si trovano nello stesso frame
della pagina web. L’attributo domain è il dominio web la cui pagina ha un tag script
con sorgente un server con diverso dominio web, questa è una chiave esterna che
punta all’attributo host della tabella HostInformation. L’attributo host_dependence è
una stringa che rappresenta il nome del server d’origine di uno script. L’attributo
script_path è una stringa che rappresenta la terza parte dell’URL nell’attributo src
dello script corrispondente. integrity_present e different_iframe sono due attributi
booleani che indicano rispettivamente se lo script aveva anche l’attributo integrity e
se lo script si trovava contenuto all’interno di un IFRAME diverso da quello della
pagina web principale.
La tabella host2directZone ha una tupla per ogni coppia dominio web e zona
diretta in cui si trova tale dominio. La tabella host2directZone contiene due attributi:
host e direct_zone, il secondo è una stringa che rappresenta la zona diretta in cui si
trova l’host del primo attributo. L’attributo direct_zone è una chiave esterna che
punta all’attributo zone della tabella zone2synctacticDependence.
La tabella zone2synctacticDependence ha una tupla per ogni coppia nome di
zona e sottodominio del nome di zona che è anch’esso un nome di zona, più una
coppia con il nome di zona stesso. Queste coppie sono state trovate nella ricerca
delle dipendenze DNS tramite il metodo multipleDomainDependencies. La tabella
quindi zone2synctacticDependence contiene due attributi: zone e syntactic_zone.
L’attributo zone rappresenta il nome di una zona, mentre syntactic_zone rappresenta
uno dei sottodomini della zona nell’attributo zone che sono anche nomi di zona più il
nome di zona stesso. L’attributo syntactic_zone è poi una chiave esterna che punta
all’attributo zone della tabella zone2nameserver.
Per fare un esempio nel caso della zona esempio.com. in questa tabella ci
sarebbero le seguenti tre righe:
id zone syntactic_zone
1 esempio.com. .
2 esempio.com. com.
3 esempio.com. esempio.com.
20

La tabella zone2nameserver ha una tupla per ogni nameserver di ogni zona,
tra tutte le zone trovate nella ricerca delle dipendenze con il metodo
multipleDomainDependencies. La tabella zone2nameserver ha tre attributi: zone,
cname e nameserver. L’attributo zone è una stringa che è il nome di una zona.
cname è una chiave esterna che punta ad una tupla della tabella domain2cname
che contiene l’alias della zona, se non ci sono alias il valore è 0. nameserver è un
attributo che rappresenta il nome di un nameserver della zona sotto l’attributo zone
della stessa tupla. Le tuple di questa tabella sono quindi coppie zona-nameserver
della zona, se una zona ha più nameserver, allora più tuple avranno lo stesso valore
di zona.
La tabella host2IP ha una tupla per ogni coppia nome host e indirizzo IP
dell’host. Il nome di host può essere sia il nome di un web server che il nome di un
nameserver. Questi sono tutti trovati durante la ricerca sui domini web e le loro
dipendenze DNS fatta dal metodo multipleDomainDependencies. La tabella host2IP
ha due attributi: host e IPv4. Il primo rappresenta il nome di un host, il secondo
rappresenta uno degli indirizzi IP dell’host. Se ci sono repliche di un host su diversi
indirizzi IP vuol dire che più tuple avranno lo stesso valore di host e diverso valore di
IPv4.
La tabella IP2Range ha una tupla per ogni coppia indirizzo IP e network in cui
si trova. Questo accoppiamento viene fatto dal metodo
multipleDomainDependencies, che richiama la classe NetNumberResolver il cui
metodo resolve cerca nel database che associa network e autonomous system,
scaricabile da: https://iptoasn.com/, la network in cui si trova un indirizzo IP
passatogli in ingresso. La tabella IP2Range ha due attributi: ip_address e range.
ip_address rappresenta un indirizzo IP di un server, è una chiave esterna che punta
all’attributo IPv4 della tabella host2IP. range è una stringa che rappresenta il range
di indirizzi in cui si trova l’indirizzo IP della stessa tupla. Il formato con cui sono
rappresentati questi range di indirizzi è lo stesso della notazione CIDR (Classless
Inter-Domain Routing), quindi primo indirizzo IP del range seguito dal carattere “/” e
dal numero di bit di prefisso. range è una chiave esterna che punta all’attributo
IP_range della tabella range2AS.
Un esempio della rappresentazione di uno dei range in tabella IP2Range è il
seguente: 123.123.123.0/24
La tabella range2AS contiene le informazioni per associare un range di
indirizzi all’autonomous system che lo gestisce. Questa tabella ha una tupla per ogni
network che è stata trovata dal metodo multipleDomainDependencies nella ricerca
delle dipendenze dei domini web. Queste tuple sono ognuna un’associazione tra la
network e l’autonomous system che la gestisce. In questa tabella, l’attributo
IP_range è una chiave esterna che punta all’attributo range della tabella IP2Range e
ha la stessa notazione che si trova in tale tabella. L’attributo AS_code rappresenta il
codice identificativo dell’autonomous system che gestisce il range di indirizzi IP.
21

location_code corrisponde al codice di due lettere che identificano una nazione,
questo è il codice che corrisponde al country_code del database nel file ip2asn.tsv,
scaricabile da: https://iptoasn.com/ di cui si è già accennato in precedenza.
L’attributo AS_description rappresenta una breve descrizione dell’autonomous
system.
Infine, la tabella range2verificated ha una tupla per ogni network di quelle che
sono presenti anche in tabella IP2Range. La tabella range2verificated ha due
attributi: range e verificated. range è un stringa che rappresenta un range di indirizzi,
è una chiave esterna che punta all’attributo range della tabella IP2Range, questo
attributo ha la stessa notazione descritta per la tabella IP2Range. verificated è un
booleano che indica se l’autonomous system che gestisce il range corrispondente
nella stessa tupla implementa la Route Origin Validation (ROV) per validare le
informazioni riguardanti il Border Gateway Protocol (BGP).
Capitolo 6 Analisi
Sezione 1- Insieme di siti considerati
Seguendo la procedura descritta in precedenza sono stati analizzati due
gruppi di siti web. Poiché l’obiettivo della tesi è quello di analizzare l’architettura delle
reti e le dipendenze dei siti web degli IdP italiani, è stato preso in esame un gruppo
di siti web con cui poter fare un confronto. Di conseguenza il primo gruppo è un
insieme di siti di uso comune che trattano anche dati personali, questi siti sono
utilizzati da milioni di utenti in tutto il mondo. Tra questi sono anche stati presi in
considerazione le pagine di login dei siti che gestiscono l’identità digitale in Spagna e
Regno Unito. Il secondo gruppo di siti, invece, è quello che contiene i siti dei nove
SPID provider.
Per quanto riguarda il primo gruppo sono stati analizzati i seguenti siti web:
● accounts.google.com
● login.microsoftonline.com
● www.facebook.com
● https://twitter.com/i/flow/login
● https://www.amazon.com/ap/signin
● I siti degli IdP del Regno Unito, che sono i seguenti:
1. auth.myprofile.postoffice.co.uk
2. auth.digidentity.eu
22

● I siti degli IdP della Spagna, che sono i seguenti:
1. clave-dninbrt.seg-social.gob.es
2. pasarela.clave.gob.es
Sezione 2 - Dati e analisi per la name resolution
Le specifiche DNS indicano un criterio di ridondanza per cui ogni zona
dovrebbe avere almeno due nameserver geograficamente e topologicamente
diversi. In questa analisi è stata preso questo criterio come spunto per fare la
seguente distinzione: se tutti i nameserver di una zona si trovano in una stessa
network significa che il criterio non è soddisfatto, se i nameserver sono divisi in 2
distinte network allora il criterio è soddisfatto, se i nameserver sono divisi in 3 o più
network diciamo che il criterio è più che soddisfatto.
Per l’analisi sono state osservate, quindi, le ridondanze nell’architettura delle
reti delle zone di cui fanno parte i nomi dei server presi in esame. I risultati che sono
stati ottenuti sono presentati nelle tabelle 6.1 e 6.2.
google.com. 4 1 1 1
microsoftonline.com. 8 5 1 1
myprofile.postoffice.co.uk. 4 1 1 1
digidentity.eu. 3 2 2 2
seg-social.gob.es. 3 2 1 1
clave.gob.es. 2 1 1 1
facebook.com. 4 2 1 1
twitter.com. 10 3 2 1
amazon.com. 6 4 2 1
IdP UK 7 3 3 3
IdP ES 5 3 1 1
Tabella 6.1 numero di nameserver, network su cui sono distribuiti i nameserver e autonomous system
che gestiscono queste network nelle architetture delle reti di cui fanno parte i web server dell’analisi.
DirectZone Redundancy networks Redundancy AS
google.com. Non soddisfa Non soddisfa
microsoftonline.com. Più che soddisfa Non soddisfa
myprofile.postoffice.co.uk. Non soddisfa Non soddisfa
23

digidentity.eu. Soddisfa Soddisfa
seg-social.gob.es. Soddisfa Non soddisfa
clave.gob.es. Non soddisfa Non soddisfa
facebook.com. Soddisfa Non soddisfa
twitter.com. Più che soddisfa Soddisfa
amazon.com. Più che soddisfa Soddisfa
IdP UK / /
IdP ES / /
Tabella 6.2 ridondanze nelle architetture delle reti di cui fanno parte i web server dell’analisi.
Nell’ordine le colonne di tabella 6.1 indicano: la zona diretta a cui
appartengono i domini web considerati, il numero di nameserver di questa zona
diretta, il numero di differenti network di cui fanno parte i nameserver, il numero di
differenti autonomous system che gestiscono le network della colonna precedente e
il numero di diversi country code associati agli autonomous system della colonna
precedente, questi country code sono stati estratti dal database ip2asn scaricabile
dal sito: https://iptoasn.com/, come visto in precedenza.
La prima colonna di tabella 6.2 riporta le zone dirette come in tabella 6.1. La
seconda colonna di tabella 6.2 riporta quali delle zone dirette soddisfano il criterio di
ridondanza espresso ad inizio sezione. Lo stesso discorso viene replicato per la
ridondanza degli autonomous system nell’ultima colonna.
Le ultime due righe della Tabella 6.1 rappresentano i due gruppi di IdP del
Regno Unito e IdP della Spagna in cui sono stati combinati i dati dei due siti per
ognuno di questi due gruppi. Le ultime due colonne non hanno valore in quanto
queste due righe sarebbero l’unione di più zone e quindi avrebbero più di un valore
in corrispondenza di queste celle.
Ogni zona presente nella tabella ha più di un nameserver. Non è possibile con
i campioni presi in considerazione evidenziare una architettura univoca per tutti,
infatti, osservando il criterio di ridondanza espresso precedentemente, la ridondanza
delle network non è uguale per tutti. Per quanto riguarda la ridondanza degli
autonomous system, invece, circa due terzi di queste zone hanno nameserver che si
trovano in network tutte gestite dallo stesso autonomous system, probabilmente per
una maggiore centralizzazione degli sforzi per la difesa da eventuali attacchi.
Le zone dirette sono comunque tutte differenti di conseguenza non ci sono siti
tra quelli in esame che siano direttamente dipendenti dalla stessa zona.
Osservando quali siano le network in cui si trovano i nameserver di queste
zone si vede che non c’è quasi nessuna network in cui si trovano nameserver di due
24

zone diverse tra quelle prese in considerazione, l’unica eccezione la fanno le
network in cui si trovano i nameserver della zona twitter.com, che sono:
205.251.192.0/24, 208.78.68.0/22, 204.13.248.0/22, come si può notare dalla tabella
6.3. Perciò, a parte quest'ultima eccezione, non è possibile portare a termine un
attacco di tipo Denial of Service su una sola network che sia in grado di danneggiare
tanti IdP diversi. Non ci sono network condivise tra i siti presi in esame per la
risoluzione del nome dns.
I risultati del paragrafo precedente sono presentati nella tabella 6.3
sottostante.
Group Network #Zone depending
on the network
networks with
ROA
Google 216.239.32.0/22 1 True
Microsoft 150.171.0.0/19 1 True
myprofile.postoffice.co.uk.
and
digidentity.eu.
205.251.192.0/24 1 False
and
digidentity.eu.
82.148.192.0/19 1 True
and
digidentity.eu.
95.216.0.0/15 1 False
seg-social.gob.es.
and
clave.gob.es.
194.179.42.0/17 1 False
seg-social.gob.es.
and
clave.gob.es.
213.99.29.0/24 1 True
seg-social.gob.es.
and
clave.gob.es.
213.0.84.0/24 1 True
Facebook 129.134.0.0/24 1 True
Facebook 185.89.218.0/23 1 False
25

Twitter 205.251.192.0/24 1 True
Twitter 208.78.68.0/22 1 False
Twitter 204.13.248.0/22 1 False
Amazon 208.78.68.0/22 1 False
Amazon 204.13.248.0/22 1 False
Amazon 204.74.108.0/23 1 False
Amazon 204.74.115.0/24 1 False
Tabella 6.3 network su cui dipendono le zone considerate
La prima colonna in tabella 6.3 indica il gruppo a cui si fa riferimento, ogni sito
è un gruppo a sé tranne per i siti degli IdP del Regno Unito e della Spagna che sono
raggruppati. La seconda colonna riporta le network in cui si trovano i nameserver
delle zone dei gruppi. La terza colonna riporta quanti sono le zone del gruppo
corrispondente che hanno almeno un nameserver nella network alla colonna
precedente, e quindi quante sono le zone del gruppo che dipendono dalla network
alla colonna precedente. L’ultima colonna riporta se per la network corrispondente
l’autonomous system che la gestisce implementa la BGP Route Origin Authorization
(ROA). Gli autonomous system rilasciano asserzioni sul prefisso di indirizzi IP di cui
sono proprietari. Per rilevare se qualche autonomous system rilascia asserzioni
errate o fraudolente, sono state introdotte le Route Origin Authorization (ROA), che
consistono in asserzioni verificabili crittograficamente, tramite firme digitali. Gli
autonomous system dovrebbero implementare la Route Origin Validation (ROV) che
consiste nello scaricare i ROA, presenti in registri pubblici, per verificare le
asserzioni sui BGP ricevuti. L’ultima colonna della tabella 6.3 indica se per la
network alla riga corrispondente esiste un ROA verificabile.
Come si vede dall’ultima colonna anche qui è evidente che non tutte le
network seguono la stessa linea, non c’è una percentuale che spicca di quelle per
cui l’autonomous system implementa oppure no la BGP ROA. Perciò è possibile, per
alcune di queste network, che un attaccante possa impersonare un autonomous
system e fornire delle asserzioni errate in cui dichiara di essere il gestore degli
indirizzi in tali network. In tal modo l’attaccante può deviare il traffico verso server
che sono sotto il suo controllo.
Osservando anche le dipendenze dagli autonomous system anche qui non ci
sono autonomous system che gestiscono network in cui risiedono nameserver di
zone diverse, tra quelle considerate, bensì ogni network su cui dipendono zone
diverse è gestita da autonomous system diversi. Questo fatto implica che non ci
siano attacchi ad autonomous system che permettano ad un attaccante di bloccare
la risoluzione dei nomi o prendere il controllo di più di uno dei siti presi in esame.
26

Però questo significa anche che la gestione delle network è distribuita su diversi
autonomous system e che quindi il perimetro da difendere è più ampio.
L’unica eccezione, riportata in tabella 6.4, la fa l’autonomous system AS3352
che gestisce le network con i nameserver di entrambe le zone dirette degli IdP
spagnoli, seg-social.gob.es e clave.gob.es.
Group AS HowManyDependsOnTheAS
myprofile.postoffice.co.uk. and
digidentity.eu.
AS16509 1
digidentity.eu.
AS29396 1
digidentity.eu.
AS24940 1
seg-social.gob.es.
and
clave.gob.es.
AS3352 2
Tabella 6.4 Dipendenza dagli autonomous system
In tabella 6.4 sono riportati gli autonomous system su cui dipendono le
network delle zone degli IdP del Regno Unito e della Spagna, sono stati tralasciati le
altre zone dirette perché non erano dati significativi, per il motivo spiegato al
paragrafo precedente.
Sezione 3 - Dati e analisi per il web access
Per quanto riguarda l’analisi dell’accesso alla pagina web, i siti sono stati
divisi in quattro categorie, come mostrato in figura 6.1. Sull’asse delle ascisse ci
sono i gruppi di siti analizzati, sull’asse delle ordinate c’è la percentuale dei siti di
questi gruppi che appartengono ad una determinata categoria.
27

Figura 6.1 Percentuale di siti, divisi per gruppi, che appartengono ad una delle categorie di sicurezza
Le quattro categorie di server presenti in figura 6.1 sono le stesse presentate
in tabella 4.1. Queste sono le categorie che rappresentano quattro livelli diversi di
sicurezza dei siti web.
Come si evince dalla figura 6.1 tutti i server tranne quelli degli IdP spagnoli,
presentano l’header Strict Transport Security come forma di difesa dagli attacchi di
tipo SSLStrip.
Analogamente alla tabella 6.1 per la ridondanza nell’architettura delle reti,
vengono di seguito riportate le tabelle 6.5 e 6.6 per la ridondanza degli indirizzi IP
per i server del gruppo di siti presi in considerazione in questo capitolo.
Host #Ip #networks #AS #AS_countries
accounts.google.com. 1 1 1 1
login.microsoftonline.com. 8 2 1 1
auth.myprofile.postoffice.co.uk. 3 2 1 1
auth.digidentity.eu. 3 2 1 1
clave-dninbrt.seg-social.gob.es. 1 1 1 1
pasarela.clave.gob.es. 1 1 1 1
www.facebook.com. 1 1 1 1
twitter.com. 2 1 1 1
28

www.amazon.com. 1 1 1 1
IdP UK 6 4 1 1
IdP ES 2 2 2 1
Tabella 6.5 Numero ridondanze indirizzi IP, network in cui si trovano e autonomous system che le
gestiscono
Host IP replicas Network
redundancy
AS redundancy
accounts.google.com. Non soddisfa Non soddisfa Non soddisfa
login.microsoftonline.com. Più che soddisfa Soddisfa Non soddisfa
auth.myprofile.postoffice.co.uk. Più che soddisfa Soddisfa Non soddisfa
auth.digidentity.eu. Più che soddisfa Soddisfa Non soddisfa
clave-dninbrt.seg-social.gob.es Non soddisfa Non soddisfa Non soddisfa
pasarela.clave.gob.es. Non soddisfa Non soddisfa Non soddisfa
www.facebook.com. Non soddisfa Non soddisfa Non soddisfa
twitter.com. Soddisfa Non soddisfa Non soddisfa
www.amazon.com. Non soddisfa Non soddisfa Non soddisfa
IdP UK / / /
IdP ES / / /
Tabella 6.6 Ridondanza degli indirizzi IP, network in cui si trovano e autonomous system che
gestiscono tali network
La prima colonna della tabella 6.5 riporta i domini web delle pagine
considerate. La seconda colonna riporta il numero di repliche degli indirizzi IP del
sito web. La terza colonna riporta il numero di differenti network in cui si trovano le
repliche degli IP dei siti web. La quarta colonna riporta il numero di diversi
autonomous system che gestiscono le network della colonna precedente. La quinta
colonna, come era per la tabella 6.1, riporta il numero di diversi country code
associati agli autonomous system della colonna precedente.
Con gli stessi criteri visti in tabella 6.2 viene riportato in tabella 6.6 se il
numero di repliche di IP, il numero di network in cui sono distribuite le repliche e il
numero di autonomous system che gestiscono tali network soddisfano il criterio di
ridondanza.
Come per la tabella 6.1 anche nella 6.6 le ultime due righe riportano i dati
raggruppati per IdP del Regno Unito e Spagna.
29

I siti che hanno più indirizzi IP in network differenti sono pochi. In più, anche
se ci sono più repliche in diverse network queste network sono gestite da un solo
autonomous system, facendo sì che prendere il controllo di uno di questi
autonomous system permetta ad un attaccante di avere il controllo di tutte le repliche
degli IP di un sito. In questo modo però il perimetro da difendere è più limitato
essendo affidata la gestione delle network dove si trovano gli indirizzi IP ad un solo
autonomous system.
In tabella 6.7 sono riportate le network in cui sono distribuite le repliche degli
IP. L’ultima colonna mostra per quali di queste si fa uso della BGP ROA.
Host network networkWithROA
accounts.google.com. 142.250.151.0/20 True
login.microsoftonline.com. 20.184.0.0/13 True
login.microsoftonline.com. 40.126.0.0/18 True
auth.myprofile.postoffice.co.uk. 18.132.0.0/16 False
auth.myprofile.postoffice.co.uk. 35.176.0.0/13 False
auth.digidentity.eu. 52.8.0.0/14 False
auth.digidentity.eu. 52.47.0.0/16 False
clave-dninbrt.seg-social.gob.es. 194.179.42.0/17 False
pasarela.clave.gob.es. 185.73.172.0/24 False
www.facebook.com. 69.171.224.0/24 True
twitter.com. 104.244.40.0/24 False
www.amazon.com. 18.32.0.0/14 False
Tabella 6.7 Dipendenza dalle network
Dalla tabella 6.7 si osserva che ogni sito dipende da network differenti, non ci
sono network in cui si trovano repliche degli IP di siti differenti. In più, dalla tabella
6.7 si evince che la maggior parte delle network in cui si trovano le repliche degli IP
dei siti analizzati non fanno uso della BGP ROA.
Sezione 4 - Dati e analisi per gli script
Infine, è stata fatta un’analisi osservando quali sono stati i server da cui è
stato scaricato uno script quando è stato fatto l’accesso alle pagine web considerate.
Sono stati presi in esame solo gli script che provenivano da server differenti da quelli
dell’origine della pagina web, e di questi solo quelli in cui il tag script si trovi nello
stesso frame della pagina web. Questo aspetto è importante perché l’utente
30

usufruisce di un servizio che nasce dalla collaborazione con terze parti. Un
attaccante che prende il controllo di uno script il cui tag si trova nello stesso frame di
una pagina web è in grado di eseguire il codice che vuole sul browser dell’utente.
Per esempio, uno script manipolato da un attaccante può far sì che vengano
inviate informazioni dell’utente oppure il cookie con cui l’utente mantiene l’accesso
su di una pagina ad un server di cui ha il controllo l’attaccante.
Un meccanismo di difesa da un attacco di questo tipo può essere il seguente:
gli sviluppatori della pagina web che offre il servizio agli utenti dovrebbero analizzare
lo script che viene scaricato da terzi in maniera da verificarne la natura non maligna
per poi farne una copia da tenere salvata nello stesso web server che offre il
servizio, o un altro ma che sia gestito dalla stessa organizzazione. In questo modo lo
script non viene più scaricato da server di altre organizzazioni.
Un’alternativa può essere quella di, dopo aver analizzato lo script da parte
degli sviluppatori, dare la possibilità al browser di verificare l’integrità dello script
scaricato. Questo è possibile farlo inserendo l’attributo integrity con l’hash della
sorgente dello script analizzato dagli sviluppatori. L’attributo andrebbe inserito nel
tag script della pagina web. Grazie all’hash il browser è in grado di scaricare lo
script, calcolare il suo hash e verificare se l’hash ottenuto è lo stesso del valore
dell’attributo integrity. Se la verifica dell’integrità dello script da parte del browser
dovesse fallire significherebbe che quest'ultimo è stato manomesso e quindi il
browser non eseguirebbe lo script in questione.
Di seguito è riportata la lista di server contattati per scaricare uno script e per
quale sito è stato scaricato, tabella 6.8.
Sito analizzato Server da cui è scaricato uno script
auth.myprofile.postoffice.co.uk ocsp.digicert.com
auth.myprofile.postoffice.co.uk tracking-protection.cdn.mozilla.net
auth.myprofile.postoffice.co.uk d1piuc6mf7ro4.cloudfront.net
auth.digidentity.eu tracking-protection.cdn.mozilla.net
auth.digidentity.eu cdn-auth.digidentity.eu
auth.digidentity.eu www.googletagmanager.com
auth.digidentity.eu snap.licdn.com
auth.digidentity.eu www.google-analytics.com
auth.digidentity.eu static.ads-twitter.com
auth.digidentity.eu px.ads.linkedin.com
31

clave-dninbrt.seg-social.gob.es ocsp.digicert.com
clave-dninbrt.seg-social.gob.es tracking-protection.cdn.mozilla.net
pasarela.clave.gob.es ocsp.digicert.com
pasarela.clave.gob.es tracking-protection.cdn.mozilla.net
login.microsoftonline.com tracking-protection.cdn.mozilla.net
login.microsoftonline.com aadcdn.msauth.net
accounts.google.com ocsp.digicert.com
accounts.google.com tracking-protection.cdn.mozilla.net
accounts.google.com ssl.gstatic.com
www.facebook.com static.xx.fbcdn.net
twitter.com apis.google.com
twitter.com abs.twimg.com
twitter.com www.google-analytics.com
twitter.com appleid.cdn-apple.com
twitter.com ssl.gstatic.com
Tabella 6.8 server da cui è stato scaricato uno script
Come si può notare molti dei siti web hanno contattato i server
tracking-protection.cdn.mozilla.net e ocsp.digicert.com per scaricare uno script.
Di seguito nella tabella 6.9 sono riportate le repliche dell’architettura delle reti
dove si trovano i server da cui sono stati scaricati gli script. La descrizione di questa
tabella è analoga alla tabella 6.1.
digicert.com. 6 2 1 1
mozilla.net. 4 4 1 1
d1piuc6mf7ro4.cloudfront.net. 4 1 1 1
digidentity.eu. 3 2 2 2
googletagmanager.com. 4 1 1 1
licdn.com. 8 3 2 1
google-analytics.com. 4 1 1 1
ads-twitter.com. 8 3 2 1
32

linkedin.com. 8 3 2 1
msauth.net. 8 8 2 2
gstatic.com. 4 1 1 1
xx.fbcdn.net. 4 2 1 1
google.com. 4 1 1 1
twimg.com. 10 3 2 1
cdn-apple.com. 4 3 2 1
Tabella 6.9 Numero di nameserver, network in cui sono distribuiti, autonomous system che gestiscono
tali network delle zone dirette dei siti da cui è scaricato uno script.
DirectZone Redundancy network Redundancy AS
digicert.com. Soddisfa Non soddisfa
mozilla.net. Più che soddisfa Non soddisfa
d1piuc6mf7ro4.cloudfront.net. Non soddisfa Non soddisfa
digidentity.eu. Soddisfa Soddisfa
googletagmanager.com. Non soddisfa Non soddisfa
licdn.com. Più che soddisfa Soddisfa
google-analytics.com. Non soddisfa Non soddisfa
ads-twitter.com. Più che soddisfa Soddisfa
linkedin.com. Più che soddisfa Soddisfa
msauth.net. Più che soddisfa Soddisfa
gstatic.com. Non soddisfa Non soddisfa
xx.fbcdn.net. Soddisfa Non soddisfa
google.com. Non soddisfa Non soddisfa
twimg.com. Più che soddisfa Soddisfa
cdn-apple.com. Più che soddisfa Soddisfa
Tabella 6.10 Ridondanze nelle architetture delle reti di cui fanno parte i server da cui sono stati
scaricati degli script.
Per le ultime due colonne della tabella 6.10 sono stati considerati gli stessi
criteri di ridondanza usati per le ultime colonne della tabella 6.1.
In questo caso le ridondanze delle network sono maggiori rispetto ai casi visti
in precedenza. Più del 60% di questi server si trovano in zone che sono distribuiti su
33

almeno 2 network diverse, c’è maggiore ridondanza anche per quanto riguarda gli
autonomous system che gestiscono queste network.
Per quanto riguarda la dipendenza nelle figure 6.2 e 6.3 sono riportate le
network e gli autonomous system, rispettivamente, da cui dipendono i server da cui
sono scaricati degli script.
Figura 6.2 Network da cui dipendono i server
Figura 6.3 Autonomous system da cui dipendono i server da cui sono scaricati script
34

A differenza di quanto visto in precedenza dalle figure 6.2 e 6.3 si evince che
ci sono sette network e cinque autonomous system su cui dipende più di una zona
diretta in cui si trova il dominio web dei server da cui si scarica uno script. Questo
significa che se un attaccante dovesse prendere il controllo di una di queste network
potrebbe bloccare la risoluzione dei nomi di più di uno dei server su cui ci sono gli
script da scaricare. In alternativa potrebbe impersonare più di uno dei server da cui
viene scaricato lo script e consegnare ai browser uno script manipolato
dall’attaccante. In questo modo sarebbe in grado di colpire un numero maggiore di
utenti, nello specifico tutti quelli che accedono a pagine web che scaricano uno script
da uno dei server impersonati dall’attaccante. Il fatto importante è che all’attaccante
basterebbe fare un attacco ad una sola network e colpire fino a 4 server da cui
vengono scaricati script, come mostrato in figura 6.2.
Anche nel caso che l’attacco colpisca i giusti autonomous system l’attaccante
sarebbe in grado di bloccare l’accesso o impersonare più di un server da cui sono
scaricati degli script.
In figura 6.4 sono riportate le percentuali dei server da cui viene scaricato uno
script che appartengono ad una delle quattro categorie di server viste anche per la
figura 6.1. In questo caso in poco più del 50% dei casi i server fanno parte di quella
categoria di host che non fanno un reindirizzamento da HTTP a HTTPS se si accede
all’host tramite HTTP. Questo significa che c’è la possibilità che uno script venga
scaricato da una pagina tramite HTTP e che un attacco di tipo SSLStrip possa
essere portato a termine anche in richieste successive alla prima. Nel caso dei siti
analizzati, però, questo problema non si pone. Ad ogni sito, infatti, si accede tramite
HTTPS, quindi anche se uno script dovesse essere scaricato tramite HTTP questo
verrebbe bloccato dal browser data la presenza di mixed content nella pagina web.
Figura 6.4 Percentuale di siti da cui è scaricato uno script che appartengono ad una delle categorie di
tabella 4.1.
35

Per l’analisi degli script è stata verificata anche la presenza dell’attributo
integrity, che permette ai browser di verificare se una risorsa scaricata da terzi non
sia stata manipolata. Come detto a inizio sezione questo sarebbe uno dei possibili
meccanismi di difesa da attacchi che sfruttano script scaricati da terzi. Nessuno degli
script analizzati aveva l’attributo integrity.
Per finire è stata ripetuta questa analisi accedendo ai siti tramite una VPN per
mascherare l'origine delle richieste e controllare se si ottenessero differenti
informazioni accedendo ai server da altre locazioni nel mondo. Le locazioni scelte
sono state: Stati Uniti, Giappone e Paesi Bassi. Non ci sono state significative
differenze tra l’esecuzione della raccolta dati dall’Italia o da altre nazioni. Le uniche
differenze riscontrate riguardano gli indirizzi IP dei siti di Facebook, Google e
Amazon che sono risultati differenti. Nonostante questo la ridondanza di indirizzi IP,
le network in cui sono distribuiti e gli autonomous system che gestiscono queste
network sono invariate. Anche per le dipendenze DNS le ridondanze sono rimaste
invariate, stesso numero di nameserver, stesso numero di network in cui sono
distribuiti e stesso numero di autonomous system che gestiscono le network.
Sezione 5 - Riepilogo analisi
Viene riportato un riepilogo sintetico dell’analisi dei siti:
● Per ogni zona diretta è diverso il numero di network in cui sono distribuiti i
nameserver, non c’è una somiglianza tra le zone da questo punto di vista.
● Due terzi delle zone dirette hanno nameserver in zone gestite dallo stesso
autonomous system.
● La zona twitter.com. ha dei nameserver situati in network in cui sono presenti
nameserver anche di altre zone dirette tra quelle considerate. Le network
sono: 205.251.192.0/24, 208.78.68.0/22, 204.13.248.0/22.
● L’autonomous system con codice identificativo AS3352 gestisce le network in
cui sono situati i nameserver delle zone dirette degli IdP spagnoli.
● Non tutti gli autonomous system che gestiscono le network delle zone dirette
implementano il BGP ROA per le loro network. Lo stesso discorso vale per le
network dove si trovano le repliche degli indirizzi IP.
● Quasi la totalità dei siti considerati implementa la Strict Transport Security
policy. Gli unici che non implementano questa policy sono i siti degli IdP
spagnoli.
● Anche per quanto riguarda le repliche degli indirizzi IP e la loro distribuzione
su differenti network, non c’è una linea d’azione comune da parte dei siti qui
considerati. Solo il criterio di ridondanza per gli autonomous system non è
soddisfatto da nessuno dei siti.
● Nessuno degli script scaricati viene verificato grazie all’attributo integrity.
● Alcuni dei nameserver delle zone dirette dei server da cui sono scaricati degli
script si trovano nella stessa network dei nameserver di altre di queste zone
dirette.
36

● Più del 50% dei server da cui è scaricato uno script non implementa la Strict
Transport Security policy e le connessioni su HTTP non le ridireziona su
HTTPS.
● L’analisi fatta passando tramite delle VPN ha fatto emergere una differenza
nell’indirizzo IP dei server, ma le ridondanze di network e autonomous
system, sia nel caso delle dipendenze DNS sia nel caso delle dipendenze
web, sono rimaste invariate.
Capitolo 7 Analisi dei siti dello SPID
Sezione 1- Insieme di IdP considerati
Una volta conclusa l’analisi del primo gruppo di siti, è stata fatta l’analisi per il gruppo
dei nove siti SPID. I domini di questi siti sono:
● loginspid.aruba.it
● identity.infocert.it
● spid.intesa.it
● id.lepida.it
● idp.namirialtsp.com
● posteid.poste.it
● identity.sieltecloud.it
● spid.register.it
● login.id.tim.it
Sezione 2 - Dati e analisi per la name resolution
Come per l’analisi del primo gruppo di siti, anche qui è stata analizzata
l’architettura delle reti in cui sono situati i server dei siti SPID. In tabella 7.1 e 7.2
sono riportati i dati trovati riguardo all’architettura delle reti.
aruba.it. 4 3 2 2
infocert.it. 2 2 1 1
intesa.it. 2 1 1 1
lepida.it. 2 2 1 1
37

namirialtsp.com. 4 1 1 1
poste.it. 3 1 1 1
sieltecloud.it. 2 2 2 2
register.it. 2 2 2 2
tim.it. 2 2 2 1
SPID-IT 21 14 11 4
Tabella 7.1 Dati architettura delle reti dei server dello SPID
DirectZone Redundancy network Redundancy AS
aruba.it. Più che soddisfa Soddisfa
infocert.it. Soddisfa Non soddisfa
intesa.it. Non soddisfa Non soddisfa
lepida.it. Soddisfa Non soddisfa
namirialtsp.com. Non soddisfa Non soddisfa
poste.it. Non soddisfa Non soddisfa
sieltecloud.it. Soddisfa Soddisfa
register.it. Soddisfa Soddisfa
tim.it. Soddisfa Soddisfa
SPID-IT / /
Tabella 7.2 Ridondanze dell’architettura delle reti dei server dello SPID
Il significato delle colonne è il medesimo delle tabelle 6.1 e 6.2. Anche il
senso dell’ultima riga è analogo alle ultime due delle tabelle 6.1 e 6.2, ma in questo
caso l’ultima riga è ottenuta mettendo insieme i dati di tutte le righe precedenti,
ovvero tutte le zone dirette in cui si trovano i domini web dei siti SPID.
Come era per il primo gruppo di siti analizzati anche qui non c’è una linea
comune riguardo alle ridondanze delle network e degli autonomous system, i
nameserver di alcune zone sono distribuiti su diverse network altri no.
I nameserver di zone differenti sono diversi e si trovano in network diverse,
gestite da autonomous system differenti. Questo significa che un attaccante non è in
grado, facendo un attacco ad una singola network di colpire diversi siti SPID.
L’unica eccezione la fanno i nameserver delle zone sieltecloud.it e register.it.
Queste due zone si appoggiano sugli stessi due nameserver. Questo significa che
se un attaccante riuscisse a portare a termine un attacco di tipo Denial of Service
sulle due network in cui si trovano i due nameserver di queste zone sarebbe in grado
38

di precludere agli utenti l’accesso a due siti dello SPID, identity.sieltecloud.it e
spid.register.it.
Come è stato fatto al capitolo 6 in tabella 6.3 anche qui, tabella 7.3, è riportato
il numero di network per cui viene implementato il BGP ROA per verificare se una
network è gestita da un certo autonomous system. Dalla tabella 7.3 si vede che non
per tutte le network viene verificata la route d’origine, in modo analogo a come si è
visto per i siti del primo gruppo analizzato. Gli autonomous system che gestiscono le
network non sembra che seguano le stesse regole. È da sottolineare che gli
autonomous system implementano il BGP ROA solo per alcune delle network che
gestiscono ma non per tutte.
Direct zone #Networks #networksWithROA
aruba.it 3 1
infocert.it. 2 2
intesa.it. 1 1
lepida.it. 2 2
namirialtsp.com. 1 1
poste.it. 1 0
sieltecloud.it. 2 1
register.it. 2 1
tim.it. 2 1
Tabella 7.3 network che implementano il BGP ROA.
Sezione 3 - Dati e analisi per il web access
Per quanto riguarda l’analisi dell’accesso al sito web sono stati divisi i server
che ospitano i siti SPID nelle quattro categorie di sicurezza di accesso al sito
espresse in tabella 4.1. La suddivisione in categorie è riportata in tabella 7.4.
Dominio Categoria
loginspid.aruba.it https_strip
identity.infocert.it secure+almost
spid.intesa.it https_strip
id.lepida.it secure+almost
idp.namirialtsp.com secure+almost
posteid.poste.it https_strip
39

identity.sieltecloud.it https_strip
spid.register.it https_strip
login.id.tim.it https_strip
Tabella 7.4 Suddivisione dei server nelle quattro categorie di sicurezza descritte in tabella 4.1.
A differenza di quanto visto per il primo gruppo di siti analizzati, per quelli
dello SPID c’è una maggioranza di siti che non implementano la Strict Transport
Security policy. Questo fatto è negativo poiché In tal modo la maggior parte dei siti
SPID è sensibile al tipo di attacco SSLStrip.
In tabella 7.5 e 7.6 sono riportate le informazioni riguardo alle repliche degli
indirizzi dei server dei siti SPID, in maniera analoga a quanto è stato fatto per il
gruppo di siti precedente. Il significato delle colonne in tabella è lo stesso per le
tabelle 6.5 e 6.6.
Host #IP #networks #AS #AS_countries
loginspid.aruba.it. 1 1 1 1
identity.infocert.it. 1 1 1 1
spid.intesa.it. 1 1 1 1
id.lepida.it. 1 1 1 1
idp.namirialtsp.com. 1 1 1 1
posteid.poste.it. 20 1 1 1
identity.sieltecloud.it. 1 1 1 1
spid.register.it. 1 1 1 1
login.id.tim.it. 1 1 1 1
SPID-IT 28 9 9 1
Tabella 7.5 Numero di ridondanze degli indirizzi IP, network in cui sono distribuiti e autonomous
system che gestiscono queste network.
Host IP replicas Network
redundancy
AS redundancy
loginspid.aruba.it. Non soddisfa Non soddisfa Non soddisfa
identity.infocert.it. Non soddisfa Non soddisfa Non soddisfa
spid.intesa.it. Non soddisfa Non soddisfa Non soddisfa
id.lepida.it. Non soddisfa Non soddisfa Non soddisfa
idp.namirialtsp.com. Non soddisfa Non soddisfa Non soddisfa
40

posteid.poste.it. Più che soddisfa Non soddisfa Non soddisfa
identity.sieltecloud.it. Non soddisfa Non soddisfa Non soddisfa
spid.register.it. Non soddisfa Non soddisfa Non soddisfa
login.id.tim.it. Non soddisfa Non soddisfa Non soddisfa
SPID-IT / / /
Tabella 7.6 In tabella è riportato per quali host sono rispettati i criteri di ridondanza di IP, network e
autonomous system.
Se nel caso del gruppo di siti precedente si poteva notare poca ridondanza e
poca distribuzione delle repliche in diverse network, in questo caso questo fatto è
ancora più marcato, ma perché quasi la totalità dei siti dello SPID si appoggiano su
un solo server. L’unico SPID provider che replica il sito su diversi indirizzi IP è
posteID, ma queste repliche sono comunque situate nella stessa network rendendo
comunque vulnerabile il sito ad attacchi Denial of Service portati a termine sull’unica
network in cui si trovano le repliche.
Il fatto che quasi tutti i server dello SPID non abbiano repliche significa che
l’attaccante non deve necessariamente colpire una network o un autonomous
system per bloccare l’accesso ad un sito dello SPID o impersonarlo, bensì
l’attaccante può concentrarsi nel tentativo di colpire un singolo server. D’altro canto
per gli sviluppatori di questi siti è necessario concentrare gli sforzi per la difesa su un
solo server, o una sola network.
Sezione 4 - Dati e analisi per gli script
Anche per i siti SPID sono stati analizzati i server d’origine degli script
scaricati dalle pagine web.Sono state raccolte le sorgenti dei tag script delle pagine
web dei siti SPID e sono stati analizzati le architetture dei server da cui veniva
scaricato uno script. Script scaricati dallo stesso server da cui proveniva la pagina
web o che fossero entro un tag IFRAME non sono stati considerati. Anche nel caso
dei siti SPID è importante questa analisi per evidenziare se ci sono attacchi che
possono sfruttare script di terzi per colpire gli utenti dei servizi degli SPID provider.
La lista di server da cui viene scaricato uno script è riportata in tabella 7.7.
SPIDwebsite Script_domain HTTPS
classification
Purpose
posteid.poste.it tags.bkrtx.com no_redirect gathering
marketing data
posteid.poste.it assets.adobedtm.com no_redirect Manage
marketing tag
posteid.poste.it tags.bluekai.com https_strip track consumer
41

behavior
posteid.poste.it consent.trustarc.com no_redirect Cookie consent
manager
identity.sieltecloud.it www.google-analytics.com https_strip analytics
identity.sieltecloud.it use.fontawesome.com no_redirect gives scalable
vector icons
spid.register.it v2.zopim.com https_strip Chat with
consumer
spid.register.it www.googletagmanager.com no_redirect web tracking
spid.register.it cmp.teamblue.services https_strip cookie
management
spid.register.it code.jquery.com no_redirect javascript
library
spid.register.it consent.cookiebot.com https_strip cookie
management
spid.register.it widget.trustpilot.com secure+almost widget to show
a review
spid.register.it maxcdn.bootstrapcdn.com no_redirect boostrap for
web
development
Tabella 7.7 Server da cui sono stati scaricati degli script per le pagine di autenticazione degli SPID
In tabella 7.7 sono riportati in ordine di colonne: i siti SPID che scaricano lo
script da terzi, il dominio web da cui è scaricato lo script, la suddivisione in categorie
dei server da cui viene scaricato uno script, le categorie sono le stesse di tabella 4.1,
e lo scopo per cui sono scaricati gli script.
Come si può vedere dall’ultima colonna generalmente questi script vengono
scaricati per la gestione dei cookies e il loro consenso o per l’analisi dell’attività degli
utenti.
Dalla prima colonna si può vedere che sono solo tre i siti SPID che scaricano
degli script da server di terzi. Questo fatto è positivo perché come spiegato in
precedenza un attaccante può sfruttare questi script di terzi per colpire gli utenti di
un servizio. È da sottolineare che comunque gli script scaricati non sono script usati
ai fini della funzionalità effettiva del servizio. Di conseguenza la dipendenza da
queste terze parti potrebbe essere evitata e gli utenti potrebbero ancora usufruire del
servizio.
Si può notare dalla categorizzazione dei server che la metà di questi non solo
non implementa la Strict Transport Security policy ma non fa una redirection da
42

HTTP a HTTPS quando si tenta di connettersi con questi server. Questo aspetto è in
linea con quanto visto per l’analisi degli script scaricati del primo gruppo di siti
analizzato. Anche qui il fatto che non ci sia redirezione verso HTTPS fa sì che un
attacco di tipo SSLStrip possa essere portato a termine anche dopo successive
richieste HTTP da parte di un browser. Come visto in precedenza, però, se si accede
al sito tramite HTTPS anche se uno script dovesse essere scaricato tramite HTTP
questo verrebbe bloccato dal browser data la presenza di mixed content nella pagina
web.
In tabella 7.8 sono riportati quali architetture delle reti dove si trovano i server
da cui sono scaricati degli script soddisfano o no il criterio di ridondanza per le
network e gli autonomous system.
Group Direct_zone Network redundancy AS redundancy
PosteID bkrtx.com. Non soddisfa Non soddisfa
PosteID adobedtm.com. Più che soddisfa Più che soddisfa
PosteID bluekai.com. Non soddisfa Non soddisfa
PosteID trustarc.com. Non soddisfa Non soddisfa
Sieltecloud google-analytics.com. Non soddisfa Non soddisfa
Sieltecloud fontawesome.com. Non soddisfa Non soddisfa
Register zopim.com. Non soddisfa Non soddisfa
Register googletagmanager.com. Non soddisfa Non soddisfa
Register teamblue.services. Soddisfa Soddisfa
Register jquery.com. Più che soddisfa Non soddisfa
Register cookiebot.com. Soddisfa Non soddisfa
Register trustpilot.com. Non soddisfa Non soddisfa
Register bootstrapcdn.com. Più che soddisfa Non soddisfa
Tabella 7.8 ridondanze di network e autonomous system
Dalla tabella 7.8 si vede come ci sia poca ridondanza in network e
autonomous system rispetto al caso dei server degli script analizzati per il primo
gruppo di siti, tabella 6.10. Questo significa che se un attacco colpisce le network in
cui sono presenti i nameserver delle zone dirette dei siti da cui sono scaricati degli
script, l’attaccante può bloccare la risoluzione dei nomi di questi server e rendere gli
script inaccessibili. Al contrario, però, il perimetro da difendere per gli sviluppatori di
questi servizi è minore.
43

Infine, sono riportate in figura 7.1 e 7.2 le dipendenze di network e
autonomous system.
Figura 7.1 Network da cui dipendono i server da cui sono scaricati degli script
Figura 7.2 Autonomous system da cui dipendono i server da cui sono scaricati degli script
In figura 7.1 ogni barra corrisponde ad una network, la sua altezza indica
quante zone dirette hanno almeno un nameserver in tale network. In figura 7.2 ogni
barra rappresenta un autonomous system e l’altezza è il numero di zone dirette che
hanno almeno un nameserver in una network gestita da tale autonomous system, le
zone dirette sono le stesse della seconda colonna di tabella 7.8 divise per gruppo.
44

Come era per le figure 6.2 e 6.3 anche qui ci sono alcune network e due
autonomous system su cui dipende più di una zona. Questo comunque indica che
un attacco ad una network può impedire la risoluzione dei nomi di più di uno dei
server da cui si scarica lo script. In alternativa un attaccante che ha il controllo di
queste network può rispondere a richieste dns per più di uno dei domini web da cui
un browser cerca di scaricare uno script, direzionando il browser a connettersi con
un indirizzo IP errato, potenzialmente un server controllato dall’attaccante.
Anche in questo caso è stato verificato se gli script avessero l’attributo
integrity, ma nessuno lo aveva, in modo analogo al caso per il primo gruppo di siti
analizzati.
Sezione 5 - Riepilogo analisi
Viene riportato un riepilogo sintetico dell’analisi dei siti SPID:
● La distribuzione dei nameserver delle zone dirette in cui si trovano i nomi dei
siti SPID è varia. Alcune zone hanno nameserver distribuiti su diverse
network altre no.
● I nameserver di zone diverse comunque non si trovano nelle stesse network,
tranne nel caso di sieltecloud.it. e register.it.
● Non tutti gli autonomous system che gestiscono le network delle zone dirette
implementano il BGP ROA per le loro network. Alcuni autonomous system
implementano questa policy solo per alcune delle network che gestiscono.
● La maggior parte dei siti SPID non implementano la Strict Transport Security
policy. Gli unici siti che lo fanno sono: identity.infocert.it, id.lepida.it e
idp.namirialtsp.com.
● I siti SPID non sono replicati su diversi indirizzi IP, tranne nel caso di
posteid.poste.it. Le repliche di quest’ultimo, comunque, si trovano tutte in una
stessa network.
● Solo tre dei siti SPID scaricano script da terzi. Questi tre siti sono:
posteid.poste.it, identity.sieltecloud.it e spid.register.it. Gli script scaricati non
sono comunque essenziali per le funzionalità del servizio di questi siti, e
quindi sono script di i siti potrebbero fare a meno.
● Nessuno degli script scaricati viene verificato grazie all’attributo integrity.
● Alcune zone dei siti da cui sono scaricati degli script hanno nameserver che si
trovano nella stessa network.
Conclusione
L’obiettivo di questa tesi era quello di fare un analisi per evidenziare aspetti
discutibili dell’architettura delle reti in cui si trovano i server dei siti, i nameserver per
la risoluzione dei nomi di questi siti e i server da cui vengono scaricati degli script da
questi siti.
45

L’analisi svolta ha evidenziato che c’è molta differenza nell’architettura delle
reti dei server. Per quanto riguarda le repliche, la distribuzione dei nameserver su
diverse network gestite da diversi autonomous system è varia da zona a zona, non
c’è una linea d’azione comune. Anche per quanto riguarda la verifica delle route di
un autonomous system, non per tutte le network viene implementato il BGP ROA, e
questo vale indipendentemente che si parli di un sito SPID o no.
Riguardo all’accesso ai siti, lo studio ha sottolineato che i server dei siti SPID
non sono replicati su diversi indirizzi IP, tranne nel caso di Poste ID, e comunque
anche queste repliche si trovano in una stessa network. Inoltre, la maggior parte dei
siti SPID non applica la Strict Transport Security policy, rendendo questi siti
vulnerabili ad attacchi di tipo SSLStrip.
Riguardo alla dipendenza dei siti da script di terzi, solo tre siti SPID scaricano
script da altri server. Questo aspetto è positivo per i siti che non dipendono da terzi
per scaricare script e non rischiano che i browser degli utenti scarichino script di cui
gli sviluppatori del sito non hanno il controllo. D’altro canto è negativo per i tre siti
che scaricano almeno uno script da terzi, soprattutto dato che non è presente nei tag
script l’attributo integrity, e quindi questi script non sono verificabili.
Concentrandosi sulle differenze tra i siti dello SPID e quelli presi in
considerazione per un confronto con essi, le principali sono due. La prima è che
sono pochi i siti SPID che implementano la Strict Transport Security policy rispetto al
primo gruppo. La seconda è che nonostante sia abbastanza vario da zona a zona
avere diversa ridondanza, nel caso dei siti SPID solo uno di questi ha delle repliche
dei server su diversi indirizzi IP, e i server di tutti i siti SPID si trovano in una network,
rendendo il perimetro da difendere più piccolo rispetto ai casi del primo gruppo di siti.
46

Analisi delle dipendenze architetturali dei servizi di autenticazione SPID

Recommended

Recommended

More Related Content

Similar to Analisi delle dipendenze architetturali dei servizi di autenticazione SPID

Similar to Analisi delle dipendenze architetturali dei servizi di autenticazione SPID (20)

Recently uploaded

Recently uploaded (10)

Analisi delle dipendenze architetturali dei servizi di autenticazione SPID