Naufraghi nella Rete

10 principali problemi di sicurezza delle applicazioni web

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:

  1. Parametri non controllati
  2. Controlli di accesso insufficienti
  3. Gestione insicura degli account e delle sessioni
  4. Cross-Site scripting (XSS)
  5. Buffer Overflows
  6. Iniezione di comandi
  7. Problemi nella gestione degli errori
  8. Uso insicuro della crittografia
  9. Amministrazione remota insicura
  10. Mal configurazione del server web

Analizziamo in dettaglio ogni tipologia di errore.

Parametri non controllati

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:

  1. Accettare solo dati validi
  2. Rifiutare dati non validi
  3. Sanare i dati in arrivo

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.

Controlli di accesso insufficienti

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:

Uso insicuro degli Id
molti siti utilizzano degli Id per identificare in modo univoco un utente.
Se questi Id non sono gestiti in modo sicuro, un altro utente potrebbe "travestirsi" semplicemente rubando un Id valido. Una applicazione non può basare la sicurezza sulla segretezza dell'Id.
Navigazione forzata
una applicazione ha spesso dei punti di controllo, è importante che anche tutte le parti accessibili agli utenti autorizzati siano convalidate. A volte è possibile raggiungere una zona protetta semplicemente oltrepassando il punto di controllo, cioè conoscendo l'url (es. "miosito.com/securedir/securefile.sxw")
Path trasversale
Questo attacco coinvolge l'uso di indirizzi relativi (es. "../../somedir/somefile.txt") per accedere a risorse che normalmente non dovrebbero essere disponibili.
Permessi sui Files
Anche se molti server permettono l'uso di autenticazione e relativi permessi, è consigliabile impostare in modo corretto anche i permessi sul disco. Questo in modo da permettere la lettura solo in alcune directory e non in altre, indipendentemente dalla configurazione del web server.
Cache delle informazioni lato client
è importante impostare correttamente gli header HTTP e meta-tags in modo da non permettere al browser di tenere in cache dati importanti, quali ad esempio particolari permessi (ad es. amministratore) o informazioni private.

Gestione insicura degli account e delle sessioni

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.

Cambio di password
Ad un cambio di password all'utente dovrebbe essere sempre richiesto l'inserimento della vecchia e della nuova password, analogamente dovrebbe essere richiesta un'ulteriore conferma per il cambio di mail, altrimenti qualcuno potrebbe inserire il proprio indirizzo e poi richiedere la password "dimenticata" (vedi caso Passport...).
Sicurezza della password
un sistema di autenticazione dovrebbe imporre una lunghezza minima e dei criteri di complessità per le password scelte dagli utenti, questo rende più complesso il trovare una password tirando ad indovinare.
Salvataggio delle password
le password vanno conservate in forma codificata, preferibilmente in modo non reversibile. E' importante non mantenere nei log informazioni come username e password, i log potrebbero essere in uno spazio insicuro.
Proteggere il transito delle credenziali
l'unico modo sicuro per fare questo è l'uso di una codifica tipo SSL, infatti anche l'invio di chiavi codificate può permettere l'accesso anche se non si è in conoscenza della chiave originale.
Protezione dell'Id della sessione
anche in questo caso la soluzione SSL è la più sicura, comunque le linee guida suggeriscono: Id lunghi e complicati, non mettere l'Id nell'url per non permettere ad esempio di fare un Bookmark, fare in modo che l'Id cambi frequentemente durante una sessione, in modo da non permettere l'accesso a distanza di tempo.
Lista degli account
è sconsigliato permettere l'accesso alla lista degli account, la conoscenza dei login potrebbe favorire un attacco. Nel caso sia necessaria una lista è consigliabile l'uso di uno pseudonimo.
Cache del browser
i dati di autenticazione e di sessione dovrebbero essere inviati esclusivamente tramite POST e mai con il metodo GET che risdlta visibile nell'url.
Relazioni di fiducia
ogni componente che ha acceso ad un altro dovrebbe autenticarsi, non sono consigliabili autenticazioni implicite
Autenticazioni col substrato
l'autenticazione per accedere ad altri servizi dovrebbe essere sicura, possibilmente via SSL, e comunque la password per l'accesso dovrebbe essere conservata in un luogo molto difficile da raggiungere anche in caso di compromissione della sicurezza.

Cross-Site scripting (XSS)

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.

BufferOverflows

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.

Iniezione di comandi

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:

Problemi nella gestione degli errori

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.

Uso insicuro della crittografia

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:

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à.

Amministrazione remota insicura

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.

Mal configurazione del server web

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:

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:

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

Creative Commons License
This work is licensed under a Creative Commons License.
Commenti

marco -- 2005-05-09 01:17:54
grazie mille è proprio ciò che cercavo

nico -- 2007-02-14 11:05:50
grazie
Nota: I link esterni sono in corsivo e aprono una nuova pagina.


Naufraghi nella rete - PHP - Informatica - Linux - Blog - Appartamento a Firenze - Gruppo di discussione