Rumore nei dati

Abbiamo discusso le informazioni relative alla navigazione che vogliamo utilizzare per modellare il comportamento degli utenti. La descrizione fatta finora non tiene per`o conto del pesante rumore che `e caratteristica frequente in questi log. Infatti una grossa porzione delle richieste che vengono effettuate al web server sono relative ad immagini o ad altre risorse statiche (file JavaScript o Flash, fogli di stile CSS, documenti XML, . . . ). Tener conto di queste risorse come parte integrante del modello di navigazione di un utente avrebbe conseguenze deleterie sia sulla qualit`a del modello sia sulla dimensione e quindi gestibilit`a dello stesso.

5.1 Due principali sotto-domini

In primo luogo le risorse statiche di un sito web sono in numero molto elevato; ci`o causa un’esplosione delle richieste da analizzare senza per altro migliorare la capacit`a del sistema di catturare la semantica della navigazione di un utente, soprattutto all’in-terno di una tipologia di sito Internet, quale `e un portale di home banking, in cui le risorse statiche vengono raramente richieste direttamente dall’utente ma quasi esclu-sivamente richiamate indirettamente dal browser come risorse necessarie alla corretta visualizzazione della pagina selezionata (ad esempio le immagini di loghi aziendali o i fogli di stile per il rendering dei vari elementi grafici). Data poi la stretta correlazione tra file statici e layout di un sito web si ha che anteporre un filtro all’analisi rende pi`u robusto il sistema in caso di cambiamenti grafici dell’interfaccia che non impattano sulla struttura dei collegamenti tra le pagine. Un altro importante problema conse-gue dal fatto che spesso tali risorse sono conservate nella cache (cfr. Sezione 7.3.1.2) del browser dell’utente (o di un caching proxy server qualora sia presente) rendendo la mancanza della chiamata ad una risorsa statica non definibile chiaramente come evento sospetto o meno e di fatto abbassando l’affidabilit`a di un qualsiasi modello che tenesse in considerazione anche di queste ultime.

Un’altra fonte di rumore `e rappresentata dal formato degli indirizzi web nel proto-collo HTTP, le cosiddette URL. Questo formato `e descritto dalla seguente grammatica: protocollo://<username:password@>nomehost<:porta></percorso><?querystring>

Per quanto riguarda la stragrande maggioranza delle applicazioni Web le compo-nenti username, password e porta non compaiono. Sono intuibili le ragioni di sicurezza nel caso delle prime due mentre per quanto riguarda il numero della porta di collega-mento questo non viene esplicitato qualora venga utilizzato il valore predefinito (porta 80 per HTTP, 443 per HTTPS) ma anche nel caso in cui questo non si verificasse, per precisa scelta degli sviluppatori, il dato rimarrebbe chiaramente invariato in caso di manipolazione delle richieste da parte di un frodatore. Lo stesso argomento vale per la porzione iniziale dell’URL che specifica il protocollo utilizzato dalla richiesta. Possiamo dunque implementare un primo filtro e ridurre il formato iniziale a quello seguente: nomehost</percorso><?querystring>

La componente querystring rappresenta tutta quella serie di parametri che vengo-no forniti dall’utente. Questa lista di parametri pu`o essere anche piuttosto lunga e

5. ANALISI DEI DATI

contenere sia informazioni circa la semantica della pagina richiamata sia parametri ag-giuntivi utilizzati dall’applicazione lato server per determinarne la “forma” (ad esempio il linguaggio da utilizzare o la quantit`a di movimenti del conto corrente da visualizza-re). La querystring `e il meccanismo principale attraverso il quale le applicazioni web dinamiche possono reagire ai diversi input dell’utente permettendo di implementare logiche di funzionamento basate sul valore dei parametri forniti. Proprio per questo motivo moltissimi attacchi a queste applicazioni si basano sulla manipolazione di tali parametri per indurre l’applicazione ad operare in maniera non prevista, basti pensare agli attacchi SQL Injection o reflected XSS. Ne deriva quindi che gli IDS progettati per garantire la sicurezza dei server web, specialmente quelli di tipo misuse detection, dispongono di numerose signature che analizzano la presenza di determinati pattern all’interno della querystring. Analogamente anche molti sistemi di anomaly detection sviluppati per monitorare il traffico HTTP [80; 81] concentrano l’attenzione su que-sta porzione dell’URL in questo caso per`o cercando di modellare, attraverso diverse techiche, l’insieme di valori legittimamente attesi.

`

E necessario dunque tenere conto di questi parametri? La risposta purtroppo non `

e univoca e dipende da alcune scelte di sviluppo dell’applicazione stessa che vogliamo monitorare. Se il ruolo di questi parametri determina la semantica della richiesta allora `

e quanto meno necessario effettuare una valutazione dell’applicazione, in collaborazione con gli sviluppatori, per individuare le varie casistiche e produrre una lista delle coppie pagina/parametro che consenta di filtrare solo le informazioni necessarie per descrivere il comportamento dell’utente. Consideriamo a titolo di esempio una sessione composta dalle due seguenti URL:

http://www.miabanca.it/azione.do?pagina=Movimenti&quantita=10 http://www.miabanca.it/azione.do?pagina=Saldo

Eliminare da questa applicazione l’intera querystring a scopo di semplificare il mo-nitoraggio comporterebbe una grave perdita di informazione e porterebbe a considerare equivalenti le due richieste. In questo caso infatti la semantica `e totalmente catturata dal parametro “pagina” il cui contenuto dovrebbe essere considerato; al contrario il parametro “quantita” fornisce un’informazione trascurabile.

Abbiamo finora considerato solamente parametri inviati attraverso la querystring. Questo tipo di “passaggio” di parametri avviene frequentemente nel caso di richieste

5.1 Due principali sotto-domini

che utilizzano il metodo HTTP GET. Nel caso per`o in cui parametri significativi ven-gano spediti anche facendo uso del metodo HTTP POST sar`a necessario provvedere la registrazione di questi specifici parametri nei file di log dato che non vengono infatti memorizzati in maniera predefinita o, se questo dovesse risultare complicato e richie-dere una configurazione del web server troppo elaborata, preverichie-dere la memorizzazione dell’intero contenuto delle richieste POST, con tutte le problematiche annesse dovute all’incremento delle dimensioni dei dati da archiviare.

L’applicazione monitorata dal nostro sistema non ha richiesto interventi di questo tipo, essendo la semantica di ogni singola richiesta ben definita dal solo nome della pagi-na acceduta, contenuto nella componente percorso di ogni URL. Ci rendiamo per`o conto che nello sviluppare un sistema pi`u generale sia preferibile posizionare la componente di analisi e scomposizione delle richieste di modo che possa direttamente intercettare tutto il traffico HTTP verso il web server senza richiedere un’analisi a posteriori dei file di log. Questo tipo di implementazione potrebbe anche meglio soddisfare quei requisiti di esecuzione real-time che sono sempre pi`u desiderabili per i sistemi antifrode e avere un impatto nullo relativamente alla configurazione del web server che non dovrebbe mai essere modificata o aggiornata. In Figura 5.1 `e possibile osservare una rappresentazione schematica proprio di questa architettura che sfrutta una funzionalit`a nota come port mirroring, di cui sono dotati gli switch di livello enterprise, per inoltrare una copia dei pacchetti smistati dallo switch stesso verso una porta opportunatamente dedicata, allo scopo di monitoraggio.