THP Wisec USH DigitalBullets TheHackersPlace network
The WIse SECurity
.italian
.english
Wisec Home SecSearch Progetti Documenti Pensieri in Sicurezza
 
Servizi alle Aziende News Cerca su Wisec
Google

Mod_Anti_Tamper

Scarica Anti Tamper
-------------------------
Anti Tamper Module for Apache 2.x

Version 0.1 Alpha Experimental.

Copyright (c) 2005 Stefano Di Paola <stefano.dipaola at wisec.it>

Released under GPL 2.0 
-------------------------

Cosa e' Mod AntiTamper (AT)

AntiTamper e' un modulo per Apache 2.x che puo' essere usato per prevenire
alcune forme di manipolazione delle url e dei cookie.

In particolare, i bot che sfruttano i motori di ricerca per la ricerca di
collegamenti a indirizzi web da attaccare saranno innocui.
E tecniche di attacco come l'Http Response Splitting o il session hijacking/fixation
saranno fortemente mitigate.
(Per un semplice esempio si legga examples/README.it)

E' importante fare notare che mod_anti_tamper non si propone come alternativa a 
 mod_security ma piuttosto come complemento.

Premessa

- Cos'e' l'HMac
L'HMac e' un algoritmo di validazione e di firma di un insieme di dati 
accoppiato con una password.
HMAC serve a controllare l'integrita' dei dati trasmessi.
http://www.faqs.org/rfcs/rfc2104.html

AT genera una password in maniera automatica e la salva in luogo 
sicuro (permessi di root 600).

Come Funziona

AT e' costituito da due principali componenti attive.
1. Un filtro per i collegamenti nelle pagine html.
2. Un filtro per i cookie.

Il Filtro per le Url

<Premessa>

  Al momento il filtering delle url avviene solamente se:
  1. nella url e' presente una query. (ad es. "indirizzo?query").

  2. il nome del server apache coincide col nome del server nella url
     (es. "http://www.wisec.it/testpage.php?id=2" sul server www.wisec.it)

  3. la url e' una url relativa al server.
     (es. "/testpage.php?id=2")

  4. Funziona solo su richeste GET.

</Premessa>


Il filtro per i collegamenti nelle pagine html prende la pagina generata da
apache e, tramite un parser Html basato su libxml e sul modulo mod_proxy_html,
riscrive i collegamenti aggiungendoci in fondo un firma con HMAC che valida 
in maniera univoca il link.
La generazione della firma HMac avviene sulla parte della uri comprendente il
path e la query.


Cioe' se ho un link: 
<a href="http://www.wisec.it/testpage.php?id=2">click here</a>

la firma validera' :

/testpage.php?id=2

e il link risultera' riscritto nel seguente modo:

<a href="http://www.wisec.it/testpage.php?id=2&_auth=1234567890">click here</a>

Dove "_auth" e' appunto la variabile che contiene il valore della firma (1234567890)
Conseguentemente il server accettera' la richiesta unicamente se la variabile 
"id" e' uguale a 2 e il percorso richiesto e' "/testpage.php"

Vediamo lo schema di funzionamento.

1. Un client fa una richiesta ad una pagina presente sul server Apache.
2. Apache genera una pagina html A.
3. AT legge A e la modifica aggiungendo ad ogni attributo html contenente un link, una firma 
   appositamente generata.
4. Il client riceve la pagina hmtl modificata.

A questo punto ci presentano due scenari, Scenario A e Scenario B:

Scenario A
5A. L'utente e' un normale visitatore e cliccando sui i link presenti nella pagina
    puo' continuare a navigare in maniera del tutto trasparente.
6A. Il modulo AT infatti verificando la firma contenuta nella richiesta con quella generata 
    al volo dai dati da' accesso alla pagina richiesta passando la richiesta ad Apache.

Scenario B
5B. L'utente e' un visistatore malizioso e prova a cambiare i valori delle variabili dei link
    presenti nella pagina appena ritornata dal server Apache e modificata con AT.
6B. Il modulo AT vede che il contenuto della richiesta genera un HMAC che non combacia
    con la firma generata precedentemente e redireziona il client su una pagina predefinita.
    Apache, cioe' non ottiene la richiesta originaria ma solo un comando di redirezione.

Il Filtro per i Cookie

Il modulo AT intercetta i Cookie da e verso Apache.
Se il cookie viene da Apache, allora AT firma il cookie con l'HMAC e lo manda al client;
Se il cookie viene dal client, allora AT genera la firma del cookie e la compara con l'HMAC
eventualmente presente (se non e' presente, il cookie e' automaticamente scartato) 
nel cookie inviato al server;

Ad esempio:

nell'header abbiamo:
Set-Cookie: PHPSESSID=111111

AT intercetta il cookie e ci agginge in coda:

Set-Cookie: PHPSESSID=111111:_auth=1234567890

A questo punto il client memorizza il cookie cosi' come gli e' stato passato:

PHPSESSID=111111:_auth=1234567890

Quando il client reinvia il cookie al server, AT prende il cookie e verifica la firma generata
al volo con quella presente. 

Ci troviamo di nuovo davanti a due scenari:

Scenario A
 Le firme coincidono. AT elimina la parte di firma e manda il cookie agli altri moduli.

Cookie: PHPSESSID=111111

Scenario B
 Le firme  non coincidono, AT  scarta tutto il cookie e non lo invia agli altri moduli. 

Nota Bene: Se un cookie non ha firma valida, AT non redireziona su nessuna pagina si limita a scartare
il cookie stesso e basta.


Un esempio di configurazione e' anti_tamper_http2.config, presente nella directory examples/ 

Le variabili di configurazione.

----------
ATHmacUrl
Sintassi: ATHmacUrl [On|Off]

Contesto: server config, virtual host, directory, .htaccess

Descrizione:
Imposta il filtering per le url

Default: On
----------


----------
ATHmacCookie

Sintassi: ATHmacCookie [On|Off]  

Contesto: server config, virtual host, directory, .htaccess

Descrizione:
Imposta il filtering per i cookie

Default: On
----------

----------
ATSetSecretPath

Sintassi: ATSetSecretPath <fullpath>

Contesto: server config

Descrizione:
Imposta il percorso assoluto dove leggere e scrivere (se mancante) il file 
contenente la password.

Default: /etc/httpd/conf/anti_tamper_secret
----------

----------
ATHmacUseIP

Sintassi: ATHmacUseIP [URL|COOKIE|BOTH|NONE]  

Contesto: server config, virtual host, directory, .htaccess

Descrizione:
Aggiunge l'IP del client nel calcolo dell'HMAC rispettivamente per url,cookie,entrambi or nessuno.

Default: NONE
----------

----------
ATSetHmacURLLibrary

Sintassi: ATSetHmacURLLibrary <full_path_solib> <exported_function> <authlen>

Contesto: server config

Descrizione:
Permette di importare funzioni ad hoc da una libreria esterna con percorso 
completo definibile in  <full_path_solib>.

La funzione deve avere la seguente sintassi:
char *exported_function ( request_rec *r , char *data,int data_len, const unsigned char *key,int key_len) 

<authlen> e' la lunghezza (in char) del valore della firma che la funzione ritorna.

Default: funzione hmac-sha1 interna al modulo.

----------

----------
ATSetHmacCookieLibrary

Contesto: server config

Sintassi: ATSetHmacCookieLibrary <full_path_solib> <exported_function> <authlen>

Descrizione:
Vedi ATSetHmacURLLibrary

Default: funzione hmac-sha1 interna al modulo.

----------

----------
ATRedirect_url

Sintassi: ATRedirect_url <url>  

Contesto: server config, virtual host, directory, .htaccess

Descrizione:
Pagina verso la quale AT deve redirezionare il client nell'eventualita' di una richiesta
non valida. (ritorna 302 found).
NB. Al momento non e' possibile aggiungere variabili alla url.
Cioe' la url deve essere una url statica tipo /index.php o error.html ma non
error.php?error=400.

Default: / (radice del server)
 
----------

----------
ATSetHMACPrefix

Sintassi: ATSetHMACPrefix <prefix>

Contesto: server config

Descrizione:
Nome della variabile che conterra' il valore della firma (caratteri permessi [A-Za-z0-9]).
Default: _auth
----------

----------
ATSetDontModifyPrefix
Sintassi: ATSetDontModifyPrefix <prefix>

Contesto: server config

Descrizione:
se non si desidera che AT aggiunga la firma ad un collegamento in una pagina,
aggiungendo in coda al link tale valore nella query, AT lo lascera' cosi' com'e'.
Attenzione: questo avviene solo nelle pagine in uscita.

Default: dontmodify
----------

Wisec - Un'Idea sviluppata e mantenuta da...

Wisec è scritto e mantenuto da Stefano Di Paola.

Wisec usa standard aperti, inclusi XHTML, PHP e CSS2.

Tutti i Diritti Riservati 2004
Tutti i messaggi e i metadati appartengono ai rispettivi autori.