Your SlideShare is downloading. ×
Progetto e Realizzazione di un Software per la Rilevazione Automatica di Codice HTML Nascosto e Fraudolento in Pagine Web
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Progetto e Realizzazione di un Software per la Rilevazione Automatica di Codice HTML Nascosto e Fraudolento in Pagine Web

641

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
641
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ` Universita degli studi di Trieste ` Facolta di Ingegneria Tesi di Laurea in Ingegneria dell’Informazione curriculum informaticaProgetto 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
  • 2. ` Universita degli studi di Trieste ` Facolta di Ingegneria Tesi di Laurea in Ingegneria dell’Informazione curriculum informaticaProgetto 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. Ai miei genitori
  • 4. Indice1 Introduzione 72 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 . . . . . . . . . . . . . . . . . . . 103 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 214 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
  • 5. 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 . . . . . . . . . . . . . . . . . . . . . . . . 375 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 Conclusioni 47 6.1 Obiettivi raggiunti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.2 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Ringraziamenti 49 6
  • 6. Capitolo 1IntroduzioneGli attacchi “Hidden Text Injection” sono attacchi informatici diffusi recentemente checolpiscono l’integrit` dei siti web: essi consistono nell’inserimento, all’interno delle pagine aweb 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 poich` non apporta modifiche evisibili 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 ` una pratica di Search Engine Op- etimization 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 ` concentrato particolarmente sulla creazione di un sistema eper la valutazione della visibilit` del testo nella pagina. La relativa analisi ha portato alla arealizzazione di due metodi distinti per la risoluzione del problema: il primo metodo, cheutilizza un’analisi OCR, ` stato proposto come soluzione al momento dell’assegnazione edel progetto, mentre il secondo metodo ` stato da me ideato durante la fase di proget- etazione. 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 esospettate di essere vittima dell’attacco, ed in seguito di classificarle utilizzando i duemetodi sviluppati per l’individuazione di testo nascosto. Il progetto ` stato realizzato presso il laboratorio Machine Learning del D.I.A. del- el’Universit` degli Studi di Trieste. Poich` il progetto ha visto l’integrazione di un com- a eponente precedentemente sviluppato presso il laboratorio, per motivi di compatibilit` ` aestato richiesto che il progetto si avvalesse delle seguenti tecnologie software: 7
  • 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 programmaticoIl capitolo “’Scenario” fornisce una panoramica un pi` dettagliata sul problema analiz- uzato 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
  • 8. Capitolo 2Scenario2.1 Scopo del progettoLo 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 ` quindi realizzato un sistema capace di individuare, eall’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 Modalit` di realizzazione aL’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. Ci` rendendo difficile ol’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 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 possonoportare, 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 esono in questo senso molto pericolosi proprio perch` difficili da individuare, e che possono ecostituire un danno importante per un dominio nel momento in cui esso viene rimossodai 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
  • 9. 2.2.2 Finalit` aLe tecniche di “Hidden Text Injection” possono essere suddivise a seconda del tipo dicodice iniettato: 1. Inserimento di link nascosti 2. Inserimento di testo nascostoEntrambe 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 emodificare 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 modalit` e le finalit` dell’attacco differiscono in modo sostanziale a atra i due casi appena citati che saranno presentate brevemente nei paragrafi seguenti.Introduzione di codice contenente link nascostiI 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` ıpi` importanza ai link che si trovano su pagine con punteggio pi` elevato e, di con- u useguenza, in genere pi` autorevoli. uL’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, poich` i motori di ricerca come Google considerano anche la pagina che ospita il elink per il calcolo del punteggio, un attaccante preferir` introdurre questi link su siti pi` a uautorevoli, guadagnando visibilit` sui motori di ricerca in modo pi` veloce ed efficace. a uIntroduzione di codice contenente testo nascostoI motori di ricerca, per indicizzare una pagina, analizzano il suo codice e ne estraggonole parti di testo al suo interno. Poich´ si occupano di valutarne soltanto il contenuto, enon 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, 3 http://en.wikipedia.org/wiki/Spamdexing 10
  • 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 finalit` di questo tipo di attacco ` la “SearchRedirection”4 , in cui l’at- a etaccante 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 visibilit`. Lo script si cura di reindirizzare alla pagina designata soltanto agli 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’affidabilit` del sito vittima intro- aducendo delle nuove parole chiave per le quali poi si ` reindirizzati su una pagina diversa, eche 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
  • 11. 12
  • 12. Capitolo 3Progettazione3.1 Struttura del progettoIl 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 pu` vedere in figura 3.1. o3.1.1 Panoramica della soluzione progettataLe 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 webLa compilazione della lista di pagine web da analizzare ` stata svolta attraverso ricerche emirate con il motore di ricerca Google, che ` di fatto il principale obiettivo della ma- enipolazione effettuata dall’attacco.Le stringhe da ricercare sono state scelte cercando gi` a questo punto di effettuare una aprima selezione di pagine che hanno una buona probabilit` di aver subito questo tipo di aattacco. 13
  • 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 ` 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 viagra2 site : gov viagra3 site : gov . au viagra4 site : mil viagra5 site : museum viagra6 site : gov . in viagra7 site : mil . in viagra8 site : edu . in viagra 14
  • 14. Fig. 3.2: Il flow chart che rappresenta l’analisi del problema9 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
  • 15. Analisi del DOM (Document Object Model) della pagina webPer ricercare la parola nel codice della pagina, ` stato deciso di procedere con l’analisi edel 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, ` che in questo modo si pu` ottenere un listato di codice HTML molto pi` e o uvicino a quello che viene di fatto visualizzato dall’utente. Questo accade poich` spesso edegli script della pagina web, inclusi nel codice originario, modificano la struttura dellapagina 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. oL’analisi effettuata sul DOM ` quindi un efficace metodo per controllare se il testo ericercato ` presente all’interno della pagina web in considerazione. Da notare che fino ad eora non si ` fatto alcun riferimento alla visibilit` della parola, o del testo, nella pagina e ache viene visualizzata dall’utente.Analisi della parte visibileUna 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 ` visibile eoppure 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 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 screenshot3.2 Metodo DOM e OCR3.2.1 IdeaIl 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
  • 16. 3.2.2 Confronto risultati DOM e OCRUna volta ottenuti dei risultati dall’analisi dell’immagine con il software OCR, si verificase la parola cercata ` presente nel codice del DOM ma non nel testo riconosciuto nello escreenshot.In questo caso la pagina sar` considerata una probabile vittima di un attacco Hidden aText 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 diversit` delle dimensioni dei caratteri e il gran numero di avariet` di colori nelle pagine web possono abbassare di molto l’efficacia di questi algorit- ami. Per questo motivo si ` resa necessaria una piccola ricerca tra i pi` comuni software e uOCR per la scelta di quello che si sarebbe dimostrato pi` accurato nella rilevazione di utesto 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 Javascript3.3.1 IdeaIl 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 ` stata la trasformazione del problema edi ricerca del testo in un’immagine in un problema pi` analitico, non soggetto alle limi- utazione del software OCR.Un software non pu` leggere un testo da un’immagine con facilit`, cio` capire se l’in- o a esieme dei pixel trovati rappresenta una lettera oppure un disegno, ma pu` facilmente oiterare 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- euare) con un colore univoco, in modo che un software possa facilmente individuare la 2 http://en.wikipedia.org/wiki/Optical character recognition 17
  • 17. modifica. In questo modo il software ` in grado di individuare nella pagina la parola ecercata, solo se visibile anche nella pagina originale.3.3.2 ProblematicheCi` che ` stato descritto nel paragrafo precedente non ` per` del tutto esatto, in quanto o e e oesistono delle considerazioni preliminari che vanno affrontate prima di poter approcciareil problema con questo tipo di soluzione.Occultamento di testo per mezzo del colore del fontLa 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 edell’algoritmo, questa non deve alterare la condizione di visibilit` del testo su cui ` ef- a efettuata.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 sfondoQuesti 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 univocoLa 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 eessario che nemmeno un pixel dell’immagine analizzata presenti il codice corrispondenteal colore individuato come univoco. Bench´ lo spettro elettromagnetico delle frequenze edel visibile sia da un punto di vista fisico uno spettro continuo, che corrisponde in praticaad un numero illimitato di colori, ` ben noto che non esiste modo di rappresentare infiniti ecolori in un numero limitato di bit, che ` quello di cui si dispone quando si modellizzano ei colori in un computer.Visto che il numero di colori effettivamente utilizzabili in una pagina web ` quindi limita- eto, ` teoricamente possibile che non esista un colore univoco in una determinata pagina eweb.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 = 16777216contenuti ad esempio in un immagine di 4096x4096 pixel. 18
  • 18. 3.3.3 LimitazioniUna limitazione nota di questo approccio ` l’impossibilit`, per uno script del tipo de- e ascritto, 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 pu` fornire alcun risultato per questi elementi. Alla luce di questo fatto, o` stato ritenuto ragionevole, anche per motivi implementativi, coprire tutte le immaginiepresenti con un unico colore prestabilito, in modo da ridurre il numero di colori utilizzatie rendere pi` facile la ricerca di colore univoco. u3.3.4 PanoramicaAnche 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 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 parolaDopo l’esecuzione dello script, si analizza lo screenshot della pagina, il cui aspetto ` stato eprobabilmente modificato dallo script, e si stabilisce se al suo interno ` presente il colore econ 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 ` stata rilevata all’interno del codice della pagina, questa sar` classificata da e aquesto 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 opagina con le immagini coperte di nero e le parole individuate evidenziate con un coloreunivoco. 19
  • 19. Fig. 3.3: Un’esempio di pagina elaborata dallo script3.4 LimitazioniGli 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 screenshotL’analisi dello screenshot della pagina web ` stata presa in considerazione poich´ ` un e eeeccellente metodo per osservare e analizzare esattamente quello che l’utente si trovadavanti quando visualizza la pagina web. Esso ` stato sfruttato per cercare di capire equali parti di testo vengono visualizzati e quali altri no, ricercando la loro presenzaall’interno di quest’immagine.Esiste per` un problema di fondo in questo approccio: le pagine web possono contenere odelle parti o dei componenti interattivi, cio` che reagiscono ad un input dell’utente emodificando 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, poich´ prevedono l’indirizzamento ad una pagina diversa. e 20
  • 20. ScrollBarEsistono altri componenti che per` prevedono una modifica della struttura o dei contenuti ovisivi rimanendo nel contesto della stessa pagina: tra i pi` comuni componenti di questo utipo troviamo le scrollbar, di cui un esempio riscontrato durante la raccolta dei risultatisi pu` vedere in figura 3.4. o Fig. 3.4: Screenshot che evidenzia uno dei limiti degli algoritmi propostiScriptUn’altra componente delle pagine web che pu` operare in questo modo sono gli script. oGli 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 immaginiUn altra limitazione, che interessa solo il secondo metodo proposto, quello DOM eJavascript, ` che lo script si limita a ricercare e rilevare il testo contenuto nel codice eHTML 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
  • 21. inevitabilmente un’analisi da parte di un algoritmo OCR, che nel metodo considerato si` voluto evitare.e 22
  • 22. Capitolo 4Implementazione Fig. 4.1: Uno schema delle funzioni del software progettato4.1 Tecnologie utilizzatePer 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
  • 23. 4.1.1 Hibernate JPA (Java Persistence API)Java Persistence API1 ` un framework che permette la gestione di un database relazionale edall’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 ` Hibernate JPA 1.0. e4.1.2 Selenium WebDriverSelenium WebDriver ` un API che permette di controllare il browser dal linguaggio di eprogrammazione. 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 ` stata utilizzata per controllare il browser eMozilla Firefox.4.1.3 Scelta del software OCRPer la scelta del software OCR si ` resa necessaria una piccola ricerca preliminare, per evalutare quale software ottenesse risultati pi` soddisfacenti se usato con immagini di upagine 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 OCRI primi semplici test su un set limitato di pagine web sottoposte hanno mostrato unevidente superiorit` del software di Google, dando risultati deludenti nel caso degli altri adue software proposti. A differenza dei primi due, il motore OCR di Google Drive ` eprobabilmente 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 acome nel caso di questo progetto.4.1.4 Google Drive OCRIl software di riconoscimento ottico di caratteri (OCR) integrato in Google Drive2 ` efornito come servizio gratuito per chi dispone di un account Google, e pu` essere eseguito oautomaticamente 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 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
  • 24. Fig. 4.2: Lo schema logico del database implementato • I file vengono caricati ed elaborati dal software OCR uno alla voltaIl software ` utilizzabile unicamente attraverso il servizio di storage, caricando i file eimmagine sul server remoto, attendendo il completamento della conversione e scaricandosuccessivamente i risultati.4.2 Database4.2.1 Entit` / Classi JPA aIl database ` stato creato utilizzando il DBMS MySql. Lo schema logico delle entit` ` e aestato 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 Classi4.3.1 GoogleCrawlerGoogleCrawler ` la classe responsabile della compilazione della lista di URL sui quali epoi 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
  • 25. Fig. 4.3: Diagramma UML della classe SnapshotterFig. 4.4: Alcuni diagrammi UML delle restanti classi sviluppate 26
  • 26. un determinato numero di risultati della ricerca sul motore Google della stringa Site-Class.name .4.3.2 WebDriverControllerLa 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 eoggetti 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 pi` istanze di Firefox allo stesso tempo per permettere una uparallelizzazione del lavoro degli oggetti Snapshotter, che si occupano di ogni singolo urlda 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 analizzarealla lista di task. Sar` proprio in questo metodo che la classe WebDriverController creer` a aun nuovo oggetto Snapshotter per l’analisi dell’oggetto Site passato.L’intero id ` un numero che identifica univocamente l’oggetto Snapshotter associato al eSite 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 eoggetti Snapshotter creati e salvati in una lista.In questo punto si ` resa necessaria la gestione di due problematiche, che vengono eapprofondite di seguito:DriverKillerE’ stata evidenziata in fase di test una certa instabilit` delle librerie Selenium WebDriver, ache 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, pu` accadere che l’oggetto oJava 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 ` stata progettata un’ulteriore classe denominata eDriverKiller, che si occupa di gestire un timeout indipendente e di terminare l’istanza diFirefox, una volta che esso ` scaduto. eAll’interno della classe WebDriverController ` stato quindi istanziato un oggetto Timer eche 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
  • 27. 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
  • 28. 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
  • 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 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
  • 30. 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 parts3 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
  • 31. 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
  • 32. 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 }78 storeColors ( element ) ;910 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
  • 33. Fig. 4.5: Esempio di pagina web elaborata dallo script con immagini coperte di nero eimmagini di sfondo sostituite dal colore rosso 34
  • 34. 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: e1 function univokeColor () {2 tolleranza = 7;3 c = ’ ’;4 found = false ;5 red = 0;6 green = 0;7 blue = 0;89 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
  • 35. Per effettuare questo controllo, ` stato creato uno script simile a quello che individua la eparola ‘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 ele occorrenze della parola. Con Java si analizzer` quindi lo screenshot della pagina, sen- aza 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 pi`, si considera questo colore come il background-color della zona. A uquesto punto si confronta il colore ottenuto con il colore che il testo aveva nella paginaoriginale e, se essi corrispondono,x si ` in presenza di un caso di testo e sfondo dello estesso colore.Evidenziazione della parola ricercataL’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 univocoLa 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 propriet` CSS background-color e color il colore univoco individuato aprecedentemente (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 ` emerso che per effetto del filtro anti-aliasing applicato allo screen- eshot, la rilevazione del colore non ` sempre garantita modificando solamente il colore dei ecaratteri della parola ricercata.`E invece risultato sufficiente per lo scopo applicare il colore univoco anche allo sfondodell’elemento span creato. Si pu` vedere in figura 4.6 uno screenshot del sito web oppor- otunamente elaborato dallo script e pronto ad essere analizzato per la ricerca del colore.Risultati: analisi screenshotL’ultimo passaggio consiste nell’ottenere uno screenshot ed analizzarlo, scorrendo ognipixel dell’immagine e ricercando un particolare valore che corrisponde al colore univococon cui ` stato colorata la zona in cui la parola avrebbe dovuto trovarsi. e 36
  • 36. Fig. 4.6: Esempio di pagina web elaborata dallo script con parola visibile evidenziatain viola4.3.5 Analisi dei risultati del software OCRPoich´ il caricamento dei risultati sul servizio di cloud storage Google Drive non ` autom- e eatizzato, 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-eware 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 ` stata riconosciuta dal software OCR. eIl 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 pi` file che riferiscono ad una sola pagina web, poich´ lo screenshot carica- u eto su Google Drive era stato precedentemente diviso in pi` parti perch´ di dimensione u emaggiore 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 TruthPer la validazione degli algoritmi proposti, ` stata necessaria la compilazione della e“Ground Truth”, ovvero la verifica manuale della condizione di visibilit` della parola aricercata analizzando uno screenshot.Poich´ la verifica della visibilit` di ogni screenshot ` un procedimento lungo e molto e a elento, ` stato progettato un “helper” che aiutasse e rendesse pi` rapido il controllo della e ustessa.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
  • 37. un colore vivace, che sia evidente alla vista dell’utente. In questo modo l’utente ` fa-ecilitato nella ricerca della parola nella pagina, poich`, se la parola ` presente nel codice e eHTML, ci sar` un rettangolo colorato nella pagina che individua la sua posizione, e l’u- atente deve soltanto controllare al suo interno per verificare se la parola ` leggibile oppure eno. L’utente, ovviamente, deve inoltre controllare accuratamente tutte le immagini dellapagina, poich` in queste l’algoritmo non ` in grado di riconoscere del testo. e eIn 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 parolavisibileFig. 4.8: Esempio di screenshot mostrato dall’helper della ground truth con parola nonvisibile 38
  • 38. Capitolo 5Risultati5.1 Raccolta datiE’ stato testo l’effettivo funzionamento del sistema realizzato. Sono stati prelevati 100URL per ogni stringa di ricerca scelta e, poich´ la ricerca ` stata completata con successo e eper 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 snapshotIl numero di snapshot realmente effettuato, ovvero il numero di URL per i quali sonostati salvati screenshot e DOM, ` infine risultato essere minore dei 900 URL raccolti edalla ricerca iniziale.Si ` infatti rilevato che durante il procedimento, non ` stato possibile generare uno e esnapshot 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 312Si pu` vedere un grafico degli URL analizzati in figura 5.1. o 39
  • 39. Fig. 5.1: Un pie chart degli URL processatiRisorse non HTMLSi ` notato che su un totale di 900 URL disponibili, il 10.6% rappresentava risorse non eHTML, che non sono quindi state analizzate ulteriormente.Questo si verifica perch` il motore di ricerca Google, utilizzato nella compilazione della elista di URL, ha la capacit` di indicizzare anche risorse diverse da pagine web, e ne arestituisce 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 ain considerazione.Snapshot interrotti da un erroreCi sono poi stati altri 18 casi in cui il software non ` stato in grado di effettuare lo esnapshot 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 ` stato registrato nel log eper 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
  • 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 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 milliseconds4 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 : WebDriverDriver7 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
  • 41. 5.2 Rilevazione testo nascostoIl 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 JavascriptOra 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 d` informazioni sull’affid- aabilit` del metodo nel rilevare il testo nascosto. aPer 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 asono 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 pu` vedere che oi relativi risultati sono scoraggianti, provando che non ` sufficiente valutare soltanto il ecodice 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 testo nascosto 42
  • 42. • 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 05.3 Analisi dei falsi positiviEntrambi 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 OCRIl 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 realt` esse non lo erano. aGli errori sono da ricondursi ad una rilevazione OCR imprecisa, in cui il testo era presentenella parte visibile ma il software OCR non ` stato in grado di riconoscerlo. Nella figura e5.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 JavascriptIl metodo DOM e Javascript ha riportato un solo caso di falso positivo, dove non ` stato ein grado di rilevare una parola visibile.Il caso ` interessante, poich´ evidenzia una limitazione dell’algoritmo: la parola si trovava e eall’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
  • 43. (a) (b)Fig. 5.2: (a) Una delle parole non rilevate dal software OCR con (b) il testo che hainvece riconosciutoSi 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 pagina5.4 Confronto metodi proposti5.4.1 Precision & RecallAnalizzando i risultati si pu` concludere che entrambi i metodi si sono rivelati piut- otosto 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
  • 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 ` infatti improbabile erilevare la parola nella parte visibile quando questa non ` effettivamente presente. e5.4.2 Tempi di esecuzioneDurante 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 ` parte della creazione degli snapshot, di cui ` sta- e eta 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 eai 120 secondi.Tuttavia ` necessario notare che durante la creazione degli snapshot le istanze di firefox ee 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 pi` elevati. uPurtroppo la scelta di utilizzare il software OCR di Google Drive ha imposto la necessit` adi 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 pi` ridotte. uInoltre l’esecuzione del software OCR, bench` avvenga sul server, richiede un tempo di ecalcolo molto pi` elevato dell’esecuzione dello script javascript, e Google Drive consente udi caricare ed elaborare un solo file alla volta.5.4.3 Considerazioni sui risultatiSi pu` in definitiva concludere che il metodo DOM e Javascript si ` rivelato piuttosto o esuperiore al metodo DOM e OCR in relazione al problema considerato, mostrando unaprecision molto pi` elevata e dei tempi di esecuzione molto pi` ridotti, nonch´ la possi- u u ebilit` di essere eseguito in modo completamente automatizzato. aDai risultati ottenuti si pu` inoltre osservare che le limitazioni dei metodi evidenziate onel 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, poich´ e 45
  • 45. il campione di pagine web scelto per lo studio ` troppo poco ampio ed eterogeneo per econsentire questo tipo di considerazioni.5.5 Utilizzo5.5.1 Pacchetto JarIl risultato del progetto ` un pacchetto JAR eseguibile, in grado di eseguire tutte le efunzioni descritte nei capitoli precedenti. L’eseguibile riceve in ingresso dei parametri estampa a video le informazioni relative all’esecuzione.Il software ` stato progettato specificatamente per l’utilizzo nel laboratorio Machine eLearning del D.I.A. presso l’Universit` degli Studi di Trieste, pertanto ` configurato in a emodo da connettersi al database della rete del laboratorio.Per specificare un server diverso, ` necessario modificare l’opportuna occorrenza nel file epersistence.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.ParametriL’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
  • 46. Capitolo 6Conclusioni6.1 Obiettivi raggiuntiL’obiettivo del progetto ` stato di ideare ed implementare un software che recupera una elista di URL, le analizzi per verificare se le corrispondenti pagine web contengono al lorointerno del testo nascosto.Alla luce di ci` che ` stato esposto nei capitoli precedenti, si pu` dire che gli obiettivi o e odel 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 pi` recente e moderna, ucon un elevato numero di funzionalit` implementate per mezzo di script. a6.2 Sviluppi futuriLe 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 difficolt` gli aalgoritmi proposti, che si limitano a considerare come contenuto legittimo tutto ci` che o` visibile nonappena la pagina sia stata caricata completamente.eDegli eventuali sviluppi futuri potrebbero considerare la possibilit` di superare questo a 47
  • 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
  • 48. RingraziamentiDesidero innanzitutto ringraziare Enrico per avermi corretto gli errori di compilazionedi latex, un’apostrofo qua e uno l` e per aver addirittura, inserito qualche virgola, e acorretto le ‘Oxford comma’. Hai fatto molto di pi` di quello che dovevi. Grazie. u Un ringraziamento va ad Andrea, perch` la sua presenza nel laboratorio rallegra le egiornate anche quando non c’` niente da ridere. e 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 difficolt` accettato il fatto che ain 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 ` perch` i ragazzi del laboratorio mi hanno e edetto che la tesi non la legge nessuno. La colpa ` loro. e 49

×