Durante lo sviluppo di applicazioni per il web la sicurezza è una caratteristica prioritaria, però spesso le soluzioni trovate non sono "sicure" come speravamo.
Per questo esistono numerose risorse per gli sviluppatori riguardo a questo tema, una di queste è il sito www.owasp.org, Open Web Application Security Project.
Tra gli intenti di questo gruppo di lavoro risalta la volontà di produrre e mantenere aggiornata una analisi dei principali problemi di sicurezza delle applicazioni web ed una serie di soluzioni per evitarli: "A Guide to Building Secure Web Applications".
Il vantaggio di questa pubblicazione è di essere Open Source, questo permette agli esperti del settore di contribuire attivamente con nuove proposte o nuovi problemi, al momento infatti è in fase di ultimazione una nuova versione ampliata del documento.
L'OWASP propone anche un documento più snello, una lista dei 10 principali problemi di sicurezza che affliggono le applicazioni web. Disponibile gratuitamente e periodicamente aggiornato è un importante punto di partenza per verificare la sicurezza di un'applicazione.
Le 10 piaghe delle applicazioni web:
Analizziamo in dettaglio ogni tipologia di errore.
Le applicazioni usano le informazioni presenti nella richiesta HTTP per decidere come rispondere. Una attacco potrebbe avvenire modificando una qualsiasi parte della richiesta HTTP, l'url, la querystring, gli headers, i cookies o i campi dei form.
Per ovviare a questo tipo di attacchi è importante filtrare i dati in arrivo, ci sono tre politiche principali per il filtraggio:
La prima opzione è la più sicura, imposizioni di lunghezza e formato limitano molto le possibili manomissioni, al contrario un filtro che elimina alcuni caratteri speciali potrebbe essere facilmente oltrepassato con una qualche codifica.
Un altro importante regola è quella di non fidarsi mai di un controllo di validità lato client, questi controlli sono utili da punto di vista delle performances e dell'usabilità, ma sono molto semplici da evitare.
Il controllo degli accessi è una funzionalità di un'applicazione web che permette agli utenti l'accesso alcune risorse ma non ad altre.
Non è semplice implementare una corretta procedura di autenticazione, infatti gli errori frequenti sono numerosi:
"miosito.com/securedir/securefile.sxw"
)"../../somedir/somefile.txt"
) per accedere a
risorse che normalmente non dovrebbero essere disponibili.La gestione degli account e delle sessioni coinvolge una vasta gamma di processi, alcuni di basso livello, tipo l'autenticazione, la gestione degli utenti, la gestione delle sessioni attive, altri più evoluti, come le funzioni per il cambio di password e il recupero di password perdute.
Le applicazioni web devono usare le sessioni per tenere traccia della richieste di ogni utente, il protocollo HTTP non offre questa funzionalità e quindi ogni applicazione deve implementarla in qualche modo.
Molti prodotti offrono un sistema integrato di gestione delle sessioni, generalmente progettato con attenzione alla sicurezza. Vediamo alcuni dei punti critici a cui dedicare maggiore attenzione.
Il cross-site scripting si verifica quando una applicazione può essere usata per inviare codice maligno in esecuzione sul un browser. Questo può avvenire in modo diretto o riflesso, un esempio potrebbe essere l'inserimento di codice javascript maligno all'interno di un messaggio di un forum, oppure sono potenziali vittime di XSS tutte le pagine che restituiscono direttamente una variabile ricevuta dall'utente.
I problemi di sicurezza legati al XSS sono molto frequenti e difficili da identificare, però è importante eliminarli, perché il browser in caso di XSS concede allo script maligno i permessi del sito che lo ospita e questo potrebbe causare perdita di sicurezza e compromissione di dati sensibili.
Per proteggersi bisogna appurare che nessuna variabile venga restituita al browser senza essere stata controllata, un filtro generico che riduce di molto i rischi è quello di sostituire tutti i caratteri sensibili, tipo (,),<,>,#,& con le loro equivalenti entities.
Un buffer overflow compromette lo stack di esecuzione di una applicazione e permette l'esecuzione di codice arbitrario sulla macchina vittima con i privilegi dell'applicazione. Anche se la tecnica è piuttosto complessa esistono una vasta gamma di applicazioni sensibili a questi attacchi.
L'uso di linguaggi interpretati (PHP, Python, Java, Pike, Perl, Ruby, ...) riduce di molto il problema in quanto un errore per compromettere la sicurezza dovrebbe andare a provocare un buffer overflow nella VM.
I rimedi sono vari, dal tenere costantemente aggiornato il sistema ed i vari prodotti usati, al controllare ogni input per lunghezza e formato.
Gli attacchi di questo tipo agiscono inserendo codice all'interno dei parametri e possono causare i più vari problemi.
Ogni applicazione scritta in linguaggi interpretati, ogni applicazione che faccia uso di chiamate al sistema per l'esecuzione di programmi esterni, può essere soggetta a questo tipo di attacco.
Oltre ai linguaggi di programmazione le iniezioni possono anche essere di codice SQL, questo compromette ovviamente la sicurezza dei dati.
I suggerimenti per ovviare a questo tipo di attacchi sono:
Usare librerie invece di chiamate a sistema per l'esecuzione di compiti specifici.
Controllare la validità di ogni input e valutare l'uso di stored procedures.
Controllare che i privilegi dell'applicazione siano i minimi possibili.
Controllare i codici di ritorno di eventuali chiamate a programmi esterni, come minimo per sapere se l'esecuzione è andata a buon fine, ma anche per non essere ignari di un eventuale attacco in atto.
Una gestione corretta degli errori non espone informazioni sulla struttura interna dell'applicazione ad eventuali attacchi.
Anche in semplice FileNotFound invece di un AccessDenied può essere un'informazione utile per un cracker, per non parlare degli stack trace dove vengono esposte parte di codice.
Per ovviare a questi problemi è necessaria una revisione del codice, gli errori devono essere gestiti in modo uniforme dall'applicazione e devono restituire messaggi chiari per l'utente e non compromettenti per lo sviluppatore.
Problemi di questo tipo possono sorgere ogni qual volta un'applicazione ha bisogno di conservare informazioni sensibili. I punti principali in cui possono nascondersi degli errori sono:
salvataggio insicuro di chiavi, certificati o password
conservare in modo improprio dati segreti in memoria
randomizzazione di bassa qualità
algoritmi di bassa qualità
mancata codifica dei dati veramente critici
tentativo di inventare nuovi algoritmi di codifica
errori nella procedura di recupero password perse
I consigli per evitare questi errori sono, minimizzare l'uso della crittografia e conservare solo le informazioni veramente necessarie, usare algoritmi di hashing irreversibili per controllare le password ed appoggiarsi a librerie di buona qualità.
Molti application server includono delle funzioni di amministrazione remota, spesso però a queste parti dell'applicazione non viene dedicata la particolare attenzione che necessiterebbero.
Un accesso insicuro all'interfaccia di amministrazione potrebbe permettere ad un intruso l'ingresso e la modifica di qualsiasi informazione.
Per ovviare a questi problemi è bene valutare l'effettiva necessità di una amministrazione remota e, nel caso sia necessaria, provvedere a costituire un'infrastruttura sicura, ad esempio usando SSL per tutta la durata della sessione, scelta non onerosa visto il numero limitato degli amministratori.
Altre opzioni potrebbero essere quelle di mantenere separate le interfacce di utente ed amministratore, in modo da rendere difficile una escalation di privilegi, oppure di porre l'interfaccia di amministrazione su un altro indirizzo o su una porta strana. Queste però non sono vere soluzioni per la sicurezza, sono solo trucchi per abbassare un po' la probabilità di un attacco.
La configurazione del web server e dell'application server giocano un ruolo fondamentale nella sicurezza di un'applicazione. Spesso amministratore di sistema e sviluppatore lavorano in due squadre diverse su due piani separati, i problemi connessi alla sicurezza spesso si trovano proprio in questo spazio intermedio.
Sono molti i problemi di configurazione che possono esserci in un sito, tra questi:
programmi sul server non regolarmente aggiornati con patch di sicurezza
server che permettono la lista delle directory o attacchi tipo path trasversale
esempi o prove abbandonate sul server o backup non necessari visibili dall'esterno
permessi errati su files e directory
funzioni di debug amministrative accessibili
messaggi di errore troppo informativi
configurazione errata dei certificati SSL o della crittografia in generale
uso di certificati auto-firmati o di default
Rendere più sicuro un server non è cosa semplice, è importante essere sempre aggiornati sui problemi di sicurezza ed installare prontamente le versioni aggiornate dei programmi bucati. In questo per fortuna alcune distribuzioni come la Debian ci vengono incontro, fornendo funzioni di aggiornamento automatico e configurazioni di default discretamente sicure.
Le linee guida generali sono comunque:
configurare con attenzione ogni applicazione
rimuovere tutti i servizi non necessari
configurare con attenzione ruoli, permessi ed accounts
controllare periodicamente i log ed impostare degli allarmi
Questa è solo una rapida panoramica dei problemi di sicurezza che potrebbero nascondersi in una applicazione web, per un'analisi più approfondita vi consiglio di consultare il sito da cui ho attinto: www.owasp.org, Open Web Application Security Project.
Ultima modifica 20/05/2003
Per ogni suggerimento/errore contattatemi liberamente: Matteo Bertini
Commenti |
marco -- 2005-05-09 01:17:54 grazie mille è proprio ciò che cercavo |
nico -- 2007-02-14 11:05:50 grazie |
This work is licensed under a Creative Commons License.