1. `
Universita degli studi di Trieste
`
Facolta di Ingegneria
Tesi di Laurea in
Ingegneria dell’Informazione
curriculum informatica
Progetto e Realizzazione di un Software per la
Rilevazione Automatica di Codice HTML
Nascosto e Fraudolento in Pagine Web
Relatore Candidato
Prof. Alberto Bartoli Daniele Nicassio
Correlatore
Ing. Enrico Sorio
Anno Accademico 2011/2012

3. `
Universita degli studi di Trieste
`
Facolta di Ingegneria
Tesi di Laurea in
Ingegneria dell’Informazione
curriculum informatica
Progetto e Realizzazione di un Software per la
Rilevazione Automatica di Codice HTML
Nascosto e Fraudolento in Pagine Web
Relatore Candidato
Prof. Alberto Bartoli Daniele Nicassio
Correlatore
Ing. Enrico Sorio
Anno Accademico 2011/2012

5. Ai miei genitori

7. Indice
1 Introduzione 7
2 Scenario 9
2.1 Scopo del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Tipo di attacco “Hidden Text Injection” . . . . . . . . . . . . . . . . . . . 9
2.2.1 Modalit` di realizzazione . . . .
a . . . . . . . . . . . . . . . . . . . 9
2.2.2 Finalit` . . . . . . . . . . . . . .
a . . . . . . . . . . . . . . . . . . . 10
3 Progettazione 13
3.1 Struttura del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Panoramica della soluzione progettata . . . . . . . . . . . . . . . . 13
3.1.2 Compilazione della lista di pagine web . . . . . . . . . . . . . . . . 13
3.1.3 Analisi di una singola pagina . . . . . . . . . . . . . . . . . . . . . 15
3.2 Metodo DOM e OCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Confronto risultati DOM e OCR . . . . . . . . . . . . . . . . . . . 17
3.2.3 Limiti degli algoritmi OCR (Optical Character Recognition) . . . 17
3.3 Metodo DOM e Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.1 Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2 Problematiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.3 Limitazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.4 Panoramica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Limitazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.1 Limitazioni dovute all’analisi dello screenshot . . . . . . . . . . . . 20
3.4.2 Testo nelle immagini . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Implementazione 23
4.1 Tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1 Hibernate JPA (Java Persistence API) . . . . . . . . . . . . . . . . 24
4.1.2 Selenium WebDriver . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.3 Scelta del software OCR . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.4 Google Drive OCR . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5

8. 4.2.1 Entit` / Classi JPA . . . . . . . . . .
a . . . . . . . . . . . . . . . . 25
4.3 Struttura Classi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.1 GoogleCrawler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.2 WebDriverController . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.3 Snapshotter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.4 JSColorizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.5 Analisi dei risultati del software OCR . . . . . . . . . . . . . . . . 37
4.3.6 Supporto Ground Truth . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Risultati 39
5.1 Raccolta dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.1 Analisi degli snapshot . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Rilevazione testo nascosto . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 Analisi dei falsi positivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.1 Metodo DOM e OCR . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.2 Metodo DOM e Javascript . . . . . . . . . . . . . . . . . . . . . . . 43
5.4 Confronto metodi proposti . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.4.1 Precision & Recall . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.4.2 Tempi di esecuzione . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4.3 Considerazioni sui risultati . . . . . . . . . . . . . . . . . . . . . . 45
5.5 Utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.5.1 Pacchetto Jar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6 Conclusioni 47
6.1 Obiettivi raggiunti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Ringraziamenti 49
6

9. Capitolo 1
Introduzione
Gli attacchi “Hidden Text Injection” sono attacchi informatici diffusi recentemente che
colpiscono l’integrit` dei siti web: essi consistono nell’inserimento, all’interno delle pagine
a
web interessate, di testo nascosto. Gli attacchi di questo tipo consentono la realizzazione
di tecniche fraudolente come la “Search Redirect” e la “Search Spam”, tecniche volte alla
manipolazione dei risultati dei motori di ricerca.
L’attacco risulta particolarmente difficile da individuare poich` non apporta modifiche
e
visibili alle pagine, e spesso gli stessi amministratori del sito ignorano di essere stati
colpiti, rendendo l’attacco molto persistente nel tempo.
L’introduzione di testo nascosto nelle pagine web ` una pratica di Search Engine Op-
e
timization considerata illecita dalla maggior parte dei motori di ricerca, e per questo
motivo le pagine web sottoposte all’attacco corrono il rischio, se rilevate, di essere ri-
mosse dai risultati di ricerca.
Considerata questa premessa, questa tesi riguarda l’ideazione e la realizzazione di un
software per la rilevazione automatizzata degli attacchi informatici di tipo “Hidden Text
Injection”.
Lo sviluppo del software si ` concentrato particolarmente sulla creazione di un sistema
e
per la valutazione della visibilit` del testo nella pagina. La relativa analisi ha portato alla
a
realizzazione di due metodi distinti per la risoluzione del problema: il primo metodo, che
utilizza un’analisi OCR, ` stato proposto come soluzione al momento dell’assegnazione
e
del progetto, mentre il secondo metodo ` stato da me ideato durante la fase di proget-
e
tazione. Entrambi i metodi si sono poi dimostrati soddisfacenti in fase di test.
Pi` in dettaglio, il software sviluppato ` in grado di compilare una lista di pagine web
u e
sospettate di essere vittima dell’attacco, ed in seguito di classificarle utilizzando i due
metodi sviluppati per l’individuazione di testo nascosto.
Il progetto ` stato realizzato presso il laboratorio Machine Learning del D.I.A. del-
e
l’Universit` degli Studi di Trieste. Poich` il progetto ha visto l’integrazione di un com-
a e
ponente precedentemente sviluppato presso il laboratorio, per motivi di compatibilit` ` ae
stato richiesto che il progetto si avvalesse delle seguenti tecnologie software:
7

10. • Linguaggio di programmazione Java
• Librerie Hibernate JPA 1.0 per l’Object-Relational Mapping
• Software DBMS MySql per la gestione del database
• Librerie Selenium WebDriver per pilotare il browser in modo programmatico
Il capitolo “’Scenario” fornisce una panoramica un pi` dettagliata sul problema analiz-
u
zato e sullo specifico attacco considerato.
Nel capitolo “Progettazione” si descrivono le principali fasi dell’ideazione e della proget-
tazione del software.
Il capitolo “Implementazione” descrive la fase di realizzazione dell’applicativo, con par-
ticolare attenzione alle problematiche di tipo implementativo riscontrate.
Il capitolo “Risultati” contiene la presentazione e la discussione dei risultati ottenuti dal-
l’esecuzione del software.
Infine il capitolo “Conclusioni” presenta le considerazioni che seguono l’analisi dei risul-
tati.
8

11. Capitolo 2
Scenario
2.1 Scopo del progetto
Lo scopo del progetto consiste nell’ideazione e realizzazione di un sistema automatizzato
che consenta di rilevare attacchi informatici di tipo “Hidden Text Injection”. Il sistema
individua ed in seguito analizza una lista di pagine web che possono essere vittima
di questo tipo di attacco. Si ` quindi realizzato un sistema capace di individuare,
e
all’interno del codice di una pagina web, porzioni di testo nascoste volontariamente alla
vista dell’utente (“Hidden Text Injection”).
2.2 Tipo di attacco “Hidden Text Injection”
2.2.1 Modalit` di realizzazione
a
L’attacco informatico denominato“Hidden Text Injection”consiste nell’inserimento frau-
dolento di parti di codice HTML1 , in particolare link o testo, all’interno di pagine web
vittime. Questo codice viene inserito all’interno della pagina web attaccata in modo che
il testo o i link iniettati non siano visibili a chi visita la pagina. Ci` rendendo difficile
o
l’individuazione dell’attacco senza un’analisi del codice sorgente interessato.
Il testo o i link possono essere nascosti alla vista dell’utente in vari modi, ad esempio con
un posizionamento nella pagina con coordinate negative, in modo da essere al di fuori
della parte della pagina che il browser visualizza, oppure ancora scrivendo con colore
`
bianco su uno sfondo bianco ecc. E utile notare che tutte queste tecniche di occulta-
mento sono quasi sempre considerate dal motore di ricerca Google illecite2 e possono
portare, se rilevate, alla rimozione del sito dai risultati di ricerca.
Questo ` un notevole fattore di rischio per chi ` vittima di attacchi di questo tipo, che
e e
sono in questo senso molto pericolosi proprio perch` difficili da individuare, e che possono
e
costituire un danno importante per un dominio nel momento in cui esso viene rimosso
dai risultati di ricerca.
1
http://en.wikipedia.org/wiki/HTML
2
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=35769#3
9

12. 2.2.2 Finalit`
a
Le tecniche di “Hidden Text Injection” possono essere suddivise a seconda del tipo di
codice iniettato:
1. Inserimento di link nascosti
2. Inserimento di testo nascosto
Entrambe le tecniche fanno parte dell’insieme dei metodi denominati di “Spamdexing”3 ,
metodi volti alla manipolazione dei risultati dei motori di ricerca, poich` puntano a
e
modificare in modo illecito la rilevanza di una determinata pagina web all’interno dei
ranking dei motori di ricerca.
Nonostante il problema dell’inserimento di codice aggiuntivo nel sorgente originale sia lo
stesso, e le tecniche con cui viene realizzato siano svariate e non rientrino negli scopi di
questo documento, le modalit` e le finalit` dell’attacco differiscono in modo sostanziale
a a
tra i due casi appena citati che saranno presentate brevemente nei paragrafi seguenti.
Introduzione di codice contenente link nascosti
I motori di ricerca, per assegnare un punteggio ad ogni pagina web, implementano deter-
minati algoritmi volti a valutarne il contenuto. Questi algoritmi assegnano un punteggio
ad ogni pagina a seconda di una serie di fattori, tra i quali solitamente il numero di link
che dirigono a quella determinata pagina. Ognuno di questi link incrementa il punteggio
totale proporzionalmente al punteggio della pagina sulla quale il link risiede, dando cos` ı
pi` importanza ai link che si trovano su pagine con punteggio pi` elevato e, di con-
u u
seguenza, in genere pi` autorevoli.
u
L’attacco“Hidden Links Injection”consiste nell’inserimento fraudolento di link che riferiscono
a un determinato sito in pagine web di altri domini.
Il motore di ricerca Google, ricercando all’interno delle pagine attaccate link e testo, tro-
va molti link che puntano a questo stesso sito, e ne incrementa l’importanza all’interno
dei suoi database. In questo modo, la rilevanza attribuita al sito dal motore di ricerca
sale, ottenendo un miglior posizionamento nei risultati di ricerca.
Inoltre, poich` i motori di ricerca come Google considerano anche la pagina che ospita il
e
link per il calcolo del punteggio, un attaccante preferir` introdurre questi link su siti pi`
a u
autorevoli, guadagnando visibilit` sui motori di ricerca in modo pi` veloce ed efficace.
a u
Introduzione di codice contenente testo nascosto
I motori di ricerca, per indicizzare una pagina, analizzano il suo codice e ne estraggono
le parti di testo al suo interno. Poich´ si occupano di valutarne soltanto il contenuto,
e
non utilizzano le informazioni sullo stile fornite nella pagina, e non distinguono tra testo
visibile e non visibile.
L’attacco analizzato consiste nell’introduzione, all’interno del codice HTML originario,
3
http://en.wikipedia.org/wiki/Spamdexing
10

13. di semplici porzioni di codice contenenti testo non visibile, in modo che i visitatori del
sito non si accorgano della modifica.
In questo caso i motori di ricerca, analizzando il codice della pagina, trovano delle pa-
role chiave che sono state inserite in questo modo, e assegnano un posizionamento nei
risultati di ricerca anche a seconda di questi termini, in modo che una ricerca di questi
ultimi restituisca tra i vari risultati anche il sito attaccato.
Una possibile finalit` di questo tipo di attacco ` la “SearchRedirection”4 , in cui l’at-
a e
taccante introduce anche uno script che redirige gli utenti che provengono dal motore
di ricerca verso una pagina diversa, che trae vantaggio dall’attacco con il conseguente
aumento di visibilit`. Lo script si cura di reindirizzare alla pagina designata soltanto
a
gli utenti che provengono dal motore di ricerca e che hanno ricercato le parole chiave
aggiunte nel testo nascosto, in modo tale da non insospettire gli utenti legittimi della
pagina.
In questo modo l’attaccante sfrutta l’autorevolezza e l’affidabilit` del sito vittima intro-
a
ducendo delle nuove parole chiave per le quali poi si ` reindirizzati su una pagina diversa,
e
che spesso ` relativa ai termini ricercati, e rende il sistema molto difficile da individuare.
e
4
http://static.usenix.org/events/sec11/tech/full papers/Leontiadis.pdf
11

14. 12

15. Capitolo 3
Progettazione
3.1 Struttura del progetto
Il sistema si compone di due macro-blocchi: il primo compila una lista di pagine web
candidate, il secondo applica l’algoritmo che individua quali sono vittima di un attacco
“Hidden Text Injection”.
Uno schema delle fasi principali del progetto si pu` vedere in figura 3.1.
o
3.1.1 Panoramica della soluzione progettata
Le principali fasi affrontate dal progetto e raffigurate in fig. 3.1 svolto sono le seguenti:
1. Compilazione di una lista di pagine web, tramite specifiche ricerche sul motore di
ricerca Google.
2. Recupero pagine web, e salvataggio su file del codice e dello screenshot.
3. Ricerca del testo cercato nel codice HTML del DOM
4. Analisi del testo visibile nello screenshot, attuata attraverso uno dei due metodi
che verranno esposti nel corso di questo capitolo.
5. Confronto dei risultati per valutare la presenza di testo nascosto, che si ha quando
la ricerca nel DOM ha dato esito positivo mentre l’analisi dello screenshot non ha
rilevato la presenza del testo cercato.
3.1.2 Compilazione della lista di pagine web
La compilazione della lista di pagine web da analizzare ` stata svolta attraverso ricerche
e
mirate con il motore di ricerca Google, che ` di fatto il principale obiettivo della ma-
e
nipolazione effettuata dall’attacco.
Le stringhe da ricercare sono state scelte cercando gi` a questo punto di effettuare una
a
prima selezione di pagine che hanno una buona probabilit` di aver subito questo tipo di
a
attacco.
13

16. Fig. 3.1: La struttura del progetto
Parametro di ricerca site di Google Search
La parola chiave ‘site:’ nelle stringhe di ricerca di Google ` un parametro che permette
e
di limitare la ricerca effettuata ai siti il cui nome di dominio contiene la stringa che lo
segue. Ad esempio la stringa di ricerca seguente:
1 university site : edu
restituisce tutti risultati di ricerca che corrispondono alla parola ‘university’ limitati ai
domini di primo livello edu.
Stringhe di ricerca
Le stringhe di ricerca sono state scelte per evidenziare delle inconsistenze tra i termini
di ricerca inclusi e i domini nei quali si effettuava la ricerca.
Le stringhe scelte, che utilizzano tutte la parola chiave ‘site:’, sono le seguenti:
1 site : gov . uk viagra
2 site : gov viagra
3 site : gov . au viagra
4 site : mil viagra
5 site : museum viagra
6 site : gov . in viagra
7 site : mil . in viagra
8 site : edu . in viagra
14

17. Fig. 3.2: Il flow chart che rappresenta l’analisi del problema
9 site : edu viagra
Tramite queste stringhe di ricerca si possono trovare molti risultati, e quindi molte pagine
web, che appartengono a domini in cui non ci si aspetta di trovare un elevato numero di
pagine che trattano legittimamente di Viagra. In questo modo ci si aspetta di trovare
nella lista diverse pagine che sono state effettivamente sottoposte ad un attacco “Hidden
Text Injection” .
3.1.3 Analisi di una singola pagina
Una volta ottenuta una lista di pagine web, l’obiettivo ` di decidere, in modo quanto
e
pi` automatizzato possibile, se si ` in presenza di una pagina sottoposta a hidden text
u e
injection.
Il primo passaggio consiste nel controllare se il testo cercato, in questo caso la parola
‘Viagra’, sia presente nel codice della pagina, indipendentemente dal fatto che sia visibile
oppure no. Questo ` necessario perch` non tutte le pagine che Google restituisce dalla
e e
ricerca contengono necessariamente la parola cercata, ad esempio poich` il contenuto
e
della pagina pu` essere stato modificato dopo l’indicizzazione del motore di ricerca.
o
Nel caso in cui la parola non dovesse risiedere nemmeno nel codice della pagina, non
abbiamo motivo di suppore che la pagina in questione sia stata effettivamente attaccata.
Un flow chart di questa fase del progetto ` mostrata in figura 3.2.
e
15

18. Analisi del DOM (Document Object Model) della pagina web
Per ricercare la parola nel codice della pagina, ` stato deciso di procedere con l’analisi
e
del DOM1 , una rappresentazione orientata agli oggetti del codice HTML di una pagina.
Il vantaggio di avvalersi di questo modello, che risiede e viene aggiornato dinamicamente
nel browser, ` che in questo modo si pu` ottenere un listato di codice HTML molto pi`
e o u
vicino a quello che viene di fatto visualizzato dall’utente. Questo accade poich` spesso
e
degli script della pagina web, inclusi nel codice originario, modificano la struttura della
pagina non appena vengono eseguiti ma, cos` facendo, modificano anche la struttura del
ı
DOM, dal quale poi si pu` estrarre il codice HTML aggiornato da analizzare.
o
L’analisi effettuata sul DOM ` quindi un efficace metodo per controllare se il testo
e
ricercato ` presente all’interno della pagina web in considerazione. Da notare che fino ad
e
ora non si ` fatto alcun riferimento alla visibilit` della parola, o del testo, nella pagina
e a
che viene visualizzata dall’utente.
Analisi della parte visibile
Una volta accertato che la parola sia presente nel codice del documento, si deve procedere
ad analizzare la parte visibile della pagina web, per individuare se quest’ultima ` visibile
e
oppure no.
`
E stato ritenuto che, qualora questa fosse presente ma non visibile, la pagina sarebbe
classificata come probabile vittima dell’attacco.
La scelta e lo sviluppo di un metodo per individuare del testo visibile nella pagina web si
` rivelato il punto cardine del lavoro svolto, che ha evidenziato due principali soluzioni:
e
1. Analisi dello screenshot della pagina con un algoritmo OCR per la rilevazione del
testo
2. Applicazione di un metodo basato sull’esecuzione di uno script Javascript ed una
successiva analisi specifica dello screenshot
3.2 Metodo DOM e OCR
3.2.1 Idea
Il primo metodo proposto consiste nell’esecuzione dei seguenti task:
1. Ricerca della parola nel DOM
2. Analisi dello screenshot della pagina con un software OCR
3. Confronto dei risultati
1
http://en.wikipedia.org/wiki/Document Object Model
16

19. 3.2.2 Confronto risultati DOM e OCR
Una volta ottenuti dei risultati dall’analisi dell’immagine con il software OCR, si verifica
se la parola cercata ` presente nel codice del DOM ma non nel testo riconosciuto nello
e
screenshot.
In questo caso la pagina sar` considerata una probabile vittima di un attacco Hidden
a
Text Injection.
3.2.3 Limiti degli algoritmi OCR (Optical Character Recognition)
Gli algoritmi OCR2 , appartenenti agli algoritmi di “pattern recognition”, consentono
l’estrazione del testo contenuto in un’immagine. Questi algoritmi sono stati progettati
principalmente per la digitalizzazione di testi stampati con parti di testo omogenee, e si
sono dimostrati affidabili in questo tipo di applicazione.
Se l’accuratezza di questi algoritmi fosse molto buona anche nel caso considerato da
questo progetto, questo metodo si rivelerebbe ideale per risolvere il problema dell’indi-
viduazione della parola cercata nel testo visibile della pagina.
Tuttavia, nonostante lo screenshot di una pagina web contenga quasi esclusivamente tipi
di carattere (font) digitali, la diversit` delle dimensioni dei caratteri e il gran numero di
a
variet` di colori nelle pagine web possono abbassare di molto l’efficacia di questi algorit-
a
mi. Per questo motivo si ` resa necessaria una piccola ricerca tra i pi` comuni software
e u
OCR per la scelta di quello che si sarebbe dimostrato pi` accurato nella rilevazione di
u
testo anche in un contesto non ottimale per gli algoritmi di questo tipo.
Un ulteriore svantaggio dell’uso degli algoritmi OCR risiede nel fatto che questi sono in
genere molto dispendiosi dal punto di vista computazionale, insieme alla maggior parte
di quelli della famiglia pattern recognition.
3.3 Metodo DOM e Javascript
3.3.1 Idea
Il metodo introduce l’utilizzo di un algoritmo da me ideato per la rilevazione del testo
visibile nella pagina.
Il concetto alla base dello sviluppo dell’algoritmo ` stata la trasformazione del problema
e
di ricerca del testo in un’immagine in un problema pi` analitico, non soggetto alle limi-
u
tazione del software OCR.
Un software non pu` leggere un testo da un’immagine con facilit`, cio` capire se l’in-
o a e
sieme dei pixel trovati rappresenta una lettera oppure un disegno, ma pu` facilmente
o
iterare attraverso milioni di pixel alla ricerca di un codice prestabilito che rappresenti,
per esempio, un determinato colore, e lo pu` fare in pochi secondi.
o
Da qui l’idea di marcare la porzione di pagina interessante (cio` il testo da individ-
e
uare) con un colore univoco, in modo che un software possa facilmente individuare la
2
http://en.wikipedia.org/wiki/Optical character recognition
17

20. modifica. In questo modo il software ` in grado di individuare nella pagina la parola
e
cercata, solo se visibile anche nella pagina originale.
3.3.2 Problematiche
Ci` che ` stato descritto nel paragrafo precedente non ` per` del tutto esatto, in quanto
o e e o
esistono delle considerazioni preliminari che vanno affrontate prima di poter approcciare
il problema con questo tipo di soluzione.
Occultamento di testo per mezzo del colore del font
La prima considerazione consiste nel fatto che per poter evidenziare il testo si deve ap-
portare una modifica alla pagina originale, e affinch` questo non interferisca con gli scopi
e
dell’algoritmo, questa non deve alterare la condizione di visibilit` del testo su cui ` ef-
a e
fettuata.
Infatti, modificando il colore del testo, si perdono tutte le informazioni relative all’oc-
cultamento attraverso particolari colori del font, cio`:
e
• Colore del font trasparente
• Colore del font uguale al colore dello sfondo
Questi due casi andranno quindi individuati specificamente prima di apportare le mod-
ifiche alla pagina originale, che porterebbero ad un’inevitabile perdita di queste infor-
mazioni.
Scelta del colore univoco
La seconda considerazione si riferisce alla scelta di un colore univoco con il quale eviden-
ziare la parola o il testo da rilevare. Perch` l’algoritmo funzioni in modo corretto, ` nec-
e e
essario che nemmeno un pixel dell’immagine analizzata presenti il codice corrispondente
al colore individuato come univoco. Bench´ lo spettro elettromagnetico delle frequenze
e
del visibile sia da un punto di vista fisico uno spettro continuo, che corrisponde in pratica
ad un numero illimitato di colori, ` ben noto che non esiste modo di rappresentare infiniti
e
colori in un numero limitato di bit, che ` quello di cui si dispone quando si modellizzano
e
i colori in un computer.
Visto che il numero di colori effettivamente utilizzabili in una pagina web ` quindi limita-
e
to, ` teoricamente possibile che non esista un colore univoco in una determinata pagina
e
web.
In teoria infatti, non sarebbe difficile creare un’immagine che rappresenti tutti i possibili
colori che il codice HTML permette di rappresentare. Essa dovrebbe avere un numero
di pixel pari al numero di colori disponibili, che nel modello RGB sono
224 = 16777216
contenuti ad esempio in un immagine di 4096x4096 pixel.
18

21. 3.3.3 Limitazioni
Una limitazione nota di questo approccio ` l’impossibilit`, per uno script del tipo de-
e a
scritto, di rilevare del testo contenuto all’interno di immagini della pagina web. Queste
infatti non sono elementi testuali e la ricerca delle occorrenze di testo nel codice HTML
della pagina non pu` fornire alcun risultato per questi elementi. Alla luce di questo fatto,
o
` stato ritenuto ragionevole, anche per motivi implementativi, coprire tutte le immagini
e
presenti con un unico colore prestabilito, in modo da ridurre il numero di colori utilizzati
e rendere pi` facile la ricerca di colore univoco.
u
3.3.4 Panoramica
Anche questo metodo prevede l’analisi del DOM per la ricerca della parola nel codice, e,
nel caso la parola venga individuata, procede con l’analisi della parte visibile. In questo
caso attraverso un’elaborazione della pagina per mezzo di uno script che implementa le
operazioni e le soluzioni alle relative problematiche descritte nei paragrafi precedenti:
1. Ricerca tutti gli elementi che nella pagina web rappresentano un’immagine e li
oscura con un colore unico
2. Itera attraverso tutti gli elementi della pagina web ricercando un colore che non `
e
mai stato utilizzato nella pagina
3. Trova tutte le occorrenze della parola nella pagina
4. Si occupa di rilevare, tra le occorrenze della parola individuate, se la parola `
e
occultata con uno dei seguenti metodi
• Testo trasparente
• Testo dello stesso colore dello sfondo
5. Evidenzia con il colore determinato al punto 2 tutte le rimanenti occorrenze della
parola
Dopo l’esecuzione dello script, si analizza lo screenshot della pagina, il cui aspetto ` stato
e
probabilmente modificato dallo script, e si stabilisce se al suo interno ` presente il colore
e
con cui lo script ha evidenziato la parola ricercata.
Se il colore viene individuato, la parola viene considerata visibile, almeno in parte, nella
pagina web originale. Se invece esso non viene individuato, ma un’occorrenza della
parola ` stata rilevata all’interno del codice della pagina, questa sar` classificata da
e a
questo metodo come vittima dell’attacco “Hidden Text Injection”.
Un esempio di pagina elaborata dallo script si pu` vedere in figura 3.3, in cui si vede la
o
pagina con le immagini coperte di nero e le parole individuate evidenziate con un colore
univoco.
19

22. Fig. 3.3: Un’esempio di pagina elaborata dallo script
3.4 Limitazioni
Gli algoritmi proposti presentano delle limitazioni, che potranno essere prese in consider-
azione in eventuali sviluppi futuri del progetto. Le principali sono descritte nei paragrafi
seguenti.
3.4.1 Limitazioni dovute all’analisi dello screenshot
L’analisi dello screenshot della pagina web ` stata presa in considerazione poich´ ` un
e ee
eccellente metodo per osservare e analizzare esattamente quello che l’utente si trova
davanti quando visualizza la pagina web. Esso ` stato sfruttato per cercare di capire
e
quali parti di testo vengono visualizzati e quali altri no, ricercando la loro presenza
all’interno di quest’immagine.
Esiste per` un problema di fondo in questo approccio: le pagine web possono contenere
o
delle parti o dei componenti interattivi, cio` che reagiscono ad un input dell’utente
e
modificando in qualche modo l’output della pagina, ovvero il suo contenuto o la sua
struttura. Alcuni di essi, come ad esempio i link, non rappresentano un problema per
gli algoritmi considerati, poich´ prevedono l’indirizzamento ad una pagina diversa.
e
20

23. ScrollBar
Esistono altri componenti che per` prevedono una modifica della struttura o dei contenuti
o
visivi rimanendo nel contesto della stessa pagina: tra i pi` comuni componenti di questo
u
tipo troviamo le scrollbar, di cui un esempio riscontrato durante la raccolta dei risultati
si pu` vedere in figura 3.4.
o
Fig. 3.4: Screenshot che evidenzia uno dei limiti degli algoritmi proposti
Script
Un’altra componente delle pagine web che pu` operare in questo modo sono gli script.
o
Gli script possono essere utilizzati per nascondere contenuti di secondaria importanza e
mostrarli solo quando l’utente manifesta un interesse specifico, ad esempio premendo su
un pulsante o su un link, o eseguendo qualche tipo di azione che il browser intercetta.
Questo genere di script potrebbe di fatto nascondere del testo o dei link relativi ad un
certo argomento (come ad esempio il Viagra) e mostrarli successivamente solo quando
l’utente preme su un apposito pulsante, portando erroneamente gli algoritmi analizzati
a classificare la pagina come “possibile vittima”.
3.4.2 Testo nelle immagini
Un altra limitazione, che interessa solo il secondo metodo proposto, quello DOM e
Javascript, ` che lo script si limita a ricercare e rilevare il testo contenuto nel codice
e
HTML della pagina e quindi non all’interno delle immagini. La ricerca infatti si limita
agli elementi che contengono del testo, mentre la ricerca in un’immagine richiederebbe
21

24. inevitabilmente un’analisi da parte di un algoritmo OCR, che nel metodo considerato si
` voluto evitare.
e
22

25. Capitolo 4
Implementazione
Fig. 4.1: Uno schema delle funzioni del software progettato
4.1 Tecnologie utilizzate
Per lo sviluppo del progetto sono state utilizzate una serie di tecnologie software che
hanno svolto alcune funzioni del progetto in modo indipendente.
Di seguito se ne elencano le principali.
23

26. 4.1.1 Hibernate JPA (Java Persistence API)
Java Persistence API1 ` un framework che permette la gestione di un database relazionale
e
dall’ambiente di programmazione Java. Esso consente di salvare o caricare oggetti Java
dal database direttamente attraverso l’interfaccia fornita.
La specifica implementazione utilizzata in questo progetto ` Hibernate JPA 1.0.
e
4.1.2 Selenium WebDriver
Selenium WebDriver ` un API che permette di controllare il browser dal linguaggio di
e
programmazione. L’API mette a disposizione dei metodi che consentono ad esempio di
eseguire il browser, recuperare e visualizzare una pagina, salvare uno screenshot oppure
iniettare del codice Javascript in una pagina precedentemente caricata.
In particolare in questo progetto la libreria ` stata utilizzata per controllare il browser
e
Mozilla Firefox.
4.1.3 Scelta del software OCR
Per la scelta del software OCR si ` resa necessaria una piccola ricerca preliminare, per
e
valutare quale software ottenesse risultati pi` soddisfacenti se usato con immagini di
u
pagine web, in condizioni non standard per il software di questo tipo.
Sono stati presi in considerazione tre principali alternative, tutte liberamente utilizzabili:
• Cuneiform OCR
• Ocropus
• Google Drive OCR
I primi semplici test su un set limitato di pagine web sottoposte hanno mostrato un
evidente superiorit` del software di Google, dando risultati deludenti nel caso degli altri
a
due software proposti. A differenza dei primi due, il motore OCR di Google Drive ` e
probabilmente quello pi` adatto alla scansione di un’immagine pi` eterogenea: questo
u u
` fondamentale quando si tratta con documenti con una grande variet` di font e colori,
e a
come nel caso di questo progetto.
4.1.4 Google Drive OCR
Il software di riconoscimento ottico di caratteri (OCR) integrato in Google Drive2 ` e
fornito come servizio gratuito per chi dispone di un account Google, e pu` essere eseguito
o
automaticamente sui documenti che vengono caricati sul servizio di cloud storage di
Google. Tutti i risultati possono essere poi scaricati in un unico file compresso al termine
dell’operazione di caricamento, che per` impone dei limiti:
o
• Ogni file caricato non pu` superare i 2 Mb di dimensione
o
1
http://en.wikipedia.org/wiki/Java Persistence API
2
http://en.wikipedia.org/wiki/Google Drive
24

27. Fig. 4.2: Lo schema logico del database implementato
• I file vengono caricati ed elaborati dal software OCR uno alla volta
Il software ` utilizzabile unicamente attraverso il servizio di storage, caricando i file
e
immagine sul server remoto, attendendo il completamento della conversione e scaricando
successivamente i risultati.
4.2 Database
4.2.1 Entit` / Classi JPA
a
Il database ` stato creato utilizzando il DBMS MySql. Lo schema logico delle entit` `
e ae
stato rappresentato in figura 4.2.
Le entit` utilizzate, corrispondenti ad oggetti Java, sono elencate di seguito:
a
• SiteClass(Id, name, source, creationDate)
• Site(Id, url, snippet, isHtml, siteClasss)
• SiteSnapshot(Id, captureStartDate, captureEndDate, imageBaseFilename, images-
Number, ocrFilename, log, domHasWord, imageHasWord, hasColor, wordIsVisi-
ble, site)
• SiteDom(Id, domFilename, siteSnapshot)
4.3 Struttura Classi
4.3.1 GoogleCrawler
GoogleCrawler ` la classe responsabile della compilazione della lista di URL sui quali
e
poi verranno applicati i due metodi proposti per la classificazione dei siti come probabili
vittime dell’attacco o no. Essa rappresenta la prima fase dello schema di fig. 4.1.
Questo componente, sviluppato precedentemente presso il laboratorio Machine Learning
del D.I.A., si occupa di recuperare, per ogni oggetto SiteClass prelevato dal database,
25

28. Fig. 4.3: Diagramma UML della classe Snapshotter
Fig. 4.4: Alcuni diagrammi UML delle restanti classi sviluppate
26

29. un determinato numero di risultati della ricerca sul motore Google della stringa Site-
Class.name .
4.3.2 WebDriverController
La classe WebDriverController si occupa di gestire un’istanza di Firefox, che viene cre-
ata all’interno del costruttore e viene terminata quando la classe conclude i suoi scopi.
Lo scopo principale della classe ` gestire una coda di task da eseguire, in questo caso
e
oggetti della classe Snapshotter, e di eseguirli uno alla volta secondo l’ordine dato. Essa
implementa l’interfaccia Runnable, e viene quindi eseguita in un thread, permettendo
in questo modo di eseguire pi` istanze di Firefox allo stesso tempo per permettere una
u
parallelizzazione del lavoro degli oggetti Snapshotter, che si occupano di ogni singolo url
da prelevare e analizzare. Essa ` composta dal costruttore e da due metodi pubblici:
e
• public void addSnapshotter(Site s, int id)
• public void run()
Il metodo addSnapshotter permette di accodare un nuovo oggetto Site da analizzare
alla lista di task. Sar` proprio in questo metodo che la classe WebDriverController creer`
a a
un nuovo oggetto Snapshotter per l’analisi dell’oggetto Site passato.
L’intero id ` un numero che identifica univocamente l’oggetto Snapshotter associato al
e
Site fornito, e serve per individuare lo Snapshotter all’interno dei file di log.
Il metodo run ` quello che esegue il thread e comincia l’esecuzione, uno alla volta, degli
e
oggetti Snapshotter creati e salvati in una lista.
In questo punto si ` resa necessaria la gestione di due problematiche, che vengono
e
approfondite di seguito:
DriverKiller
E’ stata evidenziata in fase di test una certa instabilit` delle librerie Selenium WebDriver,
a
che consentono di avviare e gestire l’istanza di Firefox utilizzata in questa classe.
Infatti, quando il browser eseguito incontra dei problemi, come ad esempio un server web
che non trasferisce dati dopo aver instaurato la connessione, pu` accadere che l’oggetto
o
Java associato all’istanza del browser blocchi l’esecuzione del codice attendendo di aver
caricato la pagina, cosa che in effetti non accade, bloccando di fatto l’intera esecuzione
del thread.
Per risolvere questo tipo di problemi ` stata progettata un’ulteriore classe denominata
e
DriverKiller, che si occupa di gestire un timeout indipendente e di terminare l’istanza di
Firefox, una volta che esso ` scaduto.
e
All’interno della classe WebDriverController ` stato quindi istanziato un oggetto Timer
e
che allo scadere del timeout esegue il codice di DriverKiller, il quale, dopo aver terminato
il browser, si occupa anche di aggiungere un’occorrenza al log relativo allo Snapshotter
interrotto.
27

30. Firefox Restarter
Come immediata conseguenza della problematica precedente, ` stata evidenziata la ne-
e
cessit`, prima di eseguire uno Snapshotter, di effettuare un controllo sullo stato di es-
a
ecuzione del browser, per verificare se per qualche motivo l’istanza non sia termina-
ta. In effetti sono stati riscontrati diversi casi in cui l’istanza del browser ` terminata
e
inaspettatamente, anche senza l’intervento della classe DriverKiller spiegata precedente-
mente. Si ` quindi reso necessario effettuare un piccolo controllo intercettando l’eccezione
e
BrowserUnreachable:
1 try {
2 driver . get ( " " ) ;
3 } catch ( U n r e a c h a b l e B r o w s e r E x c e p t i o n ex ) {
4 Logger . getLogger ( WebDriverDriver . class . getName () ) . log ( Level .
SEVERE , " My Firefox has been killed ! Creating a new
instance .. " ) ;
5 driver = new FirefoxDriver () ;
6 ...
7 }
Nel caso questa si verificasse, viene creata una nuova istanza del browser e si procede
con l’esecuzione degli oggetti Snapshotter.
4.3.3 Snapshotter
La classe Snapshotter si occupa di caricare la pagina web relativa all’oggetto Site che ha
associato e di creare un nuovo oggetto SiteSnapshot, con tutte le informazioni riguardanti
la pagina analizzata. Inoltre essa salva l’immagine dello screenshot della pagina e i file che
contengono il codice HTML associato al DOM. Infine si occupa di chiamare la funzione
che esegue lo script Javascript per la rilevazione della parola ‘viagra’ nella parte visibile
della pagina.
Questa classe ` il principale componente della seconda funzione rappresentata in fig. 4.1.
e
Si riporta di seguito la lista delle operazioni effettuate dalla classe:
1. Crea una nuova istanza della classe SiteSnapshot
2. Recupera e carica l’URL estratto dalla classe Site associata
3. Controlla se la pagina ` un documento HTML, altrimenti termina la sua esecuzione
e
marcando l’oggetto Site come non-HTML
4. Controlla che Firefox abbia correttamente caricato la pagina, altrimenti termina
la sua esecuzione e scrive una riga sul log
5. Recupera il codice HTML dei DOM presenti nella pagina
6. Ricerca all’interno del codice HTML dei DOM la parola ‘viagra’
7. Salva il contenuto dei DOM della pagina web su file
28

31. 8. Salva il file immagine dello screenshot della pagina, e lo divide in pi` file se la sua
u
dimensione supera i 2Mb
9. Esegue la funzione JSColorizer
10. Salva l’oggetto SiteSnapshot cos` creato nel database
ı
Ci sono stati diversi punti dello sviluppo di questa classe che hanno evidenziato prob-
lematiche notevoli e di seguito vengono esposte le soluzioni adottate.
DOM multipli (frames)
Quando un sito web contiene nel suo codice HTML degli elementi FRAME o IFRAME,
include in questo modo al suo interno una pagina esterna che il browser si preoccuper` a
di caricare e poi integrare, secondo quanto specificato nel codice della pagina originale.
Ognuna di queste pagine esterne, che ha un proprio codice HTML, viene caricata dal
browser assieme alla pagina originale, ma il codice HTML di ogni pagina ` logicamente
e
separato, cos` come il DOM di ognuna di esse.
ı
E’ stato deciso quindi di procedere al salvataggio di un file per ognuno dei DOM disponi-
bili nella pagina web, aggiungendo un’entit` nel database in modo da poter gestire oggetti
a
SiteSnapshot collegati a pi` DOM, cio` a pi` oggetti SiteDom.
u e u
Il codice HTML della pagina originale e di ogni frame ` stato recuperato attraverso il
e
metodo executeScript dell’oggetto FirefoxDriver, che permette di iniettare ed eseguire
codice Javascript nella pagina caricata dal browser, restituendone gli eventuali risultati.
Per prima cosa si ` recuperato il codice della pagina principale iniettando lo script
e
seguente:
1 return " < html > " + document . documentElement . innerHTML + " </ html > " ;
A questo punto ` stato iniettato un secondo script che restituisce tutti gli elementi che
e
rappresentano un frame presenti nella pagina:
1 return document . querySelectorAll ( ’ frame , iframe ’)
Per ognuno di questi si esegue nuovamente il primo script indicato per recuperare il
codice HTML corrispondente, che verr` successivamente salvato su un file.
a
Individuazione dei file non HTML
Il motore di ricerca Google ` in grado di ricercare all’interno di tipi di file anche diversi
e
da pagine web, come ad esempio file PDF, documenti prodotti da Word Processor, Fogli
di calcolo, ecc.
In questo progetto gli unici file che ha senso analizzare sono i file HTML, ovvero le pagine
web, poich` possono essere oggetto dell’attacco in considerazione.
e
Tra i risultati di ricerca ottenuti dalla classe GoogleCrawler, ` anche possibile che es-
e
istano delle occorrenze che non rappresentano pagine web. Queste occorrenze vanno
opportunamente rilevate e marcate per evitare di proseguire l’analisi che risulterebbe
29

32. insensata su tali risorse.
Purtroppo le librerie Selenium WebDriver non mettono a disposizione un sistema per pot-
er analizzare il tipo di documento caricato dal browser; la sola analisi dell’url porterebbe
all’omissione di una serie di risultati, come si pu` vedere da qualche esempio di URL che
o
ha restituito file non HTML nella nostra ricerca, anche se dall’analisi del solo indirizzo
non si sarebbe potuto prevedere:
1. http://www.bury.gov.uk/azservices/ContactDetails.asp?sID=1045
2. http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA460880
3. http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA458864
`
E stato osservato che, quando la risorsa recuperata risulta essere diversa da una pagina
web, il browser apre una finestra di dialogo che propone lo scaricamento del file, lascian-
do il contenuto della finestra principale del browser inalterato rispetto alla situazione
precedente.
Se successivamente si fosse provato a recuperare il codice sorgente della pagina, il metodo
avrebbe restituito quello della pagina precedente, ancora visualizzata dietro alla finestra
di dialogo.
`
E stato quindi possibile rilevare i file non-HTML, modificando appositamente il codice
HTML della pagina immediatamente prima di recuperare la successiva. E’ stato sosti-
tuito il codice con una stringa facilmente riconoscibile, che sarebbe rimasta invariata nel
caso la risorsa successivamente recuperata non fosse stata una pagina web.
1 driver . executeScript ( " document . body . innerHTML = ’" +
improbableString + " ’" ) ;
2 driver . get ( s . getUrl () ) ;
3 if ( driver . getPageSource () . indexOf ( improbableString ) != -1) {
4 ...
5 s . setIsHtml ( Boolean . FALSE ) ;
6 ...
7 }
Splitting degli screenshot di dimensione superiore ai 2 Mb
La classe Snapshotter si occupa, tra le altre funzioni svolte, di salvare uno screenshot
della pagina perch` venga poi analizzato dal software che si occupa della rilevazione del
e
testo visibile (OCR).
Poich` il software che ` stato scelto per questo scopo ` Google Drive OCR, ` stato neces-
e e e e
sario memorizzare le immagini su file che non superino i 2 Mb di dimensione, altrimenti
il software avrebbe rifiutato di analizzare le immagini che non rispettavano questa speci-
fica.
Per risolvere questo problema ` stato sviluppato una parte di codice che permette di
e
30

33. tagliare le immagini di dimensioni superiori in pezzi che non superino i 2 Mb.
Poich` non ` possibile prevedere la dimensione di un’immagine codificata partendo
e e
soltanto dai singoli bytes, l’unica possibilit` ` stata quella di controllare la dimensione
ae
prodotta aumentando ad ogni iterazione l’altezza dell’immagine di un certo HEIGHT STEP,
posto uguale a 1000 pixel.
1 do {
2 // if necessary , splitting big images in two or more parts
3 int h = HEIGHT_STEP ;
4 int last_h ;
5 do {
6 last_h = h ;
7 h += HEIGHT_STEP ;
8 if ( written_height + h > height ) {
9 h = height - written_height ;
10 }
11 } while ( cutAndGetSize ( originalImage , written_height , h ) <=
2048*1024 && last_h != h ) ;
12 cutAndSaveImage ( originalImage , written_height , last_h , prefix +
fileName + i + " . png " ) ;
13 written_height += ( last_h ) ;
14 i ++;
15 } while ( written_height < height ) ;
Timeout, Eccezioni e Log
Il progetto sviluppato ` composto da un elevato numero di funzioni diverse; ` fondamen-
e e
tale quindi, per garantire un efficiente risoluzione dei problemi, avere una buona gestione
dei log degli errori.
Per questo motivo ` stato aggiunto l’attributo privato log nella classe SiteSnapshot in
e
cui risiede il log degli errori relativi a quell’esecuzione associata ad un determinato Site.
`
E stato inoltre introdotto un metodo pubblico appendLog che consente di aggiungere
informazioni al log.
Nella classe Snapshotter ` stato successivamente inserito, all’interno di tutti i blocchi di
e
gestione delle eccezioni, una riga dedicata alla creazione di una voce nel log tramite la
funzione citata, in modo da tenere traccia di tutti i possibili problemi o malfunzionamen-
ti che si possono verificare durante il salvataggio dei file e la creazione di ogni oggetto
SiteSnapshot.
Poich´ il campo log ` parte dell’oggetto SiteSnapshot, che ` una delle entit` del database
e e e a
gestito con la libreria Hibernate JPA, esso viene memorizzato direttamente all’interno
del database, nella riga della tabella che si riferisce allo snapshot relativo, in modo da
risultare di facile consultazione.
31

34. 4.3.4 JSColorizer
JSColorizer ` il metodo di Snapshotter che si occupa di applicare lo script in Javascript
e
per rilevare se la parola in considerazione ` visibile nella pagina web oppure no.
e
Lo script ` in pratica suddiviso in due parti principali, tra le quali viene eseguito un’anal-
e
isi da parte di codice Java, per la rilevazione del caso particolare di occultamento tramite
testo dello stesso colore dello sfondo. Questo metodo trova la sua collocazione nella terza
fase descritta dallo schema di fig. 4.1.
Di seguito saranno analizzate le varie parti del metodo e dello script suddivise per
funzione eseguita.
Immagini oscurate
Come gi` illustrato nel capitolo relativo alla progettazione, lo script copre tutte le im-
a
magini presenti per evitare che esse interferiscano con l’individuazione del colore con cui
successivamente si evidenzieranno le parole interessate.
Per farlo lo script itera attraverso tutti gli elementi img presenti nella pagina e li copre
introducendo nel DOM un elemento div delle stesse dimensioni e con coordinate assolute
identiche in modo da posizionarsi esattamente sopra all’elemento in considerazione:
1 imgs = document . get El eme nts By Tag Na me ( ’ img ’) ;
2 for ( i =0; i < imgs . length ; i ++) {
3 x = getAbsX ( imgs [ i ]) ;
4 y = getAbsY ( imgs [ i ]) ;
5 height = imgs [ i ]. clientHeight ;
6 width = imgs [ i ]. clientWidth ;
7 overdiv = document . createElement ( ’ div ’) ;
8 overdiv . style . position = ’ fixed ’;
9 overdiv . style . top = y + ’ px ’;
10 overdiv . style . left = x + ’ px ’;
11 overdiv . style . width = width + ’ px ’;
12 overdiv . style . height = height + ’ px ’;
13 overdiv . style . zIndex = imgs [ i ]. style . zIndex ;
14 overdiv . style . visibility = imgs [ i ]. style . visibility ;
15 overdiv . style . display = imgs [ i ]. style . display ;
16 overdiv . style . backgroundColor = ’ black ’;
17 imgs [ i ]. parentNode . appendChild ( overdiv ) ;
18 }
Lo script assegna al nuovo elemento div creato anche le propriet` di visibilit` dell’immag-
a a
ine, in modo che se per qualche motivo l’immagine fosse presente ma invisibile, si evita
di coprire una parte della pagina che in realt` non presentava alla vista un’immagine.
a
Inoltre, copiando la propriet` z-index e inserendo il nuovo elemento come child del par-
a
entNode dell’immagine in considerazione, ci si assicura che, se l’immagine ` posizionata
e
sotto ad un altro elemento, anche il div inserito si trover` in quella condizione, ma
a
esattamente sopra all’immagine.
32

35. Background-images
Poich` deve eliminare tutti gli elementi che contengono delle immagini, lo script deve
e
eliminare anche tutte le immagini impostate come immagine di sfondo di un qualche
elemento nella pagina web. Per farlo, lo script itera attraverso tutti gli elementi della
pagina web alla ricerca di un’elemento che ha la propriet` css background-image diversa
a
da ‘none’. In tal caso, non ci si pu` limitare ad impostarla a ‘none’, poich` in questo modo
o e
lo sfondo diventerebbe invisibile e si vedrebbero eventuali componenti posizionati dietro a
quello analizzato. Allora tutti gli elementi individuati che disponevano di un’immagine
di sfondo vengono modificati in modo che abbiano uno sfondo uniforme di un colore
prestabilito e opaco.
1 function ba ck g ro u nd Im a ge Ki l le r ( element ) {
2 style = window . getComputedStyle ( element ) ;
3 if ( style . backgroundImage != ’ none ’) {
4 element . style . backgroundImage = ’ none ’;
5 element . style . backgroundColor = ’ red ’;
6 }
7
8 storeColors ( element ) ;
9
10 if ( element . hasChildNodes () ) {
11 var child = element . firstChild ;
12 while ( child ) {
13 if ( child . nodeType === 1 && child . nodeName != ’ SCRIPT ’) {
14 b ac kg r ou n dI ma g eK i ll er ( child ) ;
15 }
16 child = child . nextSibling ;
17 }
18 }
19 }
Un esempio di funzionamento di questa parte ` dato dallo screenshot di figura 4.5, in
e
cui tutti gli elementi img sono stati coperti di nero e tutte le immagini di sfondo sono
state sostituite con il colore rosso.
Scelta colore univoco
Lo script, a questo punto, ha l’obiettivo di trovare un colore che non ` mai stato utiliz-
e
zato all’interno della pagina, per poter evidenziare le parole interessate dalla ricerca.
Per farlo dovrebbe iterare nuovamente tutti gli elementi e controllare tutte le propriet` a
che comportano l’uso di un colore, salvandolo in una lista, per poi scegliere casualmente
un colore non utilizzato. In pratica, lo script approfitta dell’iterazione utilizzata dal
passaggio precedente, e compila un array aggiungendoci i nuovi colori trovati per ogni
elemento analizzato.
E’ tuttavia possibile che un colore non presente nello stile della pagina venga ugualmente
riscontrato in qualche pixel dell’immagine dello screenshot. Questo avviene perch´ sul-
e
33

36. Fig. 4.5: Esempio di pagina web elaborata dallo script con immagini coperte di nero e
immagini di sfondo sostituite dal colore rosso
34

37. l’output dello screenshot Firefox applica un filtro anti-aliasing che in prossimit` di alcuni
a
cambi di colore introduce delle sfumature con colori vicini ma leggermente differenti dagli
originali.
E’ stato quindi introdotto, per ogni colore individuato nella pagina, un margine di toller-
anza, ed ` stato richiesto che il colore univoco fosse al di fuori di questo range. In questo
e
modo ci si ` potuti assicurare che il colore scelto fosse sufficientemente diverso da quelli
e
presenti nella pagina. Questo sistema incrementa la probabilit` di non poter individuare
a
un colore univoco nella pagina, ma in nessuno dei test effettuati si ` mai riscontrato un
e
caso in cui lo script non ` stato in grado di individuarne uno. La funzione che si occupa
e
di trovare il colore univoco nella pagina con un margine di tolleranza ` la seguente:
e
1 function univokeColor () {
2 tolleranza = 7;
3 c = ’ ’;
4 found = false ;
5 red = 0;
6 green = 0;
7 blue = 0;
8
9 do {
10 found = false ;
11 red = Math . floor ( Math . random () *255) ;
12 green = Math . floor ( Math . random () *255) ;
13 blue = Math . floor ( Math . random () *255) ;
14 for ( i =0; i < colors . length ; i ++) {
15 current = getRGB ( colors [ i ]) ;
16 if ( current [0] < red + tolleranza && current [0] > red -
tolleranza ) found = true ;
17 if ( current [1] < green + tolleranza && current [1] > green -
tolleranza ) found = true ;
18 if ( current [2] < blue + tolleranza && current [2] > blue -
tolleranza ) found = true ;
19 }
20 } while ( found == true )
21 return new Array ( red , green , blue ) ;
22 }
Occultamento della parola tramite font dello stesso colore dello sfondo
Prima di poter evidenziare la parola con il colore individuato, bisogna effettuare dei
controlli specifici per due tipi di occultamento che non sarebbero altrimenti rilevati. Il
primo ` il caso del testo di colore trasparente, facilmente rilevabile con un controllo sul-
e
la propriet` CSS color, mentre il secondo caso, quello del testo dello stesso colore dello
a
`
sfondo, rappresenta un problema molto pi` complesso. E infatti decisamente molto com-
u
plesso riuscire a realizzare questo controllo solamente dall’ambiente Javascript, poich` e
non esiste un metodo che restituisca il colore visualizzato in un certo punto della pagina
web.
35

38. Per effettuare questo controllo, ` stato creato uno script simile a quello che individua la
e
parola ‘viagra’ nella pagina e la evidenzia, ma destinato invece a renderla trasparente.
Dopodich´ lo script restituisce all’ambiente Java tutte le coordinate nelle quali si trovano
e
le occorrenze della parola. Con Java si analizzer` quindi lo screenshot della pagina, sen-
a
za le parole interessate, calcolando la presenza percentuale dei colori nella zona in cui
avrebbe dovuto risiedere la parola. Se esiste un unico colore nella zona considerata pre-
sente per il 90% o pi`, si considera questo colore come il background-color della zona. A
u
questo punto si confronta il colore ottenuto con il colore che il testo aveva nella pagina
originale e, se essi corrispondono,x si ` in presenza di un caso di testo e sfondo dello
e
stesso colore.
Evidenziazione della parola ricercata
L’ultima parte dello script si occupa di evidenziare le parole all’interno della pagina,
tramite tre semplici passaggi:
1. Itera attraverso tutti gli elementi della pagina e individua le parole ricercate
2. Introduce un elemento span per identificare la parola
3. Applica una classe CSS all’elemento introdotto in modo che risulti evidenziato del
colore univoco
La ricerca della parola ‘viagra’ (1) avviene esclusivamente sui nodi di tipo ‘TextNode’
trovati all’interno del DOM.
Per ogni occorrenza individuata lo script introduce un elemento span che racchiude la
parola ‘viagra’ (2), e ad esso viene applicata una classe creata appositamente in modo
da assegnare alle propriet` CSS background-color e color il colore univoco individuato
a
precedentemente (3).
In questo modo tutte le occorrenze della parola nella pagina, salvo quelle nascoste tramite
i due metodi controllati precedentemente, vengono evidenziate con un colore univoco.
Se queste fossero state visibili nella pagina originale, allora dovrebbe risultare visibile,
nella screenshot della pagina cos` modificata, anche il colore univoco selezionato.
ı
Dai test effettuati ` emerso che per effetto del filtro anti-aliasing applicato allo screen-
e
shot, la rilevazione del colore non ` sempre garantita modificando solamente il colore dei
e
caratteri della parola ricercata.
`
E invece risultato sufficiente per lo scopo applicare il colore univoco anche allo sfondo
dell’elemento span creato. Si pu` vedere in figura 4.6 uno screenshot del sito web oppor-
o
tunamente elaborato dallo script e pronto ad essere analizzato per la ricerca del colore.
Risultati: analisi screenshot
L’ultimo passaggio consiste nell’ottenere uno screenshot ed analizzarlo, scorrendo ogni
pixel dell’immagine e ricercando un particolare valore che corrisponde al colore univoco
con cui ` stato colorata la zona in cui la parola avrebbe dovuto trovarsi.
e
36

39. Fig. 4.6: Esempio di pagina web elaborata dallo script con parola visibile evidenziata
in viola
4.3.5 Analisi dei risultati del software OCR
Poich´ il caricamento dei risultati sul servizio di cloud storage Google Drive non ` autom-
e e
atizzato, l’unico passaggio relativo alla rilevazione OCR implementato in questo progetto
` l’analisi dei file di testo risultanti dall’elaborazione degli screenshot da parte del soft-
e
ware di Google.
Questi file vanno infatti posizionati nella stessa cartella dgli screenshot, in modo che il
metodo implementato, parseOcrFiles, li possa individuare e leggere per controllare se la
parola ` stata riconosciuta dal software OCR.
e
Il metodo parseOcrFiles individua per prima cosa i file che nella cartella degli snapshot
hanno lo stesso nome dei file di screenshot ma con un estensione .txt aggiunta in coda.
Se esistono pi` file che riferiscono ad una sola pagina web, poich´ lo screenshot carica-
u e
to su Google Drive era stato precedentemente diviso in pi` parti perch´ di dimensione
u e
maggiore ai 2Mb, li unisce in un file unico.
A questo punto il metodo analizza il contenuto del file per controllare se al suo interno
contiene la parola “viagra”, e memorizza nel database il risultato della ricerca.
4.3.6 Supporto Ground Truth
Per la validazione degli algoritmi proposti, ` stata necessaria la compilazione della
e
“Ground Truth”, ovvero la verifica manuale della condizione di visibilit` della parola
a
ricercata analizzando uno screenshot.
Poich´ la verifica della visibilit` di ogni screenshot ` un procedimento lungo e molto
e a e
lento, ` stato progettato un “helper” che aiutasse e rendesse pi` rapido il controllo della
e u
stessa.
Il software progettato sfrutta lo stesso concetto che il metodo JSColorizer utilizza per
individuare la parola nella pagina ma, invece di alterare il testo cambiandone i colori,
introduce un nuovo elemento span che posiziona sopra la parola e ne colora i bordi con
37

40. un colore vivace, che sia evidente alla vista dell’utente. In questo modo l’utente ` fa-e
cilitato nella ricerca della parola nella pagina, poich`, se la parola ` presente nel codice
e e
HTML, ci sar` un rettangolo colorato nella pagina che individua la sua posizione, e l’u-
a
tente deve soltanto controllare al suo interno per verificare se la parola ` leggibile oppure
e
no. L’utente, ovviamente, deve inoltre controllare accuratamente tutte le immagini della
pagina, poich` in queste l’algoritmo non ` in grado di riconoscere del testo.
e e
In figura 4.7 e 4.8 si possono osservare due parti di screenshot con la parola ricercata
rispettivamente visibile e non visibile cos` come sono mostrati dall’helper.
ı
Fig. 4.7: Esempio di screenshot mostrato dall’helper della ground truth con parola
visibile
Fig. 4.8: Esempio di screenshot mostrato dall’helper della ground truth con parola non
visibile
38

41. Capitolo 5
Risultati
5.1 Raccolta dati
E’ stato testo l’effettivo funzionamento del sistema realizzato. Sono stati prelevati 100
URL per ogni stringa di ricerca scelta e, poich´ la ricerca ` stata completata con successo
e e
per tutte le 9 stringhe fornite, essa ha memorizzato nel database 900 URL.
Il software ha poi eseguito gli snapshot degli URL recuperati, segnalando quelli che non
si riferivano a pagine web, ed effettuando lo screenshot e il salvataggio del DOM dei
restanti.
Infine, gli screenshot ottenuti sono stati elaborati dal software OCR ed i relativi output
sono stati posizionati nell’apposita cartella dove il software li ha analizzati e ne ha mem-
orizzato i risultati, completando il procedimento.
5.1.1 Analisi degli snapshot
Il numero di snapshot realmente effettuato, ovvero il numero di URL per i quali sono
stati salvati screenshot e DOM, ` infine risultato essere minore dei 900 URL raccolti
e
dalla ricerca iniziale.
Si ` infatti rilevato che durante il procedimento, non ` stato possibile generare uno
e e
snapshot da tutti gli URL, poich` appartenenti ad una delle seguenti categorie:
e
• URL di documenti non HTML
• URL che hanno restituito qualche errore durante l’elaborazione
URL Totale URL Totale Totale HTML Totale con
Totali non HTML Falliti completati parola nel DOM
900 96 18 786 312
Si pu` vedere un grafico degli URL analizzati in figura 5.1.
o
39

42. Fig. 5.1: Un pie chart degli URL processati
Risorse non HTML
Si ` notato che su un totale di 900 URL disponibili, il 10.6% rappresentava risorse non
e
HTML, che non sono quindi state analizzate ulteriormente.
Questo si verifica perch` il motore di ricerca Google, utilizzato nella compilazione della
e
lista di URL, ha la capacit` di indicizzare anche risorse diverse da pagine web, e ne
a
restituisce l’indirizzo indifferentemente dal tipo di documento individuato.
E’ comunque interessante notare che la percentuale di URL che individuano risorse non-
HTML sembra piuttosto alta: questa ` probabilmente una peculiarit` del tipo di ricerca
e a
in considerazione.
Snapshot interrotti da un errore
Ci sono poi stati altri 18 casi in cui il software non ` stato in grado di effettuare lo
e
snapshot dell’indirizzo prelevato dal database. Questi casi rappresentano degli URL che
hanno in qualche momento dell’elaborazione provocato un errore che non ha permesso
di completare lo snapshot.
Si mostrano ora questi 18 casi, suddivisi per tipo di errore che ` stato registrato nel log
e
per ognuno di essi.
Numero
di URL Errore Generato
10 “Firefox couldn’t load the page. The url may be invalid.”
3 “Something went wrong while getting DOM”
2 “Something went wrong while retrieving url”
2 “This snapshot was interrupted by DriverKiller after the timeout expired”
1 “Something went wrong while getting the screenshot”
Per ognuno di questi errori viene riportata nel log anche la specifica eccezione gener-
40

43. ata, in modo da avere maggiori informazioni per classificare il problema.
Il primo errore mostrato nella tabella, occorso 10 volte, indica che il browser ha mostrato
una pagina di errore invece di caricare l’URL: questo potrebbe essere dovuto a motivi
diversi, anche se un’analisi effettuata sui risultati durante i test del software ha mostrato
che per la maggior parte si tratta di mancate risoluzioni DNS dell’indirizzo.
A titolo di esempio si mostra il log completo per l’ultimo URL della tabella, che ha
restituito errore durante l’esecuzione dello screenshot:
1 Something went wrong while getting the screenshot :
2 Could not take screenshot of current page - [ Exception ... "
Component returned failure code : 0 x80004005 ( NS_ERROR_FAILURE )
[ n s I D O M C a n v a s R e n d e r i n g C o n t e x t 2 D . drawWindow ] " nsresult : " 0
x80004005 ( NS_ERROR_FAILURE ) " location : " JS frame :: file :///
tmp / anonymous4262018683082470387webdriver - profile / extensions /
fxdr iver@goo glecode . com / components / driver_component . js :: <
TOP_LEVEL > :: line 6257 " data : no ]
3 Command duration or timeout : 411 milliseconds
4 Build info : version : ’ 2.25.0 ’ , revision : ’ 17482 ’ , time : ’
2012 -07 -18 21:09:54 ’
5 System info : os . name : ’ Linux ’ , os . arch : ’ amd64 ’ , os . version : ’
2.6.32 -5 - amd64 ’ , java . version : ’ 1.7.0 _04 ’
6 Driver info : driver . version : WebDriverDriver
7 Session ID : 3 ee267ea -415 e -45 ff - a676 -1 f3be0830d34
Pagine senza la parola ricercata
Lo snapshot per le restanti 786 pagine ` stato eseguito correttamente, salvando screen-
e
shot e file HTML del DOM.
Di queste pagine, soltanto 312, ovvero appena il 39.7%, contenevano effettivamente la
parola ‘viagra’ al loro interno, nonostante la parola chiave fosse stata specificata es-
plicitamente nella ricerca sul motore di ricerca Google. Questa ` evidentemente una
e
particolarit` del tipo di ricerca effettuata, infatti ` raro che un motore di ricerca resti-
a e
tuisca un risultato che non contiene la parola cercata.
Poich´ i motori di ricerca utilizzano, per indicizzare una pagina, anche le informazioni
e
fornite dai link che vi conducono, questo ` teoricamente possibile, ma in questo caso
e
l’ipotesi pi` probabile ` che la pagina web sia stata modificata successivamente all’indi-
u e
cizzazione del motore di ricerca.
Questo ` particolarmente vero se si pensa al fatto che una buona parte dei siti ricer-
e
cati non contiene la parola legittimamente e ci si aspetta, di conseguenza, che gli am-
ministratori delle relative pagine risolvano il problema, non appena ne acquistino la
consapevolezza.
41

44. 5.2 Rilevazione testo nascosto
Il software progettato e sviluppato ha come obiettivo la rilevazione di testo nascosto alla
vista dell’utente nella pagina web analizzata.
Nel corso di questo documento sono stati presentati due metodi che si propongono come
soluzione al problema:
• Il metodo DOM e OCR
• Il metodo DOM e Javascript
Ora si analizzeranno i risultati che questi due metodi hanno ottenuto confrontati con
la Ground Truth rilevata manualmente, in base alla quale poi sono stati calcolati anche
precision e recall dei due algoritmi.
Si intende per precision la percentuale di pagine di testo nascosto individuate corretta-
mente sul totale delle pagine individuate dal metodo. Questa d` informazioni sull’affid-
a
abilit` del metodo nel rilevare il testo nascosto.
a
Per recall si intende la percentuale di pagine con testo nascosto individuate corret-
tamente dal metodo sul totale delle pagine con testo nascosto presenti nel database
(ground truth), e d` informazioni su quante pagine che avrebbero dovuto essere rilevate
a
sono state tralasciate dal metodo.
La seguente tabella elenca i metodi per la rilevazione del testo nascosto proposti in
questo progetto.
Il primo metodo “DOM” indica la scelta di valutare come pagine con testo nascosto tutte
le pagine trovate contenenti nel codice la parola ‘viagra’.
Il secondo metodo “!OCR” indica invece che si considerano positive tutte le pagine che
non presentano nei risultati dell’OCR la parola trovata.
Questi due metodi sono stati aggiunti per completezza nella tabella, ma si pu` vedere che
o
i relativi risultati sono scoraggianti, provando che non ` sufficiente valutare soltanto il
e
codice o soltanto il visibile per ipotizzare se la pagina contenga o meno del testo nascosto.
Gli altri due metodi, invece, sono i classificatori ideati appositamente per il problema
durante questo progetto, e ciascuno di essi si basa su una coppia features diversa.
La terza riga della tabella si riferisce al metodo DOM e OCR, che individua le pagine
che contengono le parole nel DOM ma non nei risultati del software OCR.
La quarta riga si riferisce al metodo DOM e Javacript, ampiamente descritto nei capitoli
precedenti, che individua le pagine che contengono la parola nel DOM e in cui, secondo
l’analisi effettuata con il codice Javascript e lo screenshot, queste occorrenze non risultano
visibili.
Le colonne della tabella indicano rispettivamente:
• Pagine Totali - le pagine totali sottoposte ai vari metodi
• Pagine Individuate - le pagine che il metodo ha classificato come pagine con testo
nascosto
42

45. • Ground Truth - le pagine in cui il testo ` realmente nascosto (rilevate manualmente)
e
• Precision - il valore della precision calcolata sui veri positivi e falsi negativi nella
tabella sucessiva
• Recall - il valore della recall calcolata sui veri positivi e falsi positivi mostrati nella
tabella sucessiva
Pagine Pagine Ground
Metodo Totali Individuate Truth Precision Recall
DOM 786 312 204 65.38% 100%
!OCR 786 693 204 29.44% 100%
DOM+!OCR 786 219 204 93.15% 100%
DOM+!JS 786 205 204 99.51% 100%
Pagine Pagine Ground True True False False
Metodo Totali Individuate Truth Pos. Neg. Pos. Neg.
DOM 786 312 204 204 474 108 0
!OCR 786 693 204 204 93 489 0
DOM+!OCR 786 219 204 204 567 15 0
DOM+!JS 786 205 204 204 581 1 0
5.3 Analisi dei falsi positivi
Entrambi i metodi proposti hanno presentato dei falsi positivi, mentre nessuno dei due
ha invece presentato falsi negativi. Si analizza ora nello specifico i casi che sono risultati
in una rilevazione errata da parte dei metodi considerati.
5.3.1 Metodo DOM e OCR
Il metodo ha presentato 15 falsi positivi, ovvero ci sono stati 15 casi in cui il metodo
classificava le pagine come “pagine con testo nascosto” quando in realt` esse non lo erano.
a
Gli errori sono da ricondursi ad una rilevazione OCR imprecisa, in cui il testo era presente
nella parte visibile ma il software OCR non ` stato in grado di riconoscerlo. Nella figura
e
5.2 si mostra una parte di screenshot con la parola ‘viagra’ presente ma dalla quale il
software OCR non l’ha rilevata correttamente.
5.3.2 Metodo DOM e Javascript
Il metodo DOM e Javascript ha riportato un solo caso di falso positivo, dove non ` stato
e
in grado di rilevare una parola visibile.
Il caso ` interessante, poich´ evidenzia una limitazione dell’algoritmo: la parola si trovava
e e
all’interno dell’attributo “value” di una casella di testo, dove non poteva essere rilevata
dallo script che cerca la parola solo al di fuori dei tag HTML.
43

46. (a)
(b)
Fig. 5.2: (a) Una delle parole non rilevate dal software OCR con (b) il testo che ha
invece riconosciuto
Si mostra in fig 5.3 il codice e la parte di screenshot interessati.
(a)
(b)
Fig. 5.3: (a) La parola non rilevata dallo script Javascript e (b) la parte di codice in
cui era posizionata nella pagina
5.4 Confronto metodi proposti
5.4.1 Precision & Recall
Analizzando i risultati si pu` concludere che entrambi i metodi si sono rivelati piut-
o
tosto soddisfacenti nella rilevazione del testo nascosto. In particolare, il metodo DOM e
Javascript ha ottenuto dei risultati eccellenti, con una precision superiore al 99%, pari
44

47. ad un solo falso positivo.
.
Entrambi i metodi hanno inoltre mostrato una recall pari al 100% che indica una
tendenza a non riscontrare falsi negativi. Per entrambi i metodi ` infatti improbabile
e
rilevare la parola nella parte visibile quando questa non ` effettivamente presente.
e
5.4.2 Tempi di esecuzione
Durante l’esecuzione degli snapshot sono stati misurati i tempi di completamento per
ogni snapshot eseguito, in modo da avere una stima della durata media di un generico
snapshot. Questi tempi sono stati misurati su una macchina server Linux che dispone
di 8 CPU da 2.33 GHz e 8 GB di memoria centrale.
I tempi di esecuzione dei metodi analizzati sono differenti: l’esecuzione del codice Javascript
e Java del metodo DOM e Javascript ` parte della creazione degli snapshot, di cui ` sta-
e e
ta misurata la durata nel database, e la cui media risulta essere pari a 16.24 secondi,
considerando che il timeout massimo per la creazione dello snapshot ` di poco superiore
e
ai 120 secondi.
Tuttavia ` necessario notare che durante la creazione degli snapshot le istanze di firefox
e
e di conseguenza i thread che creano snapshot eseguiti contemporaneamente erano pari
a 4, riducendo il tempo medio per snapshot a 4.06 secondi, considerabile come limite
superiore per l’esecuzione del metodo DOM e Javascript.
Per quanto riguarda invece il metodo DOM e OCR, i tempi di esecuzione risultano leg-
germente pi` elevati.
u
Purtroppo la scelta di utilizzare il software OCR di Google Drive ha imposto la necessit` a
di eseguire l’upload del file immagine dello screenshot sul servizio di storage per eseguire
l’elaborazione, e successivamente di eseguire il download del file di testo elaborati, di
dimensioni molto pi` ridotte.
u
Inoltre l’esecuzione del software OCR, bench` avvenga sul server, richiede un tempo di
e
calcolo molto pi` elevato dell’esecuzione dello script javascript, e Google Drive consente
u
di caricare ed elaborare un solo file alla volta.
5.4.3 Considerazioni sui risultati
Si pu` in definitiva concludere che il metodo DOM e Javascript si ` rivelato piuttosto
o e
superiore al metodo DOM e OCR in relazione al problema considerato, mostrando una
precision molto pi` elevata e dei tempi di esecuzione molto pi` ridotti, nonch´ la possi-
u u e
bilit` di essere eseguito in modo completamente automatizzato.
a
Dai risultati ottenuti si pu` inoltre osservare che le limitazioni dei metodi evidenziate
o
nel corso di questo documento non sembrano aver influito sulla loro efficacia nell’ambito
di questo studio.
Non si deve tuttavia generalizzare questi risultati senza condurre ulteriori test, poich´
e
45

48. il campione di pagine web scelto per lo studio ` troppo poco ampio ed eterogeneo per
e
consentire questo tipo di considerazioni.
5.5 Utilizzo
5.5.1 Pacchetto Jar
Il risultato del progetto ` un pacchetto JAR eseguibile, in grado di eseguire tutte le
e
funzioni descritte nei capitoli precedenti. L’eseguibile riceve in ingresso dei parametri e
stampa a video le informazioni relative all’esecuzione.
Il software ` stato progettato specificatamente per l’utilizzo nel laboratorio Machine
e
Learning del D.I.A. presso l’Universit` degli Studi di Trieste, pertanto ` configurato in
a e
modo da connettersi al database della rete del laboratorio.
Per specificare un server diverso, ` necessario modificare l’opportuna occorrenza nel file
e
persistence.xml presente all’interno del pacchetto JAR.
Inoltre, le stringhe di ricerca per il componente GoogleCrawler devono essere inserite nel
database come righe della tabella SiteClass.
Parametri
L’eseguibile riceve in ingresso dei parametri che indicano quale funzione deve svolgere.
Alcuni di questi parametri consentono di specificare delle opzioni aggiuntive.
Di seguito si descrivono i principali parametri che il programma accetta in input:
c [n] Recupera una lista di url tramite il componente GoogleCrawler
Il parametro n indica il numero massimo di risultati per ogni stringa di ricerca
s [n] Effettua degli snapshot degli url presenti nel database
Il parametro n indica il numero di istanze di Firefox da utilizzare
o Avvia l’analisi dell’output del software OCR di Google Drive
r [n] Riprova ad effettuare gli snapshot falliti precedentemente.
Il parametro n indica il numero di istanze di Firefox da utilizzare
g Avvia l’helper per la Ground Truth
46

49. Capitolo 6
Conclusioni
6.1 Obiettivi raggiunti
L’obiettivo del progetto ` stato di ideare ed implementare un software che recupera una
e
lista di URL, le analizzi per verificare se le corrispondenti pagine web contengono al loro
interno del testo nascosto.
Alla luce di ci` che ` stato esposto nei capitoli precedenti, si pu` dire che gli obiettivi
o e o
del progetto sono stati raggiunti.
Il software progettato infatti consente di compilare una lista di URL a partire da una
serie di stringhe di ricerca date, e successivamente consente di applicare agli URL cos` ı
ottenuti due metodi per la rilevazione del testo nascosto.
Entrambi i metodi proposti hanno inoltre dato dei risultati piuttosto soddisfacenti in
termini di precision e recall. I metodi infatti non sono risultati soggetti a falsi negativi,
ed hanno entrambi riscontrato una precision superiore al 90%.
Tuttavia, nonostante i metodi proposti siano stati molto efficaci in fase di test, sono
state evidenziate delle limitazioni piuttosto importanti dell’approccio scelto per i due
metodi, che potrebbero facilmente decrementare le prestazione degli stessi se utilizzati
in contesti diversi, come ad esempio con pagine di realizzazione pi` recente e moderna,
u
con un elevato numero di funzionalit` implementate per mezzo di script.
a
6.2 Sviluppi futuri
Le limitazioni evidenziate nel corso dei precedenti capitoli individuano un problema nel
tipo di approccio usato per la rilevazione del testo visibile.
In una pagina web alcune parti di contenuto possono non essere inizialmente visibili
nonostante esse siano comunque accessibili in seguito ad un’interazione con la pagina
tramite qualche tipo di input. Tutti questi tipi di componenti, che sono per la maggior
parte implementati tramite scripting lato client ma non solo, mettono in difficolt` gli
a
algoritmi proposti, che si limitano a considerare come contenuto legittimo tutto ci` che
o
` visibile nonappena la pagina sia stata caricata completamente.
e
Degli eventuali sviluppi futuri potrebbero considerare la possibilit` di superare questo
a
47

50. limite, assicurandosi di non essere in presenza di casi di questo genere, oppure intro-
ducendo un metodo per l’analisi dei componenti di questo tipo.
48