Sito Web: http://www.owasp.org/
LA TOP TEN DELLE VULNERABILITÀ DELLE WEB APPLICATION
Ormai nello sviluppo delle Applicazioni Web il fattore sicurezza è diventato un requisito fondamentale, molti siti Internet se ne occupano e forniscono anche strumenti Open Source (gratis), uno di questi è il sito http://www.owasp.org/, Open Web Application Security Project.
Importante è la loro pubblicazione : "A Guide to Building Secure Web Applications", che è sempre aggiornata e che tiene traccia di tutti i sistemi di attacco e di difesa per le Web Applications.
http://www.cgisecurity.com/owasp/html/
Il fatto di essere Open Source, permette agli esperti del settore di contribuire attivamente con nuove proposte o nuovi problemi.
L'OWASP propone anche un documento più snello, una lista dei 10 principali problemi di sicurezza che affliggono le applicazioni web.
Le 10 vulnerabilità delle applicazioni web:
INPUT NON VALIDO
CONTROLLI DI ACCESSO INSUFFICIENTI
GESTIONE INSICURA DEGLI ACCOUNT E DELLE SESSIONI
CROSS-SITE SCRIPTING (XSS)
BUFFER OVERFLOWS
INIEZIONE DI COMANDI
GESTIONE DEGLI ERRORI SUPERFICIALE
USO INSICURO DELLA CRITTOGRAFIA
AMMINISTRAZIONE REMOTA INSICURA
CONFIGURAZIONE SUPERFICIALE DEL SERVER WEB
ANALIZZIAMO IN DETTAGLIO OGNI TIPOLOGIA DI VULNERABILITÀ.
INPUT NON VALIDO
Le applicazioni web utilizzano le informazioni presenti nella richiesta HTTP per decidere come rispondere.
Questo è il tipo di attacco visto a pagina 6, che potrebbe realizzarsi modificando una qualsiasi parte della richiesta HTTP, l'URL, la querystring, gli headers, i cookies o i campi dei form.
Per proteggersi è importante filtrare i dati in arrivo:
Accettare solo dati validi
Rifiutare dati non validi
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.
La terza opzione riguarda il rimpiazzamento dei dati non validi con dati validi.
Un'altra importante regola è quella di non affidarsi completamente ai controlli 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 è usato per dare l'accesso agli utenti solo ad alcune parti del sito e differenti a seconda dell'utente che si è identificato.
Non è semplice implementare una corretta procedura di autenticazione, infatti gli errori frequenti sono numerosi:
Uso insicuro degli Id
molti siti usano 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
Un'applicazione ha spesso delle zone di controllo d'accesso, è importante che anche tutte le parti accessibili agli utenti autorizzati siano convalidate.
A volte è possibile raggiungere una zona riservata semplicemente oltrepassando il punto di controllo, cioè conoscendo l'url, come detto nel capitolo ACCESSI VARI (es."www.sito.com/dirsicura/file.sxw")
Path trasversale
Questo attacco coinvolge l'uso di indirizzi relativi (es. "../../directory/file.txt") per accedere a risorse che normalmente non dovrebbero essere disponibili.
Permessi sui Files
È sempre una buona pratica impostare i permessi sul disco, onde evitare la lettura delle directory (directory listening), 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
Le applicazioni web possono gestire gli account e le sessioni e questo coinvolge una molti 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.
Osserviamo alcuni dei punti critici a cui dedicare maggiore attenzione.
CAMBIO DI PASSWORD
Ogni volta che un utente prova a cambiare una password, l'applicazione dovrebbe richiedere 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".
SICUREZZA DELLA PASSWORD
Un sistema di autenticazione dovrebbe imporre una lunghezza minima (meglio 8 caratteri) e dei criteri di complessità (numeri e lettere) per le password scelte dagli utenti, questo rende più complesso il trovare una password tirando ad indovinare.
SALVATAGGIO DELLE PASSWORD
Nella conservazione delle password vanno evitati i fogliettini, le rubriche del telefonino, ed i file di testo o accessibili a tutti,sarebbe meglio criptarle in un file.
E' importante non mantenere nei log informazioni come username e password, i log potrebbero essere in uno spazio insicuro.
PROTEGGERE IL TRANSITO DELLE CREDENZIALI
È meglio usare il protocollo SSL (Secure Socket Layer) per trasmettere le informazioni (password, ecc.), poiché tramite HTTPS (HyperText Transport Protocol Secure) i dati vengono criptati.
PROTEZIONE DELL'ID DELLA SESSIONE
Gli ID sessione sarebbe meglio se fossero essere trasmessi in SSL, 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
Non è buona pratica permettere l'accesso alla lista degli account, la conoscenza dei login potrebbe facilitare 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 risulta visibile nell'URL.
RELAZIONI DI FIDUCIA
Ogni componente che ha acceso ad un altro dovrebbe autenticarsi, non sono consigliabili autenticazioni implicite o memorizzate.
CROSS-SITE SCRIPTING (XSS)
Come abbiamo detto il cross-site scripting si verifica quando una applicazione è usata per inviare codice maligno in esecuzione sul un browser.
Questo può succedere in modo diretto o riflesso, un esempio potrebbe essere l'inserimento di codice javascript cattivo all'interno di un messaggio di un forum, oppure sono eventuali vittime di XSS tutte le pagine che restituiscono direttamente una variabile ricevuta dall'utente.
I problemi di sicurezza legati al XSS sono molto assidui e difficili da identificare, tuttavia è 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 difendersi bisogna verificare che nessuna variabile venga restituita al browser senza essere stata controllata, un filtro generico che riduce di molto i rischi è quello di rimpiazzare tutti i caratteri sensibili, tipo (,),<,>,#,& con le loro equivalenti entities.
BUFFER OVERFLOWS
Un buffer overflow danneggia lo stack di esecuzione (ossia lo spazio di memoria) di una applicazione e autorizza l'esecuzione di codice arbitrario sulla macchina vittima con i privilegi dell'applicazione.
Anche se la tecnica è piuttosto complicata esistono una pletora di applicazioni sensibili a questi attacchi.
L'uso di linguaggi interpretati (ASP,PHP, Python, Pike, Java, Perl, Ruby, ...) riduce di molto il problema in quanto un errore per mettere a repentaglio la sicurezza dovrebbe andare a provocare un buffer overflow nella VM (Virtual Machine).
I provvedimenti sono vari, dal tenere regolarmente aggiornato il sistema ed i vari prodotti utilizzati, al controllare ogni input per lunghezza e formato.
INIEZIONE DI COMANDI
Anche questo lo abbiamo visto in precedenza e ricordiamo che attacchi di questo tipo agiscono inserendo codice all'interno dei parametri di un web form e possono provocare i più diversi problemi.
Qualsiasi applicazione scritta in linguaggi interpretati ed 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 consigli 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 nei DBMS (Data Base Management System).
- Controllare che i privilegi dell'applicazione siano i minimi possibili.
Controllare i codici di ritorno di possibili chiamate a programmi esterni, al minimo per conoscere se l'esecuzione è andata a buon fine, ma anche per non essere ignari di un eventuale attacco in atto.
GESTIONE DEGLI ERRORI SUPERFICIALE
Una gestione corretta degli errori (quindi non superficiale), significa non rendere, un errore del software (anche causato volontariamente), fonte di informazioni sulla struttura interna dell'applicazione ad eventuali attacchi.
Anche il semplice File Not Found piuttosto di un Access Denied può essere un'informazione utile per un hacker, per non parlare degli stack trace
Esempio di stack trace error:
Access to the path "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\root\c0c02afa\19017b74" is denied.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.UnauthorizedAccessException: Access to the path "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\root\c0c02afa\19017b74" is denied.
ASP.NET is not authorized to access the requested resource. Consider granting access rights to the resource to the ASP.NET request identity. ASP.NET has a base process identity (typically {MACHINE}\ASPNET on IIS 5 or Network Service on IIS 6) that is used if the application is not impersonating. If the application is impersonating via <identity impersonate="true"/>, the identity will be the anonymous user (typically IUSR_MACHINENAME) or the authenticated request user.
To grant ASP.NET write access to a file, right-click the file in Explorer, choose "Properties" and select the Security tab. Click "Add" to add the appropriate user or group. Highlight the ASP.NET account, and check the boxes for the desired access.
dove vengono mostrate parte di codice.
Per porre rimedio a questi problemi bisogna effettuare 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
Spesso problemi di questo tipo possono sorgere ogni qual volta un'applicazione ha bisogno di conservare informazioni sensibili.
I punti basilari 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 suggerimenti per eludere questi errori sono, minimizzare l'uso della crittografia e conservare solo le informazioni davvero necessarie, adoperare algoritmi di hashing irreversibili per controllare le password ed appoggiarsi a librerie di buona qualità.
AMMINISTRAZIONE REMOTA INSICURA
Come abbiamo già detto precedentemente l'amministrazione remota di un server, può essere fonte di rischio se fatta male.
Un accesso insicuro all'interfaccia di amministrazione potrebbe permettere ad un intruso l'ingresso e la modifica di qualsiasi informazione.
Per rimediare 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.
CONFIGURAZIONE SUPERFICIALE DEL SERVER WEB
La configurazione del web server e dell'application server giocano un ruolo fondamentale nella sicurezza di un'applicazione.
A volte amministratore di sistema e sviluppatore sono persone diverse che non si interfacciano tra loro, 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, ci vuole molto studio ed accortezza, ma è importante essere sempre aggiornati sui problemi di sicurezza ed installare prontamente le versioni aggiornate dei programmi bucati (patch).
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
