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

CAS: a short introduction

Si tratta di un sistema di autenticazione originariamente creato dall’università di YALE, per fornire una modalità di autenticazione di un utente per una applicazione. Il produttore, Ja-SIG, è un consorzio globale no-profit costituito da università e partner commerciali.
Tra le sue caratteristiche tecniche si più importanti:

1. Un protocollo aperto e ben documentato;
2. SSO non solo WEB; Supporta anche la proxy autentication che permette per esempio anche a intere applicazioni di autenticarsi e non solo a client web.- Compliant con il procollo SAML per l’iterazione con altri sistemi SSO;
3. Una componente server open source; E’ possibile scaricarselo e installarselo in casa per testare l’ambiente. Funziona sia con apache 1 che apache 2.
4. Una vasta libreria di client per Java, Net, PHP, Perl, Apache, uPortal e altri ancora;
5. Integrato con uPortal, BlueSocket, TikiWiki, Mule, Liferay, ExO, Moodle e altri ancora
6. Vengono forniti molti esempi pronti all’uso.
7. Si tratta di un software con una comunità abbastanza robusta e attiva.
8. Rilasciato con aggiornamenti abbastanza cadenzati.
9. Scritto in java e open source.

Funzionamento

E’ basato su cookie di sessione (come la maggior parte dei SSO).

CAS richiede SSL.

CAS usa LDAP per memorizzare le informazioni degli utenti connessi.

Quando un utente accede ad un sito CASizzato il sito lo reinderizza al server CAS. In questa fase un cookie viene salvato sulla macchina dell’utente. Questo cookie contiene un ticket univoco che lo identifica. Dopo che CAS ha verificato la sua identità lo rimanda indietro al sito di partenza. CAS aggancia un ticket unico alla URL del sito protetto.

Il sito protetto vede il ticket e manda tale ticket al CAS server. CAS chiede al servizio protetto se il ticket è buono. Se si l’accesso è garantito.

Client per CAS

Net Cas Client

.Net Http module

Acegi as CAS Client

ASP.NET Forms Authentication

AuthCAS

CAS + Seam Web Applications

CAS and JSR-168

CAS Client for Java 3.0

CAS Client for Java 3.1

CAS Proxying with ASP.Net Forms Authentication

CASBar- Toolbar for Firefox 2

CASP — CASP is an ASP .NET CAS client implementation in C #.

ColdFusion client script

Copy of CAS Client for Java 3.0

ISAPI Filter

Java Client

JSP Client

mod_auth_cas

MOD_CAS

mod_python auth module

PAM Module

Perl Client

phpCAS

CAS e Java

Per quanto riguarda la configurazione. Si mette un jar nel web-inf. Si configura un filtro (CAS in Java è gestito mediante Filter) e dovrebbe essere tutto a posto.

http://www.ja-sig.org/wiki/display/CAS/CASifying+Tomcat+Manager

CAS e .NET

http://www.ja-sig.org/wiki/display/CASC/ASP.NET+Forms+Authentication

In .NET viene usato un HTTPModule.

Esempio in DotNET

HTTPModule Filter Process

Il filtro HTTPModule è un programma C# che intercetta tutte le URL verso IIS 6.0 ed esegue le seguenti azioni:

il filtro controlla se si tratta di un utente valido guardando il cookie di sessione.

se un utente valido esiste (l’utente si è già autenticato all’applicazione corrente), lo USER ID è registrato nella collection degli elementi di contesto alla voce HTTP_USER e il controllo viene redirezionato alla URL richiesta. l’utente può essere prelevato in questo modo: string user = (string)Context.Items["HTTP_USER"];

Se non esiste un utente valido nel cookie di sesisone allora il filtro controlla il Ticket nel SSO Server.

se il ticket esiste (l’utente è stato già autenticato) il filtro inizia con il SSOServer il processo di validazione, uno user ID viene generato e salvato e crittato nel cookie di sessione e memorizzato nella collection di contesto alla voce HTTP_USER.

se la validazione fallisce viene generato un errore e il filtro torna un eccezione.

se nè esiste un utente valido, nè un ticket esiste (l’utente non si è autenticato) allora il filtro inizia un processo di login redirezionando il controllo al processo di SSO Login.

il filtro HTTPModule usa 2 files di configurazione per gestire questa fase:

il primo definisce i nomi di directory file e le directory del file di configurazione principale, se viene richiesta SSL, se e dove loggare le informazioni sul processo di filtro.

Il filtro HTTPModule è installato in ogni directory in cui si vuole intercettare la URL.

Se il filtro valido l’utente l’applicazione può leggere lo userID nella server variable HTTP_user.

Se il server SSO non valida l’utente l’applicazione non accederà mai alla URL richiesta.

Conclusioni

In buona sostanza CAS è un sistema di autenticazione puro e non di autorizzazione.

In altre parole consente di propagare l’identità dell’utente tra diverse applicazioni eventualmente istallate su server o in domini differenti mediante dei ticket crittografati. La determinazione dell’autorizzazioni assegnate ad un utente e l’enforcing delle policy di sicurezza sono compiti che spettano all’applicazione.

In effetti, è prassi utilizzare CAS in combinazione con un directory server in cui sono censite sia le identità degli utenti che i ruoli assegnati, tuttavia è responsabilità di ogni singola applicazione connettersi alla directory per accedere al profilo dell’utente e quindi applicare le dovute policy. Una possibile soluzione potrebbe essere quella di inserire nel ticket / cookie informazioni supplementari. Essendo il ticket scambiato di frequente non è una procedura consigliabile dato che il profilo di un utente può essere molto articolato mentre tale ticket deve essere il più snello possibile.

Riferimenti

http://www.ja-sig.org/products/cas/

http://wiki.case.edu/Central_Authentication_Service

http://www.ja-sig.org/wiki/display/CASC/.Net+Http+module

http://www.ja-sig.org/wiki/display/CASC/ASP.NET+Forms+Authentication

http://www.ja-sig.org/wiki/display/CASC/CAS+Proxying+with+ASP.Net+Forms+Authentication

http://www.ja-sig.org/wiki/display/CASC/ASP.NET+Forms+Authentication+with+Role+Provider