Il blog sull'informatica

Consentire agli utenti della propria LAN l'accesso ai siti Web mediante Proxy è ormai una prassi. Analizzare i relativi file di log, però, risulta essere un'operazione piuttosto tediosa, indi per cui è molto conveniente utilizzare dei software in grado di generare i report degli accessi in modo automatico.

Se il proxy che avete tirato su è Squid e non implementate meccanismi di autentica (ad esempio NTLM), potete usare Calamaris come generatore di report.

L'installazione e la configurazione di tale applicativo è piuttosto semplice. Infatti, per installarlo basta digitare:

nightfly@nightbox:~$ sudo apt-get install calamaris

Ad installazione completata possiamo passare alla configurazione. Per prima cosa creiamo la directory calamaris in /var/www:

nightfly@nightbox:~$ sudo mkdir -p /var/www/calamaris

e le sottodirectory daily, weekly e monthly, in cui andranno salvati rispettivamente i report giornalieri, settimanali e mensili:

nightfly@nightbox:~$ sudo mkdir -p /var/www/calamaris/daily

nightfly@nightbox:~$ sudo mkdir -p /var/www/calamaris/weekly

nightfly@nightbox:~$ sudo mkdir -p /var/www/calamaris/monthly

assegniamo i giusti permessi alle directory appena create:

nightfly@nightbox:~$ cd /var/www

nightfly@nightbox:/var/www$ sudo chown nomeutente:nomeutente -R calamaris

A questo punto possiamo creare il primo report, digitando:

nightfly@nightbox:/var/www$ sudo calamaris -a -F html /var/log/squid/access.log > /var/www/calamaris/index.html

Il report sarà visualizzabile mediante browser alla seguente URL:

http://vostroippubblico/calamaris

Per consentire solo ad uno specifico utente la visualizzazione del report occorre creare un file .htaccess recante le seguenti direttive:

AuthName "Sezione riservata Calamaris"
AuthType Basic
AuthUserFile /etc/apache2/passwd
Require user <nome utente>

ovviamente il nome utente deve essere presente nel file /etc/apache2/passwd (in cui viene fatta l'associazione tra l'utente stesso ed il digest della sua password)

Infine, modifichiamo il file /etc/apache2/apache2.conf in questo modo:

<Directory /var/www/calamaris>
AllowOverride AuthConfig
</Directory>

Salviamo il tutto e riavviamo apache:

nightfly@nightbox:~$ sudo service apache2 restart

Per ricevere i report direttamente via email (oltre ad ottenere il loro salvataggio nelle dir precedentemente create), possiamo modificare come segue il file cron.conf posizionato in /etc/calamaris:

daily:vostro.indirizzo@email.it:/var/www/calamaris/daily/index.html:both:'Squid giornaliero'
weekly:vostro.indirizzo@email.it:/var/www/calamaris/weekly/index.html:both:'Squid settimanale'
monthly:vostro.indirizzo@email.it:/var/www/calamaris/monthly/index.html:both:'Squid mensile'

Inoltre, sarà necessario abilitare la cache di squid (se non l'avete ancora fatto), decommentando la direttiva cache_dir presente nel file /etc/squid/squid.conf.

Done, enjoy!

In questo post ho descritto il concetto su cui si basa l'attacco CSRF, mentre in quest'altro post ho provato ad elencare alcuni rimedi da utilizzare per mitigare tale tipologia di attacco.

Adesso vedremo quali sono i diversi tipi di attacco CSRF.

Login CSRF

L'attaccante invia una URL trappola alla vittima, contenente le proprie credenziali di accesso sul sito vulnerabile. In questo modo, appena la vittima effettuerà il login e se il sito lo consente, l'attaccante riuscirà a tenere traccia dei suoi comportamenti (sezioni visitate, link cliccati et similia), semplicemente accedendo al proprio profilo in un secondo momento (vedi YouTube).

Stored CSRF

Il sito vulnerabile consente l'inserimento di codice lato client (Javascript e/o HTML) da parte degli utenti autenticati. Questa in realtà è una vulnerabilità agli attacchi XSS che però può essere utilizzata per creare delle richieste CSRF. Supponiamo che l'attaccante utilizzi i campi di input di un form per iniettare del codice HTML contenente un ulteriore form caratterizzato da diversi campi hidden. Tali campi verranno popolati ad-hoc in modo da creare le giuste variabili da inviare al server tramite HTTP POST.

Ad esempio si potrebbe avere un form del tipo:

<form name="csrf" id="csrf" method="post" action="pagina.php">
<input type="hidden" name="nome" value="Mario" />
<input type="hidden" name="cognome" value="Rossi" />
<input type="hidden" name="telefono" value="06676785" />
</form>

e la seguente immagine "trappola":

<img src="images/immagine.jpg" alt="immagine" onclick="javascript:document.forms['csrf'].submit()" />

L'utente vittima, cliccando sull'immagine, invierebbe i dati al server, i quali verrebbero così processati (si pensi alla classica transazione finanziaria).

Tale tipologia di attacco CSRF è quella che ha un ottimo margine di riuscita, in quanto l'attaccante è certo che l'utente vittima sia effettivamente loggato al sito vulnerabile (altrimenti non potrebbe accedere al form precedentemente forgiato).

Reflected CSRF

L'attacco ha come sorgente "terze parti", ad esempio siti esterni, applicazioni di instant messaging, client di posta et similia. I margini di riuscita sono relativamente bassi, in quanto l'attaccante non può sapere a priori se la vittima è loggata o meno sul sito vulnerabile nel momento in cui viene sferrato l'attacco vero e proprio.

Le metodologie di attacco sono quelle classiche, ovvero creazione di una URL "trappola" oppure l'uso di un form creato ad hoc.

Il form che l'attaccante potrebbe creare è simile a quello visto in precedenza, eccezion fatta per l'attributo action:

<form name="csrf" id="csrf" method="post" action="http://www.sitovulnerabile.it/pagina.php">
<input type="hidden" name="nome" value="Mario" />
<input type="hidden" name="cognome" value="Rossi" />
<input type="hidden" name="telefono" value="06676785" />
</form>

<img src="images/immagine.jpg" alt="immagine" onclick="javascript:document.forms['csrf'].submit()" />

Dai miei esempi si evince come l'HTTP POST offra dei margini di sicurezza migliori rispetto al GET, ma è comunque soggetto ad attacchi CSRF. Per questo, è opportuno utilizzare il token anche se il vostro sito accetta solo dati inviati mediante POST.

Inoltre, nell'ambito degli stored CSRF, se il sito non presenta vulnerabilità XSS (grazie a politiche di input sanitization), il metodo POST associato al controllo del referer HTTP, rappresenta una buona contromisura al CSRF, anche se non ottimale.

Proprio per questo motivo, consiglio di utilizzare i token sempre e comunque.

A presto.

Tutti gli addetti ai lavori sanno (o almeno dovrebbero sapere) che nell'ambito della sicurezza Web occorre prestare particolare attenzione ai dati trasmessi al server mediante gli appositi form HTML.

Tale operazione si rende indispensabile poichè un utente malevolo potrebbe "postare" delle stringhe "ad hoc" per "iniettare" del codice SQL arbitrario (SQL injection) oppure inserire all'interno della pagina del codice HTML (o javascript) che provoca il reindirizzamento su un sito infetto (iframe, redirect et similia, ovvero tutto ciò che riguarda gli attacchi XSS).

Per questo motivo ho deciso di postare qualche riga di codice PHP che consente di filtrare in modo rapido ed efficace i dati immessi dagli utenti.

In particolare, vengono svolti due controlli: il primo si occupa dell'individuazione (e la successiva rimozione) dei caratteri speciali di MySQL (apice singolo, apice doppio, backslash, cancelletto, ecc.), mentre il secondo verifica che non vi siano dei tag HTML all'interno delle stringhe immesse nei campi di input.

Ecco il codice:

if(isset($_POST['username']) && $_POST['username'] != '')
{
$username = mysqli_real_escape_string($mysqli,strip_tags($_POST['username']));
}

else
{
        $errore = 'Devi inserire lo username';
 }

Come potete notare, il campo su cui è stato implementato il filtro è quello relativo allo username. Per prima cosa viene verificato che la variabile $_POST['username'] sia settata e non sia vuota.

Se tale controllo va a buon fine, tramite la funzione strip_tags() viene rimosso l'eventuale codice HTML e successivamente, mediante mysqli_real_escape_string() vengono filtrati i caratteri speciali relativi a MySQL.

Ovviamente, attraverso tale meccanismo non darete agli utenti la possibilità di scegliere username del tipo:

<username>

o ancora:

username#

ma si sa, in questi casi bisogna certamente scendere a compromessi e capire dove sta il male minore.

A presto.