Gengish’s Weblog

Just another WordPress.com weblog

Security in JavaEE applications: introduction

Le 10 vulnerabilità più critiche delle applicazioni web J2EE

Introduzione

Questo articolo descrive le 10 vulnerabilità più comuni e più critiche delle applicazioni web scritte in ambiente j2ee  con le tecnologie più comuni: servlet, jsp, struts, jsf, hibernate analizzando le varie debolezze che si possono avere e cercando di fornire una possibile soluzione al problema.

Le 10 vulnerabilità più critiche per le applicazioni web J2EE sono:

  1. Cross site scripting XSS
  2. Injection flaws
  3. Malicious file execution
  4. Insecure Direct Object Reference
  5. Cross site request forgery
  6. Information Leakage and Improper Error Handling
  7. Broken Authentication and Session Management
  8. Insecure Cryptographic Storage
  9. Insecure Communications
  10. Failure to Restrict URL Access

 

 

Breve Descrizione

 

1. XSS Cross Site Scripting

Gli xss flaws si verificano ogni qualvolta un utente fornisce dati all’applicazione ma questi non vengono nè convalidati nè tantomeno viene codificato l’output che si genera in seguito alla richiesta.

In questo modo si possono verificare casi in cui un utente malizioso può inserire script (in genere Javascript) all’interno dei campi della form per dirottare l’utente su altri siti, invalidare sessioni, modificare il sito stesso e introdurre worm.

 

2. Injection Flaws

L’injection flaws, in particolare il SQL injection, è molto comune nelle applicazioni Java EE ma anche in quelle del mondo .NET.

L’Injection si verifica quando l’utente fornisce dati in input che fanno parte di una query dinamica senza che questi vengano validati e controllati. E’ possibile che l’utente malizioso possa inserire in questi campi dei veri e propri pezzi di codice sql, per esempio, in modo da accedere a ulteriori dati in lettura oppure effettuare aggiornamenti o cancellazioni sulla tabella oggetto della query ma anche di altre se si riesce a conoscerne la denominazione e la struttura.

 

3. Maliciuos File Execution

Un codice vulnerabile all’inclusione di file remoti (RFI) permette all’utente malizioso di includere codice e dati ostili, con conseguenze molto devastanti, come ad esempio la compromissione totale del server.  Gli attacchi da esecuzione di file maligni affliggono tutte le applicazioni che accettano come input nomi di file o addirittura file veri e propri che possono nascondere file eseguibili al proprio interno (trojan e backdoor).

 

4. Insicure Direct Object Reference

Una Insecure Direct Object Reference si verifica quando uno sviluppatore espone un riferimento all’implementazione interna di un oggetto come un file, un record del db, una chiave, una URL o un parametro di una form. L’utente malizioso può manipolare tali riferimenti per ottenere l’accesso agli altri oggetti senza autorizzazione. Un tipico caso è quando si rende esplicito l’uso del codice conto come chiave di login per certe operazioni bancarie o l’uso del proprio codice fiscale.

 

5. CSRF

Un attacco di tipo Cross Site Request Forgery forza un browser trusted ovvero già autenticato a mandare una richiesta ad una applicazione j2ee vulnerabile in modo che si forza il browser a compiere un azione ostile a vantaggio dell’utente malizioso. Si tratta di una vulnerabilità molto simile a quella XSS ma se nel caso del XSS ci si fida di ciò che l’utente inserisce all’interno dei campi della form in questo caso si sfrutta la fiducia che si ha dell’applicativo. un tipico caso avviene quando si invita qualcuno a far parte di una comunity tramite l’invio di una email. questa email può essere intercettata da chiunque e quindi anche i ‘non invitati’ possono iscriversi senza che l’applicativo se ne accorga.

 

6. Information Leakage

Alcune applicazioni possono, non intenzionalmente, fornire informazioni sulla loro configurazione interna,  sulla loro implementazione a causa per esempio di una non appropriata gestione degli errori che non maschera alcuni dettagli che possono essere usati per dedurre e recuperare dati sensibili per danneggiare l’applicazione stessa o gli utenti che vi accedono.

 

7. Broken Authentication

Le credenziali utente e i token di sessione, spesso, non sono protetti in maniera sufficiente. In questo modo, l’utente malizioso, può compromettere password, chiavi e token di autenticazione per assumere l’identità di altri e quindi operare con privilegi più ampi di quelli normalmente a lui concessi.  queste debolezze nel sistema di autenticazione degli utenti quindi permettono alll’attaccante di indovinare facilmente le password, effettuare un attacco a forza bruta o aggirare totalmente l’operazione di login.

 

8. Insecure Cryptographic Storage

Le applicazioni j2ee sfruttano raramente le funzioni crittografiche per proteggere dati e credenziali ovvero raramente impostano una qualche forma di crittografia all’interno del db per nascondere i dato in chiaro se questo tratta di password di accesso, numero di conto bancario, numero di carta di credito.

ma ci sono anche casi in cui il sistema mostra di essere debole e vulnerabile nonostante adotti una qualche forma di crittografia:

  • trattamento errato dei dati critici (cifratura errata o debole)
  • conservazione errata delle chiavi, certificati e password che quindi possono essere rubate.
  • cattiva scelta degli algoritmi di cifratura
  • uso di algoritmi di cifratura non testati e quindi non affidabili
  • gestione errata o inesistente  della procedura di cambio chiavi

In questo modo l’utente malizioso può prelevare questi dati e usarli come se fossero i propri.

 

9. Insecure Communications

Le comunicazioni insicure avvengono quando alcune fasi di una tipica applicazione web come la login e l’inserimento dei dati di una carta di credito non avvengono sotto protocollo SSL che critta tutto il canale trasmissivo.  Gli attaccanti, quindi, possono agevolmente sniffare le credenziali di accesso o il numero di carta di credito per operare su conti bancari, effettuare acquisti con carte di credito non di loro possesso e quindi arrecare danno.

 

10. Failure to Restrict URL Access

Di frequente l’applicazione j2ee pensa di proteggere se stessa nascondendo alcune funzionalità tramite il non mostrare i link agli utenti autenticati ma senza le necessarie autorizzazioni. Un utente malizioso può però carpire il link a lui nascosto da una macchina sulla quale si è autenticato un utente con privilegi maggiori e quindi usare direttamente tale link ed accedere alla risorsa nascosta.

 

Statistiche

Le prime 4 vulnerabilità sono le più frequenti. Ognuna di esse colpisce almeno il 5% delle applicazioni.

 

Gli attacchi più frequenti e noti nel panorama delle applicazioni web sono:

  • Phising causato da scarso controllo di autenticazione e autorizzazione (A1, A4, A7, A10)
  • violazione della privacy causato da povera validazione, scarso controllo regole di business e debole controllo dell’autorizzazione (A2, A4, A6, A7, A10)
  • furto di identità causato da povero o non esistente controllo crittografico (A8, A9), inclusione remota di file (A3) e controllo debole di autorizzazioni, regole di business e autenticazione (A4, A7, A10)
  • compromissione del sistema, alterazione o distruzione dei dati causati da injections e remote file include (A2) e (A3)
  • perdite finanziarie attraverso transazioni nn autorizzare e CSRF attacks (A4, A5, A7, A10)
  • perdita della credibilità a causa della presenza di una qualsiasi delle precedenti vulnerabilità

 

Le vulnerabilità che ultimamente si stanno imponendo come le più critiche sono:

  • l’esecuzione di file maliziosi,
  • il Cross Site Request Forgery
  • la comunicazione insicura

 

 

A breve verranno dettagliate le varie vulnerabilità con una serie di articoli dedicati.

 

Riferimenti

http://www.intilinux.com/sicurezza/

http://www.owasp.org

http://www.notrace.it/

dicembre 12, 2008 - Posted by | hibernate, injection flaws, IT, Java, jsf, Security, sql injections, Standard, struts | , , , , , , , , , , , , , , ,

2 commenti »

  1. Thank goodness some bloggers can still write. Thanks for this piece..

    Commento di buy pagerank 10 blog | novembre 18, 2011 | Rispondi

  2. Great read..

    Commento di samsung corby | novembre 29, 2011 | Rispondi


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: