Articolo Pubblicazioni

OWASP Top 10 (2003): i dieci problemi di sicurezza più critici delle applicazioni web

di · Pubblicato il 10 marzo 2003

Abstract

All’inizio del 2003 l’Open Web Application Security Project ha pubblicato la prima edizione della Top Ten, un elenco dei problemi di sicurezza più critici delle applicazioni web. L’articolo presenta il progetto, descrive le dieci categorie con esempi concreti e contromisure e suggerisce come usare l’elenco nello sviluppo, nei test e nei contratti con i fornitori.

Vincenzo Calabrò | OWASP Top 10 (2003): i dieci problemi di sicurezza più critici delle applicazioni web
 

Il progetto OWASP

L’Open Web Application Security Project è una comunità aperta nata nel 2001 per migliorare la sicurezza del software applicativo. Produce documenti e strumenti gratuiti, tra cui una guida allo sviluppo di applicazioni web sicure. La Top Ten, pubblicata in questi mesi, è un documento breve pensato per chi deve decidere dove concentrare gli sforzi, cioè sviluppatori, responsabili di progetto e committenti.
Il presupposto è semplice. Firewall e cifratura SSL proteggono la rete e il canale, ma le richieste HTTP arrivano comunque all’applicazione, che le elabora con il proprio codice. Se quel codice contiene errori, l’attaccante li sfrutta passando attraverso tutte le difese perimetrali.

Le dieci categorie

La prima edizione elenca questi problemi:
  1. input non validato, cioè informazioni ricevute dal browser e usate senza controlli;
  2. controllo degli accessi difettoso, che permette agli utenti di vedere o modificare dati di altri o di usare funzioni riservate;
  3. autenticazione e gestione delle sessioni difettose, con credenziali e identificativi di sessione non protetti;
  4. cross site scripting, in cui l’applicazione invia al browser di un utente codice inserito da un attaccante;
  5. buffer overflow nei componenti scritti in linguaggi che non controllano la memoria, come alcuni moduli CGI o librerie;
  6. injection, cioè l’invio di comandi a interpreti come database SQL o sistema operativo attraverso i parametri;
  7. gestione impropria degli errori, con messaggi che rivelano dettagli interni o comportamenti che lasciano il sistema in uno stato insicuro;
  8. memorizzazione insicura di password, numeri di carte e altri dati, con cifratura assente o realizzata male;
  9. negazione del servizio, ottenuta consumando risorse dell’applicazione con richieste costose;
  10. gestione insicura della configurazione di server e applicazioni, con account predefiniti, file di esempio e servizi inutili.

Due esempi concreti

Una pagina di accesso costruisce la query al database concatenando i valori inseriti nel modulo. Se nel campo della password si inserisce una stringa con un apice e una condizione sempre vera, la query restituisce un utente valido senza conoscere la password. È un caso di injection, reso possibile dalla mancata validazione dell’input. La contromisura è usare query parametriche e validare ogni valore secondo il tipo atteso.
Un forum mostra i messaggi degli utenti senza codificare i caratteri speciali. Un utente inserisce nel messaggio un frammento di JavaScript che legge il cookie di sessione e lo invia a un server esterno. Ogni visitatore che apre il messaggio consegna la propria sessione all’attaccante. È un cross site scripting. La contromisura è codificare in uscita i caratteri speciali e limitare ciò che l’utente può inserire.

Un principio comune

Molte categorie hanno la stessa radice. L’applicazione si fida di ciò che arriva dal browser, mentre tutto ciò che arriva dal client può essere modificato, compresi campi nascosti, cookie, intestazioni e parametri dell’indirizzo. I controlli fatti in JavaScript nel browser migliorano l’usabilità e restano aggirabili da chiunque modifichi la richiesta. La regola è validare sul server ogni dato, con un elenco di ciò che è consentito, e trattare come ostile tutto il resto.

Sessioni e controllo degli accessi

Le categorie due e tre meritano attenzione perché i loro errori non si vedono nei test funzionali. Un’applicazione che mostra il profilo dell’utente in base a un numero passato nell’indirizzo funziona perfettamente per chi la usa in modo normale. Basta cambiare quel numero per leggere il profilo di un altro. Allo stesso modo un identificativo di sessione prevedibile, trasmesso senza cifratura o mai scaduto, permette di impersonare un utente senza conoscerne la password. Le contromisure sono controllare sul server, a ogni richiesta, che l’utente abbia diritto alla risorsa, generare identificativi di sessione casuali e lunghi, proteggerli con SSL e invalidarli alla disconnessione e dopo un periodo di inattività.

Come usare la Top Ten

L’elenco si presta a diversi usi pratici:
  • come lista di controllo nella revisione del codice e nei test prima della messa in produzione;
  • come base per la formazione degli sviluppatori, che spesso non conoscono questi problemi;
  • come requisito nei contratti, chiedendo al fornitore di dichiarare come ha affrontato ciascuna categoria;
  • come punto di partenza per un programma di test periodici sulle applicazioni già in esercizio.
Il documento stesso avverte che non è un elenco completo. È una sintesi dei problemi più frequenti e gravi osservati dai partecipanti al progetto, destinata a essere aggiornata nel tempo. Un’applicazione che li evita tutti ha eliminato le cause più comuni di compromissione, e resta esposta a errori di altro tipo.

Le conseguenze per chi gestisce i sistemi

Per chi amministra server web la Top Ten sposta l’attenzione. Il server può essere aggiornato e configurato con cura e restare esposto attraverso l’applicazione che ospita. Per questo i test di sicurezza dovrebbero includere prove sulle applicazioni, con strumenti che modificano i parametri delle richieste, oltre alle scansioni dei servizi di rete. I log del server web, se conservati e analizzati, permettono di riconoscere molti tentativi di attacco, come richieste con apici, parole chiave SQL o tag script nei parametri.
 
Vedi anche: l’articolo del 2013 Principi di sviluppo software sicuro, l’articolo del 2018 Metodologie di penetration testing e l’articolo del 2021 Log4Shell.
 
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.
Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn