x

Top Ten Vulnerabilità

Aspetti legali (D.lgs 196/03 e BS 7799)
indietro
avanti

SICUREZZA INFORMATICA SUL WEB
by Nanni Bassetti

 

 

Sito Web:  http://www.owasp.org/

x

 

 

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.

 

x
x

 

 

 


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

uggeriscono: 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.

x

 

 

 


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