Implementazione e strumenti

La tecnologia server side adottata in questa prima versione per la realizzazione di un sistema atto all'interazione utente, che permettesse di rendere fruibile lo strumento di acquisizione tramite la metafora del “meta-browser annidato”, è stata basata prevalentemente sull’uso di Python3 congiuntamente all'utilizzo del frame-work Flask (http://flask.pocoo.org/) e della libreria Requests (http://docs.python-requests.org/en/ma ster/).

Flask

Flask viene definito dai suo stessi ideatori come un “microframework” (micro like as “micro-kernel), cioè una struttura “core” flessibile con minime funzionalità, concentrate nel definire determinate convezioni che aiutino a rendere l'ambiente omogeneo – con supporto al pattern MVC e alle estensioni – così da permettere di ampliare le potenzialità dell'ambiente di lavoro in base alle reali necessità. Inoltre offre un sistema di configurazione e di esecuzione centralizzato così da rendere l'ambiente facilmente gestibile con un approccio comune che sia trasversale a tutte le estensioni. Flask per esempio non ha un suo sistema ORM prefissato o un sistema di gestione di ruoli e utenze già integrato, ma sono aspetti che risultano facilmente aggiungibili in base alle proprie necessità e le relative extensions.

Risultano abbastanza ovvie le motivazioni che hanno spinto verso la scelta di Flask come framework su cui basare il progetto, in quanto si era alla ricerca di un prodotto che potesse offire un ragionevole compromesso tra avere dei solidi binari di partenza che permettessero di disporre di una struttura di riferimento e allo stesso tempo disporre di un’ampia libertà di scelta implementativa, il tutto senza aggiungere overhead di librerie che difficilmente sarebbero state utilizzate; per esempio, era stata anche valutata la possibilità di utilizzare Django, ma lo si è ritenuto troppo monolitico e troppo constringente, prevedendo che con esso si sarebbe corso il rischio di avere un prodotto che interferisse troppo nelle decisioni tecniche implementative che di volta in volta sarebbero potute emergere.

Requests

Per la parte ricoprente il ruolo di “mediatore” tra le richieste utente e il rilancio delle stesse verso il sito di interesse, si è ricorsi alla libreria Requests la quale annovera

Massimiliano Dal Cero – Sistema server-side di acquisizione forense di contenuti Web asincroni

interessanti e utili caratteristiche che permettono una gestione flessibile ed elegante delle richieste HTTP, fornendo quindi una solida base per l'implementazione del proxy di mediazione.

Tra le caratteristiche sicuramente più utili allo scopo del progetto si menzionano:

• Keep-Alive & Connection Pooling • Sessions with Cookie Persistence • Elegant Key/Value Cookies • Multipart File Uploads • Streaming Downloads • Connection Timeouts • Chunked Requests

In Python esiste nativamente nelle sue librerie standard il modulo urllib2 che mette a disposizione quasi tutte le principali funzionalità HTTP, ma la sua interfaccia è molto frastagliata. Quel modulo è stato creato per tempi diversi - e un web diverso. Serve molto lavoro (addirittura anche l’overriding di metodi) per realizzare il più semplice dei task. Requests si fa carico di tutto il lavoro per implementare HTTP/1.1 su Python - rendendo immediata l’integrazione delle applicazioni con i web services. Non c’è bisogno di aggiungere manualmente query string agli URL, o di fare form-encoding dei dati inviati via POST. Il Keep-alive e il pooling delle connessioni HTTP sono completamente automatici, tutto ciò grazie a urllib3, che è contenuta dentro Requests e permette ad ogni richiesta HTTP inviata all’interno di una sessione di usare automaticamente la stessa connessione, consentendo in tal modo di non avere problemi di compatibilità con servizi particolarmente pignoli (come per esempio Facebook o Twitter che tentano in tutti i modi di identificare sessione mediate così da evitare, per motivi di sicurezza, connessioni indirette che passani attraverso connessioni aperte da altre applicazioni, in grado quindi di tracciare le azioni degli utenti oltre che prendere conoscenza delle credenziali).

Di fondamentale importanza è stato il pieno e flessibile supporto nella libreria Requests ai cookies, la cui specifica implementazione ha permesso di creare agevolmente un componente software che facesse da mediatore in grado di mantenere viva la sessione generata dall'utente dal suo browser senza che questa venisse persa nella triangolazione.

Puntamento delle risorse

Nel momento in cui la connessione transita dalla web application intermedia verso l'utente, risultava necessario poter intervenire anche sulle risorse puntate internamente alla pagina (css,script,immagini,video,etc). Questo aspetto, seppure non dettato da nessuna necessità forense, aveva il “solo” scopo di soddisfare precise necessità tecniche, come evitare che la fruizione dei contenuti potesse essere contrastata dal server originario qualora avesse avuto da “obiettare” nel vedere la sessione dell'utente provenire da differenti indirizzi IP.

Si rendeva quindi necessario effettuare le opportune analisi all'interno del codice sorgente proveniente dal server di origine, così da poterne apportare le necessarie modifiche e far puntare coerentemente tutte le risorse verso un unico indirizzo intermedio. Potendo sfruttare gli stessi controlli di ispezione del codice, si rendeva inoltre possibile intercettare e modificare opportunamente quegli script, introdotti intenzionalmente dal fornitore del contenuto, con l'intento di impiantare “scomodi” controlli idonei ad intercettare potenziali anomalie per applicare relative protezioni utili allo scopo.

Purtroppo però, seppure innocue, le analisi e relative modifiche al codice originale non proponevano un panorama ottimale ad un interlocutore non tecnico (come per esempio un giudice o un avvocato), per il quale la presenza della parola “modifica” risuonava funestamente come una potenziale minaccia all'originalità (ed integrità) del contenuto. Proprio questo aspetto si è rivelato essere un punto particolarmente delicato, che ha contribuito ad interrompere lo sviluppo della fase 1.

Seppure le modifiche fossero solamente strumentali a rendere possibile la fruizione del contenuto all'operatore, senza che queste apportassero alcun impatto finale all'acquisizione, ad orecchie non tecniche, la sola presenza di potenziali “modifiche” risultava sollevare perplessità inaccettabili da far ricadere un alone negativo su tutta la soluzione.

Acquisizione dei contenuti

Per meglio ottimizzare le risorse, la fase di acquisizione era stata pensata affinché non partisse immediatamente al momento stesso del click di “finalizzazione”. Si era notato infatti che certe acquisizioni risultavano essere così particolarmente esose di risorse da ricadere negativamente su tutta l'infrastruttura e di conseguenza su tutti gli utenti che stavano operando nel stesso momento sul medesimo asset. Si era quindi proceduto a calibrare le attività organizzando le singole acquisizioni in task “schedulati”. Ogni

Massimiliano Dal Cero – Sistema server-side di acquisizione forense di contenuti Web asincroni

acquisizione veniva messa in cosa al momento del click dell'utente sul pulsante “acquisisci” (o finalizza). Così facendo si rincorreva l'obiettivo di bilanciare il carico in base ad un predeterminato numero massimo di acquisizioni parallele definito in fase di configurazione.

Una volta superata la coda e iniziato il vero processo di acquisizione l'url di interesse veniva dato in pasto a PhantomJS (http://phantomjs.org/), un browser non visivo “Full web stack”. Seppure privo di rendering a video e con la sola possibilità di essere controllato da linea di comando o tramite scripting (javascript), sotto al cofano presenta un browser completo basato su Chromium con pieno supporto agli standard moderni del Web, potendo vantare un interprete javascript basato sul motore V8 di Google. Insieme all'url di interesse si passavano a PhantomJS anche tutte quelle informazioni salvate durante la prima fase di navigazione svolta dall'utente, contenenti tutti gli header HTTP (quindi comprensivi anche dei cookie) necessari a replicare la sessione al momento dell'avvenuto click sul pulsante “finalizza”. Quindi se l'utente aveva effettuato un login su un determinato servizio, tale sessione risultava disponibile ugualmente in fase di acquisizione, anche a fronte di controlli puntuali sull'indirizzo IP di provenienza da parte del servente. Essendo infatti che tutta la navigazione risultava mediata, anche l'IP di uscita sarebbe risultato mascherato, presentandosi quindi con il medesimo indirizzo. Discorso simile per lo user-agent, il quale essendo un header HTTP poteva essere tranquillamente clonato, rimanendo così invariato anche nella fase finale di acquisizione.

In conclusione, una volta giunti con PhantomJS configurato in maniera tale da replicare la sessione utente e l'url della risorsa da acquisire, si applicavano svariate strategie tali da permettere a PhantomJS di compiere quelle azioni necessarie ad ottenere il contenuto completo. Per fare ciò si erano studiate azioni “standard” da compiere ad ogni accesso ad un contenuto, così da avere una ragionevole certezza che le risorse in essa presenti fossero completamente caricate. Esempio di azione compiuta ad ogni accesso era lo “scrolling” della pagina fino a che nessun nuovo contenuto venisse aggiunto dinamicamente, oppure passare il “mouse virtuale” su ogni oggetto del DOM, così da permettere il caricamento di tutte quelle risorse secondarie caricate allo scatenarsi dell'evento “onmouseover”. Tutti comportamenti, seppure non privi di mancanze ed effetti collaterali difficili da arginare, utili allo scopo di determinare quelle risorse che, per ottimizzazione dello sviluppatore, non erano caricate insieme alla pagina.

Una volta svolte tutte le azioni di base necessarie, alcune delle quali studiate appositamente per pre-determinati domini noti possedere caratteristiche peculiari, si procedeva quindi al download di tutte le risorse caricate dalla pagina. Questo aspetto risultava essere possibile grazie al supporto nativo al “Network Monitoring” integrato in PhantomJS (http://phantomjs.org/network-monitoring.html) caratterizzato dalla possibilità di creare e associare specifiche callback richiamate al momento del caricamento della risorsa, potendo così generare al termine del caricamento un export in formato HAR (HTTP Archive) (http://www.softwareishard.com/blog/har-12-spec/) facilmente fruibile con HAR viewer (http://www.softwareishard.com/blog/har-viewer/) (Figura 14).

Massimiliano Dal Cero – Sistema server-side di acquisizione forense di contenuti Web asincroni