Universita degli studi di Trieste

Facolta di Ingegneria

Tesi di Laurea in

Ingegneria dell’Informazionecurriculum informatica

Progetto e Realizzazione di un Software per laRilevazione 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

Universita degli studi di Trieste

Facolta di Ingegneria

Tesi di Laurea in

Ingegneria dell’Informazionecurriculum informatica

Progetto e Realizzazione di un Software per laRilevazione 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

Ai miei genitori

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 Modalita di realizzazione . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.2 Finalita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

4.2.1 Entita / Classi JPA . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 Struttura Classi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3.1 GoogleCrawler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.2 WebDriverController . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.3 Snapshotter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.4 JSColorizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3.5 Analisi dei risultati del software OCR . . . . . . . . . . . . . . . . 374.3.6 Supporto Ground Truth . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Risultati 395.1 Raccolta dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.1 Analisi degli snapshot . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Rilevazione testo nascosto . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.3 Analisi dei falsi positivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3.1 Metodo DOM e OCR . . . . . . . . . . . . . . . . . . . . . . . . . 435.3.2 Metodo DOM e Javascript . . . . . . . . . . . . . . . . . . . . . . . 43

5.4 Confronto metodi proposti . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.4.1 Precision & Recall . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.4.2 Tempi di esecuzione . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4.3 Considerazioni sui risultati . . . . . . . . . . . . . . . . . . . . . . 45

5.5 Utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.5.1 Pacchetto Jar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6 Conclusioni 476.1 Obiettivi raggiunti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.2 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Ringraziamenti 49

6

Capitolo 1

Introduzione

Gli attacchi “Hidden Text Injection” sono attacchi informatici diffusi recentemente checolpiscono l’integrita dei siti web: essi consistono nell’inserimento, all’interno delle pagineweb interessate, di testo nascosto. Gli attacchi di questo tipo consentono la realizzazionedi tecniche fraudolente come la “Search Redirect” e la “Search Spam”, tecniche volte allamanipolazione dei risultati dei motori di ricerca.L’attacco risulta particolarmente difficile da individuare poiche non apporta modifichevisibili alle pagine, e spesso gli stessi amministratori del sito ignorano di essere staticolpiti, rendendo l’attacco molto persistente nel tempo.L’introduzione di testo nascosto nelle pagine web e una pratica di Search Engine Op-timization considerata illecita dalla maggior parte dei motori di ricerca, e per questomotivo 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 unsoftware per la rilevazione automatizzata degli attacchi informatici di tipo “Hidden TextInjection”.Lo sviluppo del software si e concentrato particolarmente sulla creazione di un sistemaper la valutazione della visibilita del testo nella pagina. La relativa analisi ha portato allarealizzazione di due metodi distinti per la risoluzione del problema: il primo metodo, cheutilizza un’analisi OCR, e stato proposto come soluzione al momento dell’assegnazionedel progetto, mentre il secondo metodo e stato da me ideato durante la fase di proget-tazione. Entrambi i metodi si sono poi dimostrati soddisfacenti in fase di test.Piu in dettaglio, il software sviluppato e in grado di compilare una lista di pagine websospettate di essere vittima dell’attacco, ed in seguito di classificarle utilizzando i duemetodi sviluppati per l’individuazione di testo nascosto.

Il progetto e stato realizzato presso il laboratorio Machine Learning del D.I.A. del-l’Universita degli Studi di Trieste. Poiche il progetto ha visto l’integrazione di un com-ponente precedentemente sviluppato presso il laboratorio, per motivi di compatibilita estato richiesto che il progetto si avvalesse delle seguenti tecnologie software:

7

• 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 piu dettagliata sul problema analiz-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

Capitolo 2

Scenario

2.1 Scopo del progetto

Lo scopo del progetto consiste nell’ideazione e realizzazione di un sistema automatizzatoche consenta di rilevare attacchi informatici di tipo “Hidden Text Injection”. Il sistemaindividua ed in seguito analizza una lista di pagine web che possono essere vittimadi questo tipo di attacco. Si e quindi realizzato un sistema capace di individuare,all’interno del codice di una pagina web, porzioni di testo nascoste volontariamente allavista dell’utente (“Hidden Text Injection”).

2.2 Tipo di attacco “Hidden Text Injection”

2.2.1 Modalita di realizzazione

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 webvittime. Questo codice viene inserito all’interno della pagina web attaccata in modo cheil testo o i link iniettati non siano visibili a chi visita la pagina. Cio rendendo difficilel’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 conun posizionamento nella pagina con coordinate negative, in modo da essere al di fuoridella parte della pagina che il browser visualizza, oppure ancora scrivendo con colorebianco 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 possonoportare, se rilevate, alla rimozione del sito dai risultati di ricerca.Questo e un notevole fattore di rischio per chi e vittima di attacchi di questo tipo, chesono in questo senso molto pericolosi proprio perche difficili da individuare, e che possonocostituire un danno importante per un dominio nel momento in cui esso viene rimossodai risultati di ricerca.

1http://en.wikipedia.org/wiki/HTML2http://support.google.com/webmasters/bin/answer.py?hl=en&answer=35769#3

9

2.2.2 Finalita

Le tecniche di “Hidden Text Injection” possono essere suddivise a seconda del tipo dicodice 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, poiche puntano amodificare in modo illecito la rilevanza di una determinata pagina web all’interno deiranking dei motori di ricerca.Nonostante il problema dell’inserimento di codice aggiuntivo nel sorgente originale sia lostesso, e le tecniche con cui viene realizzato siano svariate e non rientrino negli scopi diquesto documento, le modalita e le finalita dell’attacco differiscono in modo sostanzialetra 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 punteggioad ogni pagina a seconda di una serie di fattori, tra i quali solitamente il numero di linkche dirigono a quella determinata pagina. Ognuno di questi link incrementa il punteggiototale proporzionalmente al punteggio della pagina sulla quale il link risiede, dando cosıpiu importanza ai link che si trovano su pagine con punteggio piu elevato e, di con-seguenza, in genere piu autorevoli.L’attacco“Hidden Links Injection”consiste nell’inserimento fraudolento di link che riferisconoa 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’internodei suoi database. In questo modo, la rilevanza attribuita al sito dal motore di ricercasale, ottenendo un miglior posizionamento nei risultati di ricerca.Inoltre, poiche i motori di ricerca come Google considerano anche la pagina che ospita illink per il calcolo del punteggio, un attaccante preferira introdurre questi link su siti piuautorevoli, guadagnando visibilita sui motori di ricerca in modo piu veloce ed efficace.

Introduzione di codice contenente testo nascosto

I motori di ricerca, per indicizzare una pagina, analizzano il suo codice e ne estraggonole parti di testo al suo interno. Poiche si occupano di valutarne soltanto il contenuto,non utilizzano le informazioni sullo stile fornite nella pagina, e non distinguono tra testovisibile e non visibile.L’attacco analizzato consiste nell’introduzione, all’interno del codice HTML originario,

3http://en.wikipedia.org/wiki/Spamdexing

10

di semplici porzioni di codice contenenti testo non visibile, in modo che i visitatori delsito 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 neirisultati di ricerca anche a seconda di questi termini, in modo che una ricerca di questiultimi restituisca tra i vari risultati anche il sito attaccato.Una possibile finalita di questo tipo di attacco e la “SearchRedirection”4, in cui l’at-taccante introduce anche uno script che redirige gli utenti che provengono dal motoredi ricerca verso una pagina diversa, che trae vantaggio dall’attacco con il conseguenteaumento di visibilita. Lo script si cura di reindirizzare alla pagina designata soltantogli utenti che provengono dal motore di ricerca e che hanno ricercato le parole chiaveaggiunte nel testo nascosto, in modo tale da non insospettire gli utenti legittimi dellapagina.In questo modo l’attaccante sfrutta l’autorevolezza e l’affidabilita del sito vittima intro-ducendo delle nuove parole chiave per le quali poi si e reindirizzati su una pagina diversa,che spesso e relativa ai termini ricercati, e rende il sistema molto difficile da individuare.

4http://static.usenix.org/events/sec11/tech/full papers/Leontiadis.pdf

11

12

Capitolo 3

Progettazione

3.1 Struttura del progetto

Il sistema si compone di due macro-blocchi: il primo compila una lista di pagine webcandidate, il secondo applica l’algoritmo che individua quali sono vittima di un attacco“Hidden Text Injection”.Uno schema delle fasi principali del progetto si puo vedere in figura 3.1.

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 diricerca 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 metodiche verranno esposti nel corso di questo capitolo.

5. Confronto dei risultati per valutare la presenza di testo nascosto, che si ha quandola ricerca nel DOM ha dato esito positivo mentre l’analisi dello screenshot non harilevato la presenza del testo cercato.

3.1.2 Compilazione della lista di pagine web

La compilazione della lista di pagine web da analizzare e stata svolta attraverso ricerchemirate con il motore di ricerca Google, che e di fatto il principale obiettivo della ma-nipolazione effettuata dall’attacco.Le stringhe da ricercare sono state scelte cercando gia a questo punto di effettuare unaprima selezione di pagine che hanno una buona probabilita di aver subito questo tipo diattacco.

13

Fig. 3.1: La struttura del progetto

Parametro di ricerca site di Google Search

La parola chiave ‘site:’ nelle stringhe di ricerca di Google e un parametro che permettedi limitare la ricerca effettuata ai siti il cui nome di dominio contiene la stringa che losegue. Ad esempio la stringa di ricerca seguente:

1 university site:edu

restituisce tutti risultati di ricerca che corrispondono alla parola ‘university’ limitati aidomini di primo livello edu.

Stringhe di ricerca

Le stringhe di ricerca sono state scelte per evidenziare delle inconsistenze tra i terminidi 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

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 pagineweb, che appartengono a domini in cui non ci si aspetta di trovare un elevato numero dipagine che trattano legittimamente di Viagra. In questo modo ci si aspetta di trovarenella lista diverse pagine che sono state effettivamente sottoposte ad un attacco “HiddenText Injection” .

3.1.3 Analisi di una singola pagina

Una volta ottenuta una lista di pagine web, l’obiettivo e di decidere, in modo quantopiu automatizzato possibile, se si e in presenza di una pagina sottoposta a hidden textinjection.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 visibileoppure no. Questo e necessario perche non tutte le pagine che Google restituisce dallaricerca contengono necessariamente la parola cercata, ad esempio poiche il contenutodella pagina puo essere stato modificato dopo l’indicizzazione del motore di ricerca.Nel caso in cui la parola non dovesse risiedere nemmeno nel codice della pagina, nonabbiamo motivo di suppore che la pagina in questione sia stata effettivamente attaccata.Un flow chart di questa fase del progetto e mostrata in figura 3.2.

15

Analisi del DOM (Document Object Model) della pagina web

Per ricercare la parola nel codice della pagina, e stato deciso di procedere con l’analisidel DOM1, una rappresentazione orientata agli oggetti del codice HTML di una pagina.Il vantaggio di avvalersi di questo modello, che risiede e viene aggiornato dinamicamentenel browser, e che in questo modo si puo ottenere un listato di codice HTML molto piuvicino a quello che viene di fatto visualizzato dall’utente. Questo accade poiche spessodegli script della pagina web, inclusi nel codice originario, modificano la struttura dellapagina non appena vengono eseguiti ma, cosı facendo, modificano anche la struttura delDOM, dal quale poi si puo estrarre il codice HTML aggiornato da analizzare.L’analisi effettuata sul DOM e quindi un efficace metodo per controllare se il testoricercato e presente all’interno della pagina web in considerazione. Da notare che fino adora non si e fatto alcun riferimento alla visibilita della parola, o del testo, nella paginache viene visualizzata dall’utente.

Analisi della parte visibile

Una volta accertato che la parola sia presente nel codice del documento, si deve procederead analizzare la parte visibile della pagina web, per individuare se quest’ultima e visibileoppure no.E stato ritenuto che, qualora questa fosse presente ma non visibile, la pagina sarebbeclassificata come probabile vittima dell’attacco.La scelta e lo sviluppo di un metodo per individuare del testo visibile nella pagina web sie rivelato il punto cardine del lavoro svolto, che ha evidenziato due principali soluzioni:

1. Analisi dello screenshot della pagina con un algoritmo OCR per la rilevazione deltesto

2. Applicazione di un metodo basato sull’esecuzione di uno script Javascript ed unasuccessiva 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

1http://en.wikipedia.org/wiki/Document Object Model

16

3.2.2 Confronto risultati DOM e OCR

Una volta ottenuti dei risultati dall’analisi dell’immagine con il software OCR, si verificase la parola cercata e presente nel codice del DOM ma non nel testo riconosciuto nelloscreenshot.In questo caso la pagina sara considerata una probabile vittima di un attacco HiddenText Injection.

3.2.3 Limiti degli algoritmi OCR (Optical Character Recognition)

Gli algoritmi OCR2, appartenenti agli algoritmi di “pattern recognition”, consentonol’estrazione del testo contenuto in un’immagine. Questi algoritmi sono stati progettatiprincipalmente per la digitalizzazione di testi stampati con parti di testo omogenee, e sisono dimostrati affidabili in questo tipo di applicazione.Se l’accuratezza di questi algoritmi fosse molto buona anche nel caso considerato daquesto 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 tipidi carattere (font) digitali, la diversita delle dimensioni dei caratteri e il gran numero divarieta di colori nelle pagine web possono abbassare di molto l’efficacia di questi algorit-mi. Per questo motivo si e resa necessaria una piccola ricerca tra i piu comuni softwareOCR per la scelta di quello che si sarebbe dimostrato piu accurato nella rilevazione ditesto 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 ingenere molto dispendiosi dal punto di vista computazionale, insieme alla maggior partedi 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 testovisibile nella pagina.Il concetto alla base dello sviluppo dell’algoritmo e stata la trasformazione del problemadi ricerca del testo in un’immagine in un problema piu analitico, non soggetto alle limi-tazione del software OCR.Un software non puo leggere un testo da un’immagine con facilita, cioe capire se l’in-sieme dei pixel trovati rappresenta una lettera oppure un disegno, ma puo facilmenteiterare attraverso milioni di pixel alla ricerca di un codice prestabilito che rappresenti,per esempio, un determinato colore, e lo puo fare in pochi secondi.

Da qui l’idea di marcare la porzione di pagina interessante (cioe il testo da individ-uare) con un colore univoco, in modo che un software possa facilmente individuare la

2http://en.wikipedia.org/wiki/Optical character recognition

17

modifica. In questo modo il software e in grado di individuare nella pagina la parolacercata, solo se visibile anche nella pagina originale.

3.3.2 Problematiche

Cio che e stato descritto nel paragrafo precedente non e pero del tutto esatto, in quantoesistono delle considerazioni preliminari che vanno affrontate prima di poter approcciareil 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 affinche questo non interferisca con gli scopidell’algoritmo, questa non deve alterare la condizione di visibilita del testo su cui e ef-fettuata.Infatti, modificando il colore del testo, si perdono tutte le informazioni relative all’oc-cultamento attraverso particolari colori del font, cioe:

• 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. Perche l’algoritmo funzioni in modo corretto, e nec-essario che nemmeno un pixel dell’immagine analizzata presenti il codice corrispondenteal colore individuato come univoco. Benche lo spettro elettromagnetico delle frequenzedel visibile sia da un punto di vista fisico uno spettro continuo, che corrisponde in praticaad un numero illimitato di colori, e ben noto che non esiste modo di rappresentare infiniticolori in un numero limitato di bit, che e quello di cui si dispone quando si modellizzanoi colori in un computer.Visto che il numero di colori effettivamente utilizzabili in una pagina web e quindi limita-to, e teoricamente possibile che non esista un colore univoco in una determinata paginaweb.In teoria infatti, non sarebbe difficile creare un’immagine che rappresenti tutti i possibilicolori che il codice HTML permette di rappresentare. Essa dovrebbe avere un numerodi pixel pari al numero di colori disponibili, che nel modello RGB sono

224 = 16777216

contenuti ad esempio in un immagine di 4096x4096 pixel.

18

3.3.3 Limitazioni

Una limitazione nota di questo approccio e l’impossibilita, per uno script del tipo de-scritto, di rilevare del testo contenuto all’interno di immagini della pagina web. Questeinfatti non sono elementi testuali e la ricerca delle occorrenze di testo nel codice HTMLdella pagina non puo fornire alcun risultato per questi elementi. Alla luce di questo fatto,e stato ritenuto ragionevole, anche per motivi implementativi, coprire tutte le immaginipresenti con un unico colore prestabilito, in modo da ridurre il numero di colori utilizzatie rendere piu facile la ricerca di colore univoco.

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 questocaso attraverso un’elaborazione della pagina per mezzo di uno script che implementa leoperazioni e le soluzioni alle relative problematiche descritte nei paragrafi precedenti:

1. Ricerca tutti gli elementi che nella pagina web rappresentano un’immagine e lioscura con un colore unico

2. Itera attraverso tutti gli elementi della pagina web ricercando un colore che non emai 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 eoccultata 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 dellaparola

Dopo l’esecuzione dello script, si analizza lo screenshot della pagina, il cui aspetto e statoprobabilmente modificato dallo script, e si stabilisce se al suo interno e presente il colorecon cui lo script ha evidenziato la parola ricercata.Se il colore viene individuato, la parola viene considerata visibile, almeno in parte, nellapagina web originale. Se invece esso non viene individuato, ma un’occorrenza dellaparola e stata rilevata all’interno del codice della pagina, questa sara classificata daquesto metodo come vittima dell’attacco “Hidden Text Injection”.Un esempio di pagina elaborata dallo script si puo vedere in figura 3.3, in cui si vede lapagina con le immagini coperte di nero e le parole individuate evidenziate con un coloreunivoco.

19

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 paragrafiseguenti.

3.4.1 Limitazioni dovute all’analisi dello screenshot

L’analisi dello screenshot della pagina web e stata presa in considerazione poiche e uneccellente metodo per osservare e analizzare esattamente quello che l’utente si trovadavanti quando visualizza la pagina web. Esso e stato sfruttato per cercare di capirequali parti di testo vengono visualizzati e quali altri no, ricercando la loro presenzaall’interno di quest’immagine.Esiste pero un problema di fondo in questo approccio: le pagine web possono conteneredelle parti o dei componenti interattivi, cioe che reagiscono ad un input dell’utentemodificando in qualche modo l’output della pagina, ovvero il suo contenuto o la suastruttura. Alcuni di essi, come ad esempio i link, non rappresentano un problema pergli algoritmi considerati, poiche prevedono l’indirizzamento ad una pagina diversa.

20

ScrollBar

Esistono altri componenti che pero prevedono una modifica della struttura o dei contenutivisivi rimanendo nel contesto della stessa pagina: tra i piu comuni componenti di questotipo troviamo le scrollbar, di cui un esempio riscontrato durante la raccolta dei risultatisi puo vedere in figura 3.4.

Fig. 3.4: Screenshot che evidenzia uno dei limiti degli algoritmi proposti

Script

Un’altra componente delle pagine web che puo operare in questo modo sono gli script.Gli script possono essere utilizzati per nascondere contenuti di secondaria importanza emostrarli solo quando l’utente manifesta un interesse specifico, ad esempio premendo suun 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 uncerto argomento (come ad esempio il Viagra) e mostrarli successivamente solo quandol’utente preme su un apposito pulsante, portando erroneamente gli algoritmi analizzatia classificare la pagina come “possibile vittima”.

3.4.2 Testo nelle immagini

Un altra limitazione, che interessa solo il secondo metodo proposto, quello DOM eJavascript, e che lo script si limita a ricercare e rilevare il testo contenuto nel codiceHTML della pagina e quindi non all’interno delle immagini. La ricerca infatti si limitaagli elementi che contengono del testo, mentre la ricerca in un’immagine richiederebbe

21

inevitabilmente un’analisi da parte di un algoritmo OCR, che nel metodo considerato sie voluto evitare.

22

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 chehanno svolto alcune funzioni del progetto in modo indipendente.Di seguito se ne elencano le principali.

23

4.1.1 Hibernate JPA (Java Persistence API)

Java Persistence API1 e un framework che permette la gestione di un database relazionaledall’ambiente di programmazione Java. Esso consente di salvare o caricare oggetti Javadal database direttamente attraverso l’interfaccia fornita.La specifica implementazione utilizzata in questo progetto e Hibernate JPA 1.0.

4.1.2 Selenium WebDriver

Selenium WebDriver e un API che permette di controllare il browser dal linguaggio diprogrammazione. L’API mette a disposizione dei metodi che consentono ad esempio dieseguire il browser, recuperare e visualizzare una pagina, salvare uno screenshot oppureiniettare del codice Javascript in una pagina precedentemente caricata.In particolare in questo progetto la libreria e stata utilizzata per controllare il browserMozilla Firefox.

4.1.3 Scelta del software OCR

Per la scelta del software OCR si e resa necessaria una piccola ricerca preliminare, pervalutare quale software ottenesse risultati piu soddisfacenti se usato con immagini dipagine 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 unevidente superiorita del software di Google, dando risultati deludenti nel caso degli altridue software proposti. A differenza dei primi due, il motore OCR di Google Drive eprobabilmente quello piu adatto alla scansione di un’immagine piu eterogenea: questoe fondamentale quando si tratta con documenti con una grande varieta di font e colori,come nel caso di questo progetto.

4.1.4 Google Drive OCR

Il software di riconoscimento ottico di caratteri (OCR) integrato in Google Drive2 efornito come servizio gratuito per chi dispone di un account Google, e puo essere eseguitoautomaticamente sui documenti che vengono caricati sul servizio di cloud storage diGoogle. Tutti i risultati possono essere poi scaricati in un unico file compresso al terminedell’operazione di caricamento, che pero impone dei limiti:

• Ogni file caricato non puo superare i 2 Mb di dimensione

1http://en.wikipedia.org/wiki/Java Persistence API2http://en.wikipedia.org/wiki/Google Drive

24

Fig. 4.2: Lo schema logico del database implementato

• I file vengono caricati ed elaborati dal software OCR uno alla volta

Il software e utilizzabile unicamente attraverso il servizio di storage, caricando i fileimmagine sul server remoto, attendendo il completamento della conversione e scaricandosuccessivamente i risultati.

4.2 Database

4.2.1 Entita / Classi JPA

Il database e stato creato utilizzando il DBMS MySql. Lo schema logico delle entita estato rappresentato in figura 4.2.Le entita utilizzate, corrispondenti ad oggetti Java, sono elencate di seguito:

• 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 e la classe responsabile della compilazione della lista di URL sui qualipoi verranno applicati i due metodi proposti per la classificazione dei siti come probabilivittime dell’attacco o no. Essa rappresenta la prima fase dello schema di fig. 4.1.Questo componente, sviluppato precedentemente presso il laboratorio Machine Learningdel D.I.A., si occupa di recuperare, per ogni oggetto SiteClass prelevato dal database,

25

Fig. 4.3: Diagramma UML della classe Snapshotter

Fig. 4.4: Alcuni diagrammi UML delle restanti classi sviluppate

26

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 e gestire una coda di task da eseguire, in questo casooggetti della classe Snapshotter, e di eseguirli uno alla volta secondo l’ordine dato. Essaimplementa l’interfaccia Runnable, e viene quindi eseguita in un thread, permettendoin questo modo di eseguire piu istanze di Firefox allo stesso tempo per permettere unaparallelizzazione del lavoro degli oggetti Snapshotter, che si occupano di ogni singolo urlda prelevare e analizzare. Essa e composta dal costruttore e da due metodi pubblici:

• public void addSnapshotter(Site s, int id)

• public void run()

Il metodo addSnapshotter permette di accodare un nuovo oggetto Site da analizzarealla lista di task. Sara proprio in questo metodo che la classe WebDriverController creeraun nuovo oggetto Snapshotter per l’analisi dell’oggetto Site passato.L’intero id e un numero che identifica univocamente l’oggetto Snapshotter associato alSite fornito, e serve per individuare lo Snapshotter all’interno dei file di log.Il metodo run e quello che esegue il thread e comincia l’esecuzione, uno alla volta, deglioggetti Snapshotter creati e salvati in una lista.In questo punto si e resa necessaria la gestione di due problematiche, che vengonoapprofondite di seguito:

DriverKiller

E’ stata evidenziata in fase di test una certa instabilita delle librerie Selenium WebDriver,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 webche non trasferisce dati dopo aver instaurato la connessione, puo accadere che l’oggettoJava associato all’istanza del browser blocchi l’esecuzione del codice attendendo di avercaricato la pagina, cosa che in effetti non accade, bloccando di fatto l’intera esecuzionedel thread.Per risolvere questo tipo di problemi e stata progettata un’ulteriore classe denominataDriverKiller, che si occupa di gestire un timeout indipendente e di terminare l’istanza diFirefox, una volta che esso e scaduto.All’interno della classe WebDriverController e stato quindi istanziato un oggetto Timerche allo scadere del timeout esegue il codice di DriverKiller, il quale, dopo aver terminatoil browser, si occupa anche di aggiungere un’occorrenza al log relativo allo Snapshotterinterrotto.

27

Firefox Restarter

Come immediata conseguenza della problematica precedente, e stata evidenziata la ne-cessita, prima di eseguire uno Snapshotter, di effettuare un controllo sullo stato di es-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 e terminatainaspettatamente, anche senza l’intervento della classe DriverKiller spiegata precedente-mente. Si e quindi reso necessario effettuare un piccolo controllo intercettando l’eccezioneBrowserUnreachable:

1 try{

2 driver.get("");

3 } catch(UnreachableBrowserException 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 procedecon l’esecuzione degli oggetti Snapshotter.

4.3.3 Snapshotter

La classe Snapshotter si occupa di caricare la pagina web relativa all’oggetto Site che haassociato e di creare un nuovo oggetto SiteSnapshot, con tutte le informazioni riguardantila pagina analizzata. Inoltre essa salva l’immagine dello screenshot della pagina e i file checontengono il codice HTML associato al DOM. Infine si occupa di chiamare la funzioneche esegue lo script Javascript per la rilevazione della parola ‘viagra’ nella parte visibiledella pagina.Questa classe e il principale componente della seconda funzione rappresentata in fig. 4.1.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 e un documento HTML, altrimenti termina la sua esecuzionemarcando l’oggetto Site come non-HTML

4. Controlla che Firefox abbia correttamente caricato la pagina, altrimenti terminala 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

8. Salva il file immagine dello screenshot della pagina, e lo divide in piu file se la suadimensione 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 preoccuperadi 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 dalbrowser assieme alla pagina originale, ma il codice HTML di ogni pagina e logicamenteseparato, 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’entita nel database in modo da poter gestire oggettiSiteSnapshot collegati a piu DOM, cioe a piu oggetti SiteDom.Il codice HTML della pagina originale e di ogni frame e stato recuperato attraverso ilmetodo executeScript dell’oggetto FirefoxDriver, che permette di iniettare ed eseguirecodice Javascript nella pagina caricata dal browser, restituendone gli eventuali risultati.Per prima cosa si e recuperato il codice della pagina principale iniettando lo scriptseguente:

1 return "<html >" + document.documentElement.innerHTML + "</html >";

A questo punto e stato iniettato un secondo script che restituisce tutti gli elementi cherappresentano un frame presenti nella pagina:

1 return document.querySelectorAll(’frame , iframe ’)

Per ognuno di questi si esegue nuovamente il primo script indicato per recuperare ilcodice HTML corrispondente, che verra successivamente salvato su un file.

Individuazione dei file non HTML

Il motore di ricerca Google e in grado di ricercare all’interno di tipi di file anche diversida pagine web, come ad esempio file PDF, documenti prodotti da Word Processor, Foglidi calcolo, ecc.In questo progetto gli unici file che ha senso analizzare sono i file HTML, ovvero le pagineweb, poiche possono essere oggetto dell’attacco in considerazione.Tra i risultati di ricerca ottenuti dalla classe GoogleCrawler, e anche possibile che es-istano delle occorrenze che non rappresentano pagine web. Queste occorrenze vannoopportunamente rilevate e marcate per evitare di proseguire l’analisi che risulterebbe

29

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 porterebbeall’omissione di una serie di risultati, come si puo vedere da qualche esempio di URL cheha restituito file non HTML nella nostra ricerca, anche se dall’analisi del solo indirizzonon si sarebbe potuto prevedere:

1. http://www.bury.gov.uk/azservices/ContactDetails.asp?sID=10452. http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA4608803. http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA458864

E stato osservato che, quando la risorsa recuperata risulta essere diversa da una paginaweb, 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 situazioneprecedente.Se successivamente si fosse provato a recuperare il codice sorgente della pagina, il metodoavrebbe restituito quello della pagina precedente, ancora visualizzata dietro alla finestradi dialogo.E stato quindi possibile rilevare i file non-HTML, modificando appositamente il codiceHTML della pagina immediatamente prima di recuperare la successiva. E’ stato sosti-tuito il codice con una stringa facilmente riconoscibile, che sarebbe rimasta invariata nelcaso 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 screenshotdella pagina perche venga poi analizzato dal software che si occupa della rilevazione deltesto visibile (OCR).Poiche il software che e stato scelto per questo scopo e Google Drive OCR, e stato neces-sario memorizzare le immagini su file che non superino i 2 Mb di dimensione, altrimentiil software avrebbe rifiutato di analizzare le immagini che non rispettavano questa speci-fica.Per risolvere questo problema e stato sviluppato una parte di codice che permette di

30

tagliare le immagini di dimensioni superiori in pezzi che non superino i 2 Mb.Poiche non e possibile prevedere la dimensione di un’immagine codificata partendosoltanto dai singoli bytes, l’unica possibilita e stata quella di controllare la dimensioneprodotta 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 e composto da un elevato numero di funzioni diverse; e fondamen-tale quindi, per garantire un efficiente risoluzione dei problemi, avere una buona gestionedei log degli errori.Per questo motivo e stato aggiunto l’attributo privato log nella classe SiteSnapshot incui 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 aggiungereinformazioni al log.Nella classe Snapshotter e stato successivamente inserito, all’interno di tutti i blocchi digestione delle eccezioni, una riga dedicata alla creazione di una voce nel log tramite lafunzione 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 oggettoSiteSnapshot.Poiche il campo log e parte dell’oggetto SiteSnapshot, che e una delle entita del databasegestito con la libreria Hibernate JPA, esso viene memorizzato direttamente all’internodel database, nella riga della tabella che si riferisce allo snapshot relativo, in modo darisultare di facile consultazione.

31

4.3.4 JSColorizer

JSColorizer e il metodo di Snapshotter che si occupa di applicare lo script in Javascriptper rilevare se la parola in considerazione e visibile nella pagina web oppure no.Lo script e in pratica suddiviso in due parti principali, tra le quali viene eseguito un’anal-isi da parte di codice Java, per la rilevazione del caso particolare di occultamento tramitetesto dello stesso colore dello sfondo. Questo metodo trova la sua collocazione nella terzafase descritta dallo schema di fig. 4.1.Di seguito saranno analizzate le varie parti del metodo e dello script suddivise perfunzione eseguita.

Immagini oscurate

Come gia illustrato nel capitolo relativo alla progettazione, lo script copre tutte le im-magini presenti per evitare che esse interferiscano con l’individuazione del colore con cuisuccessivamente si evidenzieranno le parole interessate.Per farlo lo script itera attraverso tutti gli elementi img presenti nella pagina e li copreintroducendo nel DOM un elemento div delle stesse dimensioni e con coordinate assoluteidentiche in modo da posizionarsi esattamente sopra all’elemento in considerazione:

1 imgs = document.getElementsByTagName(’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 proprieta di visibilita dell’immag-ine, in modo che se per qualche motivo l’immagine fosse presente ma invisibile, si evitadi coprire una parte della pagina che in realta non presentava alla vista un’immagine.Inoltre, copiando la proprieta z-index e inserendo il nuovo elemento come child del par-entNode dell’immagine in considerazione, ci si assicura che, se l’immagine e posizionatasotto ad un altro elemento, anche il div inserito si trovera in quella condizione, maesattamente sopra all’immagine.

32

Background-images

Poiche deve eliminare tutti gli elementi che contengono delle immagini, lo script deveeliminare anche tutte le immagini impostate come immagine di sfondo di un qualcheelemento nella pagina web. Per farlo, lo script itera attraverso tutti gli elementi dellapagina web alla ricerca di un’elemento che ha la proprieta css background-image diversada ‘none’. In tal caso, non ci si puo limitare ad impostarla a ‘none’, poiche in questo modolo sfondo diventerebbe invisibile e si vedrebbero eventuali componenti posizionati dietro aquello analizzato. Allora tutti gli elementi individuati che disponevano di un’immaginedi sfondo vengono modificati in modo che abbiano uno sfondo uniforme di un coloreprestabilito e opaco.

1 function backgroundImageKiller( 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 backgroundImageKiller(child);

15 }

16 child = child.nextSibling;

17 }

18 }

19 }

Un esempio di funzionamento di questa parte e dato dallo screenshot di figura 4.5, incui tutti gli elementi img sono stati coperti di nero e tutte le immagini di sfondo sonostate sostituite con il colore rosso.

Scelta colore univoco

Lo script, a questo punto, ha l’obiettivo di trovare un colore che non e mai stato utiliz-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 proprietache comportano l’uso di un colore, salvandolo in una lista, per poi scegliere casualmenteun colore non utilizzato. In pratica, lo script approfitta dell’iterazione utilizzata dalpassaggio precedente, e compila un array aggiungendoci i nuovi colori trovati per ognielemento analizzato.E’ tuttavia possibile che un colore non presente nello stile della pagina venga ugualmenteriscontrato in qualche pixel dell’immagine dello screenshot. Questo avviene perche sul-

33

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

34

l’output dello screenshot Firefox applica un filtro anti-aliasing che in prossimita di alcunicambi di colore introduce delle sfumature con colori vicini ma leggermente differenti daglioriginali.E’ stato quindi introdotto, per ogni colore individuato nella pagina, un margine di toller-anza, ed e stato richiesto che il colore univoco fosse al di fuori di questo range. In questomodo ci si e potuti assicurare che il colore scelto fosse sufficientemente diverso da quellipresenti nella pagina. Questo sistema incrementa la probabilita di non poter individuareun colore univoco nella pagina, ma in nessuno dei test effettuati si e mai riscontrato uncaso in cui lo script non e stato in grado di individuarne uno. La funzione che si occupadi trovare il colore univoco nella pagina con un margine di tolleranza e la seguente:

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 deicontrolli specifici per due tipi di occultamento che non sarebbero altrimenti rilevati. Ilprimo e il caso del testo di colore trasparente, facilmente rilevabile con un controllo sul-la proprieta CSS color, mentre il secondo caso, quello del testo dello stesso colore dellosfondo, rappresenta un problema molto piu complesso. E infatti decisamente molto com-plesso riuscire a realizzare questo controllo solamente dall’ambiente Javascript, poichenon esiste un metodo che restituisca il colore visualizzato in un certo punto della paginaweb.

35

Per effettuare questo controllo, e stato creato uno script simile a quello che individua laparola ‘viagra’ nella pagina e la evidenzia, ma destinato invece a renderla trasparente.Dopodiche lo script restituisce all’ambiente Java tutte le coordinate nelle quali si trovanole occorrenze della parola. Con Java si analizzera quindi lo screenshot della pagina, sen-za le parole interessate, calcolando la presenza percentuale dei colori nella zona in cuiavrebbe dovuto risiedere la parola. Se esiste un unico colore nella zona considerata pre-sente per il 90% o piu, si considera questo colore come il background-color della zona. Aquesto punto si confronta il colore ottenuto con il colore che il testo aveva nella paginaoriginale e, se essi corrispondono,x si e in presenza di un caso di testo e sfondo dellostesso 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 delcolore 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 laparola ‘viagra’ (2), e ad esso viene applicata una classe creata appositamente in mododa assegnare alle proprieta CSS background-color e color il colore univoco individuatoprecedentemente (3).In questo modo tutte le occorrenze della parola nella pagina, salvo quelle nascoste tramitei 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 e emerso che per effetto del filtro anti-aliasing applicato allo screen-shot, la rilevazione del colore non e sempre garantita modificando solamente il colore deicaratteri della parola ricercata.E invece risultato sufficiente per lo scopo applicare il colore univoco anche allo sfondodell’elemento span creato. Si puo vedere in figura 4.6 uno screenshot del sito web oppor-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 ognipixel dell’immagine e ricercando un particolare valore che corrisponde al colore univococon cui e stato colorata la zona in cui la parola avrebbe dovuto trovarsi.

36

Fig. 4.6: Esempio di pagina web elaborata dallo script con parola visibile evidenziatain viola

4.3.5 Analisi dei risultati del software OCR

Poiche il caricamento dei risultati sul servizio di cloud storage Google Drive non e autom-atizzato, l’unico passaggio relativo alla rilevazione OCR implementato in questo progettoe l’analisi dei file di testo risultanti dall’elaborazione degli screenshot da parte del soft-ware di Google.Questi file vanno infatti posizionati nella stessa cartella dgli screenshot, in modo che ilmetodo implementato, parseOcrFiles, li possa individuare e leggere per controllare se laparola e stata riconosciuta dal software OCR.Il metodo parseOcrFiles individua per prima cosa i file che nella cartella degli snapshothanno lo stesso nome dei file di screenshot ma con un estensione .txt aggiunta in coda.Se esistono piu file che riferiscono ad una sola pagina web, poiche lo screenshot carica-to su Google Drive era stato precedentemente diviso in piu parti perche di dimensionemaggiore ai 2Mb, li unisce in un file unico.A questo punto il metodo analizza il contenuto del file per controllare se al suo internocontiene la parola “viagra”, e memorizza nel database il risultato della ricerca.

4.3.6 Supporto Ground Truth

Per la validazione degli algoritmi proposti, e stata necessaria la compilazione della“Ground Truth”, ovvero la verifica manuale della condizione di visibilita della parolaricercata analizzando uno screenshot.Poiche la verifica della visibilita di ogni screenshot e un procedimento lungo e moltolento, e stato progettato un “helper” che aiutasse e rendesse piu rapido il controllo dellastessa.Il software progettato sfrutta lo stesso concetto che il metodo JSColorizer utilizza perindividuare 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

un colore vivace, che sia evidente alla vista dell’utente. In questo modo l’utente e fa-cilitato nella ricerca della parola nella pagina, poiche, se la parola e presente nel codiceHTML, ci sara un rettangolo colorato nella pagina che individua la sua posizione, e l’u-tente deve soltanto controllare al suo interno per verificare se la parola e leggibile oppureno. L’utente, ovviamente, deve inoltre controllare accuratamente tutte le immagini dellapagina, poiche in queste l’algoritmo non e in grado di riconoscere del testo.In figura 4.7 e 4.8 si possono osservare due parti di screenshot con la parola ricercatarispettivamente visibile e non visibile cosı come sono mostrati dall’helper.

Fig. 4.7: Esempio di screenshot mostrato dall’helper della ground truth con parolavisibile

Fig. 4.8: Esempio di screenshot mostrato dall’helper della ground truth con parola nonvisibile

38

Capitolo 5

Risultati

5.1 Raccolta dati

E’ stato testo l’effettivo funzionamento del sistema realizzato. Sono stati prelevati 100URL per ogni stringa di ricerca scelta e, poiche la ricerca e stata completata con successoper 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 nonsi riferivano a pagine web, ed effettuando lo screenshot e il salvataggio del DOM deirestanti.Infine, gli screenshot ottenuti sono stati elaborati dal software OCR ed i relativi outputsono 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 sonostati salvati screenshot e DOM, e infine risultato essere minore dei 900 URL raccoltidalla ricerca iniziale.Si e infatti rilevato che durante il procedimento, non e stato possibile generare unosnapshot da tutti gli URL, poiche appartenenti ad una delle seguenti categorie:

• URL di documenti non HTML

• URL che hanno restituito qualche errore durante l’elaborazione

URL Totale URL Totale Totale HTML Totale conTotali non HTML Falliti completati parola nel DOM

900 96 18 786 312

Si puo vedere un grafico degli URL analizzati in figura 5.1.

39

Fig. 5.1: Un pie chart degli URL processati

Risorse non HTML

Si e notato che su un totale di 900 URL disponibili, il 10.6% rappresentava risorse nonHTML, che non sono quindi state analizzate ulteriormente.Questo si verifica perche il motore di ricerca Google, utilizzato nella compilazione dellalista di URL, ha la capacita di indicizzare anche risorse diverse da pagine web, e nerestituisce 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 e probabilmente una peculiarita del tipo di ricercain considerazione.

Snapshot interrotti da un errore

Ci sono poi stati altri 18 casi in cui il software non e stato in grado di effettuare losnapshot dell’indirizzo prelevato dal database. Questi casi rappresentano degli URL chehanno in qualche momento dell’elaborazione provocato un errore che non ha permessodi completare lo snapshot.Si mostrano ora questi 18 casi, suddivisi per tipo di errore che e stato registrato nel logper ognuno di essi.

Numerodi 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

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 mostratouna pagina di errore invece di caricare l’URL: questo potrebbe essere dovuto a motividiversi, anche se un’analisi effettuata sui risultati durante i test del software ha mostratoche 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 harestituito 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: 0x80004005 (NS_ERROR_FAILURE)

[nsIDOMCanvasRenderingContext2D.drawWindow]" nsresult: "0

x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file :///

tmp/anonymous4262018683082470387webdriver -profile/extensions/

fxdriver@googlecode.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: 3ee267ea -415e-45ff-a676 -1 f3be0830d34

Pagine senza la parola ricercata

Lo snapshot per le restanti 786 pagine e stato eseguito correttamente, salvando screen-shot e file HTML del DOM.Di queste pagine, soltanto 312, ovvero appena il 39.7%, contenevano effettivamente laparola ‘viagra’ al loro interno, nonostante la parola chiave fosse stata specificata es-plicitamente nella ricerca sul motore di ricerca Google. Questa e evidentemente unaparticolarita del tipo di ricerca effettuata, infatti e raro che un motore di ricerca resti-tuisca un risultato che non contiene la parola cercata.Poiche i motori di ricerca utilizzano, per indicizzare una pagina, anche le informazionifornite dai link che vi conducono, questo e teoricamente possibile, ma in questo casol’ipotesi piu probabile e che la pagina web sia stata modificata successivamente all’indi-cizzazione del motore di ricerca.Questo e particolarmente vero se si pensa al fatto che una buona parte dei siti ricer-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 laconsapevolezza.

41

5.2 Rilevazione testo nascosto

Il software progettato e sviluppato ha come obiettivo la rilevazione di testo nascosto allavista dell’utente nella pagina web analizzata.Nel corso di questo documento sono stati presentati due metodi che si propongono comesoluzione al problema:

• Il metodo DOM e OCR

• Il metodo DOM e Javascript

Ora si analizzeranno i risultati che questi due metodi hanno ottenuto confrontati conla Ground Truth rilevata manualmente, in base alla quale poi sono stati calcolati ancheprecision 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 da informazioni sull’affid-abilita del metodo nel rilevare il testo nascosto.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 da informazioni su quante pagine che avrebbero dovuto essere rilevatesono state tralasciate dal metodo.

La seguente tabella elenca i metodi per la rilevazione del testo nascosto proposti inquesto progetto.Il primo metodo “DOM” indica la scelta di valutare come pagine con testo nascosto tuttele pagine trovate contenenti nel codice la parola ‘viagra’.Il secondo metodo “!OCR” indica invece che si considerano positive tutte le pagine chenon presentano nei risultati dell’OCR la parola trovata.Questi due metodi sono stati aggiunti per completezza nella tabella, ma si puo vedere chei relativi risultati sono scoraggianti, provando che non e sufficiente valutare soltanto ilcodice 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 problemadurante 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 pagineche 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 capitoliprecedenti, che individua le pagine che contengono la parola nel DOM e in cui, secondol’analisi effettuata con il codice Javascript e lo screenshot, queste occorrenze non risultanovisibili.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 testonascosto

42

• Ground Truth - le pagine in cui il testo e realmente nascosto (rilevate manualmente)

• Precision - il valore della precision calcolata sui veri positivi e falsi negativi nellatabella sucessiva

• Recall - il valore della recall calcolata sui veri positivi e falsi positivi mostrati nellatabella sucessiva

Pagine Pagine GroundMetodo 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 FalseMetodo 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 dueha invece presentato falsi negativi. Si analizza ora nello specifico i casi che sono risultatiin 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 metodoclassificava le pagine come“pagine con testo nascosto”quando in realta esse non lo erano.Gli errori sono da ricondursi ad una rilevazione OCR imprecisa, in cui il testo era presentenella parte visibile ma il software OCR non e stato in grado di riconoscerlo. Nella figura5.2 si mostra una parte di screenshot con la parola ‘viagra’ presente ma dalla quale ilsoftware 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 e statoin grado di rilevare una parola visibile.Il caso e interessante, poiche evidenzia una limitazione dell’algoritmo: la parola si trovavaall’interno dell’attributo “value” di una casella di testo, dove non poteva essere rilevatadallo script che cerca la parola solo al di fuori dei tag HTML.

43

(a)

(b)

Fig. 5.2: (a) Una delle parole non rilevate dal software OCR con (b) il testo che hainvece 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 incui era posizionata nella pagina

5.4 Confronto metodi proposti

5.4.1 Precision & Recall

Analizzando i risultati si puo concludere che entrambi i metodi si sono rivelati piut-tosto soddisfacenti nella rilevazione del testo nascosto. In particolare, il metodo DOM eJavascript ha ottenuto dei risultati eccellenti, con una precision superiore al 99%, pari

44

ad un solo falso positivo..

Entrambi i metodi hanno inoltre mostrato una recall pari al 100% che indica unatendenza a non riscontrare falsi negativi. Per entrambi i metodi e infatti improbabilerilevare la parola nella parte visibile quando questa non e effettivamente presente.

5.4.2 Tempi di esecuzione

Durante l’esecuzione degli snapshot sono stati misurati i tempi di completamento perogni snapshot eseguito, in modo da avere una stima della durata media di un genericosnapshot. Questi tempi sono stati misurati su una macchina server Linux che disponedi 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 Javascripte Java del metodo DOM e Javascript e parte della creazione degli snapshot, di cui e sta-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 e di poco superioreai 120 secondi.Tuttavia e necessario notare che durante la creazione degli snapshot le istanze di firefoxe di conseguenza i thread che creano snapshot eseguiti contemporaneamente erano paria 4, riducendo il tempo medio per snapshot a 4.06 secondi, considerabile come limitesuperiore per l’esecuzione del metodo DOM e Javascript.Per quanto riguarda invece il metodo DOM e OCR, i tempi di esecuzione risultano leg-germente piu elevati.Purtroppo la scelta di utilizzare il software OCR di Google Drive ha imposto la necessitadi eseguire l’upload del file immagine dello screenshot sul servizio di storage per eseguirel’elaborazione, e successivamente di eseguire il download del file di testo elaborati, didimensioni molto piu ridotte.Inoltre l’esecuzione del software OCR, benche avvenga sul server, richiede un tempo dicalcolo molto piu elevato dell’esecuzione dello script javascript, e Google Drive consentedi caricare ed elaborare un solo file alla volta.

5.4.3 Considerazioni sui risultati

Si puo in definitiva concludere che il metodo DOM e Javascript si e rivelato piuttostosuperiore al metodo DOM e OCR in relazione al problema considerato, mostrando unaprecision molto piu elevata e dei tempi di esecuzione molto piu ridotti, nonche la possi-bilita di essere eseguito in modo completamente automatizzato.Dai risultati ottenuti si puo inoltre osservare che le limitazioni dei metodi evidenziatenel corso di questo documento non sembrano aver influito sulla loro efficacia nell’ambitodi questo studio.Non si deve tuttavia generalizzare questi risultati senza condurre ulteriori test, poiche

45

il campione di pagine web scelto per lo studio e troppo poco ampio ed eterogeneo perconsentire questo tipo di considerazioni.

5.5 Utilizzo

5.5.1 Pacchetto Jar

Il risultato del progetto e un pacchetto JAR eseguibile, in grado di eseguire tutte lefunzioni descritte nei capitoli precedenti. L’eseguibile riceve in ingresso dei parametri estampa a video le informazioni relative all’esecuzione.Il software e stato progettato specificatamente per l’utilizzo nel laboratorio MachineLearning del D.I.A. presso l’Universita degli Studi di Trieste, pertanto e configurato inmodo da connettersi al database della rete del laboratorio.Per specificare un server diverso, e necessario modificare l’opportuna occorrenza nel filepersistence.xml presente all’interno del pacchetto JAR.Inoltre, le stringhe di ricerca per il componente GoogleCrawler devono essere inserite neldatabase 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 GoogleCrawlerIl parametro n indica il numero massimo di risultati per ogni stringa di ricerca

s [n] Effettua degli snapshot degli url presenti nel databaseIl 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

Capitolo 6

Conclusioni

6.1 Obiettivi raggiunti

L’obiettivo del progetto e stato di ideare ed implementare un software che recupera unalista di URL, le analizzi per verificare se le corrispondenti pagine web contengono al lorointerno del testo nascosto.Alla luce di cio che e stato esposto nei capitoli precedenti, si puo dire che gli obiettividel progetto sono stati raggiunti.Il software progettato infatti consente di compilare una lista di URL a partire da unaserie 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 intermini 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, sonostate evidenziate delle limitazioni piuttosto importanti dell’approccio scelto per i duemetodi, che potrebbero facilmente decrementare le prestazione degli stessi se utilizzatiin contesti diversi, come ad esempio con pagine di realizzazione piu recente e moderna,con un elevato numero di funzionalita implementate per mezzo di script.

6.2 Sviluppi futuri

Le limitazioni evidenziate nel corso dei precedenti capitoli individuano un problema neltipo di approccio usato per la rilevazione del testo visibile.In una pagina web alcune parti di contenuto possono non essere inizialmente visibilinonostante esse siano comunque accessibili in seguito ad un’interazione con la paginatramite qualche tipo di input. Tutti questi tipi di componenti, che sono per la maggiorparte implementati tramite scripting lato client ma non solo, mettono in difficolta glialgoritmi proposti, che si limitano a considerare come contenuto legittimo tutto cio chee visibile nonappena la pagina sia stata caricata completamente.Degli eventuali sviluppi futuri potrebbero considerare la possibilita di superare questo

47

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

Ringraziamenti

Desidero innanzitutto ringraziare Enrico per avermi corretto gli errori di compilazionedi latex, un’apostrofo qua e uno la e per aver addirittura, inserito qualche virgola, ecorretto le ‘Oxford comma’. Hai fatto molto di piu di quello che dovevi. Grazie.

Un ringraziamento va ad Andrea, perche la sua presenza nel laboratorio rallegra legiornate anche quando non c’e niente da ridere.

Un grazie va a Giorgio, per avermi fatto capire fin dal primo giorno che io non soniente e voi sapete tutto.

Un grazie anche ad Eric, per il suo umorismo che attraverso Google Talk spesso ar-rivava anche nel laboratorio.

Un grazie al professor Bartoli, anche se le sue battute non le ho quasi mai capite, aparte ‘ti distruggo la presentazione’. Quella l’ho capita bene.

Un ringraziamento sincero va ai miei genitori, che mi hanno sostenuto sempre du-rante questo percorso.

Ringrazio infine Silvia, fedele e irrequieta, che ha con difficolta accettato il fatto chein questi giorni l’avrei trascurata.

E si, ancora un ultimo ringraziamento va a tutti i miei amici, soprattutto chi mi evenuto a trovare la sera sapendo che non sarei potuto uscire, riuscendo ugualmente afarmi fare tardi. Si capisce che non ha senso?

Ultimo forse anche per importanza, ma doveroso, un grazie a Max per avermi aiutatoa fare la ground truth. Senza il mio helper non sarebbe stato cosı facile. Ma grazie.

Se mi permetto di scrivere queste cose e perche i ragazzi del laboratorio mi hannodetto che la tesi non la legge nessuno. La colpa e loro.

49