Nota: Se stai leggendo questo messaggio è perchè non vedi i nostri file css, oppure perchè non hai un browser "standards-compliant browser". Leggi l'aiuto.

TechTarget Italy & 01net Network SearchCIO.it SearchNetworking.it SearchSecurity.it 01net 01netCIO 01netPMI 01netTRADE 01netNETS iTechStudio Digifocus Applicando CIO Club ProntoImprese IlSoftware
Cerca
in
Quanto è sicuro Java?
Approfondimenti
Quanto è sicuro Java?
Alcune debolezze hanno messo in discussione l’affidabilità di uno dei più diffusi linguaggi per il Web. Tuttavia, se si usano alcuni accorgimenti, Java rimane un codice molto sicuro e affidabile.
Link suggeriti
11 Settembre 2007

Per lungo tempo, Java è stato reputato un linguaggio di programmazione sicuro. Ultimamente, però, questa reputazione è stata messa in discussione. Java è stato infatti accusato di essere soggetto al cross-site scripting (XSS) e ad altri simili attacchi di input, come l'injection SQL.

Ma allora sta peggiorando la sicurezza di Java in sé oppure sta indebolendosi la sicurezza delle applicazioni Web che usano Java? Gli attacchi XSS sono dovuti al codice scadente di Java o a uno scarso progetto delle applicazioni Web? In questo articolo, esamineremo le caratteristiche di sicurezza di Java, i recenti exploit che hanno indotto qualcuno a mettere in discussione Java e le best practice per mantenere sicure le applicazioni Java.

Caratteristiche di sicurezza del Java
Java integra un certo numero di caratteristiche di sicurezza non presenti in altri linguaggi. Per esempio, controlla le dimensioni dei dati di input, impedendo il buffer overflow, un comune exploit in cui un attacker "sommerge" un'applicazione con una quantità di dati maggiore a quella che può essere gestita. Un buffer overflow può mandare in crash un'applicazione o, se strutturato in modo adeguato, può attivare un processo che permetta accessi maligni al sistema.

Diversamente da altri linguaggi, quali il C e assembler, Java si “autoelimina” finito il suo utilizzo. In pratica, dopo che un'applicazione si è chiusa, grazie a un apposito sistema di pulizia, Java svuota la memoria usata da tale applicazione. Questo processo, che funziona in background, impedisce che altri exploit possano impossessarsi di un'applicazione sovraccaricando la memoria impiegata.

La più robusta versione enterprise di Java, J2EE, porta la sicurezza a un livello più elevato tramite un insieme di pacchetti di crittografia per la codifica dei dati e memorizza in modo sicuro le chiavi crittografiche. J2EE, inoltre, dispone di file di configurazione che possono anche "blindare" un'applicazione Java consentendo l'accesso agli utenti autorizzati e bloccando l'accesso di quelli indesiderati.

Oltre a queste caratteristiche, Java dispone di pacchetti per l'autenticazione e la verifica del codice. I pacchetti di autenticazione permettono che il login dei moduli esterni per il loro collegamento. Il controllo del codice verifica che il bytecode Java sia caricato nell'applicazione affinché ne venga assicurata la legittimità.

I più comuni exploit di Java
Con tutte le caratteristiche di sicurezza che incorporate Java, come potrebbe accadere qualcosa di negativo? Ecco alcuni dei più comuni exploit usati contro Java e anche alcune best practice per evitarli.

Recentemente, la maggior parte degli exploit sono stati attacchi come l'injection SQL e XSS, e sessioni di hijacking (Java non è soggetto al buffer overflow poiché controlla le dimensioni dei buffer di input).

Dato che Java è spesso usato come middleware per collegare i sistemi di backend e frontend, viene frequentemente impiegato nelle applicazioni Web per connettere i siti Internet e i database. Ciò lo rende soggetto agli attacchi injection SQL e XSS, con cui gli attacker veicolano il codice maligno (sui form dei siti Web) inseriti in un collegamento apparentemente innocuo su una pagina Web.

In XSS, l'attacker usa del codice maligno embedded per prendere le informazioni da un sito Web, quale le credenziali di login o le informazioni relative al conto corrente bancario. L'injection SQL è simile, eccetto per il fatto che l'attacker inserisce le istruzioni SQL e tenta di rubare le stesse informazioni dal database di backend che fornisce i dati al sito Web.

Proteggersi da questi tipi di attacchi richiede la combinazione di best practice di programmazione, disegno delle applicazione e project management. Il modo migliore per impedire gli attacchi di injection secondo la prospettiva della programmazione prevede la convalida e la “cancellazione” di tutti gli input.

Gli attacchi di injection sono innescati da caratteri speciali, come < e > nel caso di XSS e dall'apostrofo (') negli attacchi SQL. Gli sviluppatori possono aggiungere del codice che controlli l'input dai siti Web per individuare eventuali caratteri speciali (convalida), in caso affermativo vengono rimossi (cancellazione). Per evitare ulteriori injection SQL, gli sviluppatori dovrebbero assicurare che siano evitati statement maligni codificando le stringhe che non possono essere concatenate negli statement SQL e usare statement predefiniti.

Un'altra minaccia contro Java è la sessione di hijacking, in cui un attacker maligno impersona un utente legittimo subentrando nella loro sessione. Una sessione dirottata può essere usata per accedere all'account reale dell'utente e ottenere le informazioni personali o per impadronirsi del conto corrente bancario.

Le stesse regole che si applicano in Java valgono in tutti gli altri linguaggi per le sessioni di protezione. Queste includono la generazione di una sessione ID casuale e unica che cessa di esistere quando l'applicazione viene chiusa. L'output JSESSIONID generato da Java può essere codificato per soddisfare i requisiti dei predetti test di verifica. Le sessioni possono anche essere controllate attraverso i cookie. Sia i cookie che le sessioni ID possono essere compromessi tramite XSS, perciò proteggersi da XSS è il modo migliore per bloccare le sessione hijacking quando si usa Java.

In sintesi
I progetti di sviluppo Java dovrebbero essere controllati dal punto di vista della sicurezza, come accade per un progetto in qualunque altro linguaggio. I requisiti di sicurezza dovrebbero essere inclusi nei requisiti di business e nelle specifiche funzionali anche prima che lo sviluppo cominci. Le revisioni di sicurezza dovrebbero essere incorporate nel ciclo di vita del progetto assieme alle verifiche del codice e ai test a intervalli regolari.

Per Java in particolare, Fortify Software offre un buon tool per testare il codice al fine di verificare le vulnerabilità di sicurezza. Fortify gestisce inoltre il database Java Open Review Project sulle vulnerabilità Java. Un'altra buona fonte di informazione è Open Web Application Security Project (OWASP).

Java è oggi meno sicuro di quanto sia mai stato in precedenza? Non proprio. Ultimamente ha perso un po' di punti perché ha evidenziato alcuni degli stessi difetti che affliggono altre applicazioni Web. Ma questi difetti, come XSS, fanno parte delle vulnerabilità connesse con tutta la programmazione per il Web e non sono necessariamente specifici di Java. Con una combinazione di sicure practice di programmazione (come la convalida e la cancellazione dell'input e un sicuro session management), di sicuri progetti delle applicazioni e l'inserimento di verifiche della sicurezza nel ciclo di sviluppo, i progetti il Java possono essere resi affidabili e sicuri.

Il Sole 24 ORE S.p.A.

Sede Legale in Milano, Via Monte Rosa, 91 - Sede Operativa: Via Carlo Pisacane, 1 - Pero (MI)

Partita Iva - Codice Fiscale 00777910159 - Dati societari