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

ESRI and Supported OGC Specifications

In questo breve articolo elencherò brevemente il supporto di alcuni prodotti ESRI (quelli che uso) alle specifiche OGC.

 

OGC specifications supportati

 

                       

standard	descrizione	provider	consumer
WMS 1.1.1	Fornisce mappe	Arcims, arcgisserver 9.x	Arcgisdesktop 9.x webadf 9.x openlayers
WMS 1.3	Fornisce mappe	Arcims arcgisserver 9.x	Arcgisdesktop 9.x webadf 9.x Openlayers
WFS 1.0	Fornisce feature	Arcims 9.x	Arcgisdesktop 9.x con interoperability
WFS 1.1	Fornisce feature	Arcims 9.3 arcgisserver 9.3	Arcgisdesktop 9.3 con interoperability Openlayers
WFS-T 1.1	Gestisce anche in editing feature	Arcgisserver 9.3	Openlayers
WCS 1.0	Fornisce dati raster	Argcisserver 9.3	Arcgisdektop 9.3 Openlayers
WCS 1.1.1	Fornisce dati raster	Arcgisserver 9.3	Arcgisdesktop 9.3 openlayers
KML 2.1	Google earth	Arcgiserver 9.x	Arcgisexplorer
KML 2.2 OGC	Google earth	Arcgisserver 9.3	Arcgisexplorer

 

 

Note su cosa è in grado di fare ARCIMS rispetto agli standard.

 

Arcims java connector ha degli oggetti capaci di dialogare in maniera primitiva con server WMS ma non WFS.

 

ARCIMS non è un client WMS o WFS nè tantomento WCS. Questo significa che non sa consumare layer di questo tipo tramite AXL. È possibile aggiungere wms e wfs (se esiste estensione data interoperability in arcgis desktop) in un mxd e creare un arcims map service ma ci sono alcune differenze minimali rispetto agli image server.

 

Esistono librerie di terze parti javascript per aprire mappe wms / wfs.

Addirittura con openlayers si possono fare query di modifica in wfs-t. Peccato che dei server più conosciuti solo Geoserver lo supporti.

 

 

Riguardo le diverse possibiltà che ARCIMS offre in termini di comunicabilità con altre sorgenti dati ovvero in che modo ARCIMS riesce ad aggiungere layer alle sue mappa vi posso dire che esistono 3 diversi tipi di file di configurazione che a volte possono generare ambiguità:

Map configuration Files, Viewer Configuration Files e Default AXL.

 

Map Configuration Files

Per quanto riguarda il primo esso è il file AXL classico che si deve compilare per configurare ARCIMS. In questo file bisogna fornire l’insieme di istruzioni per le proprietà della mappa e il rendering. le varie richieste al server ARCIMS (XML REquest) possono modificare alcune proprietà specificate nell’AXL come aggiungere nuovi layer, modificare l’aspetto etc… Possiamo dire che l’AXL fornisce il comportamento di default della mappa.

l’ attributo più importante, in questo articolo è WORKSPACES

esso specifica la location di tutti i dati usati nella mappa. nel map configuration files ci sono solo 3 tipi di workstation validi: shapeworkspace (usato per referenziare shapefile), imageworkspace (usato per referenziare directory con immagini), sdeworkspace (usato per referenziare layers in ArcSDE di tipo raster o vettoriale).

Il file di configurazione si trova sul server. I dati che possono essere caricati appartengono alla rete locale.

 

 

Viewer Configuration Files

Questo file di configurazione è l’output del salvataggio tramite ArcExplorer o l’ARCIMS Java Viewers e risiede nella macchina locale.

La struttura di questo tipo di file è molto simile a quella del Map Configuration File. Una differenza importante viene rappresentata da elementi aggiuntivi nel tag WORKSPACES.

ImageServerworkspace che permette di puntare ad un imageserver.

featureserverworkspace che permette di puntare ad un arcims feature server.

I dati che possono essere caricati sono servizi ARCIMS e dati presenti nella rete locale.

 

Default.axl: A Special Viewer Configuration File

il default.axl è un file di configurazione speciale che è l’output del ARCIMS Designer quando un arcims java viewer viene creato.

Viene usato per caricare i servizi ARCIMS in un ARCIMS Java Viewer.

la struttura è molto simile a quella di un viewer configuration file. importante è notare che quando arcims designer crea default.axl e un feature service è incluso, un layer viene incluso in default.axl per ogni layer nel feature service. bisogna stare attenti quando si aggiungono o cancellano layers nei feature service. se un layer viene aggiunto nel servizio ma non nel default.axl l’arcims java viewer non visualizza il nuovo layer. Se un layer viene cancellato nel servizio viene mostrato un messaggio di layer no trovato.

Questo file di configurazione si trova sul server.

I dati che possono essere caricati sono solo Arcims services.

 

Differenze tra le modalità di interrogazione di ImageService e MapService

Sostanzialmente i due tipi di servizi (uno caricato tramite AXL e l’altro tramite MXD) possono essere interrogati in maniera similare. ci sono alcune differenza

inoltre si possono interrogare servizi imageserver e mapserver quasi allo stesso modo nel senso che in qualcuni casi ci sono indicate le differenze nella sintassi in altri casi non c’è scritto niente
Per esempio per get_features le queries sui layer dinamici possono essere fatte solo su image services, workspace è valido solo per image services mentre dataframe è valido solo per mapservices.

per get_image gli unici valori per workspace sono imageworkspace, shapeworkspace e sdeworkspace.

per get_extract solo i dati vettoriali vengono estratti, le immagini e i layers acetati non vengono estratti. vale solo per image server.

 

 

 

Standard WMS, WFS and WCS: a short introduction

WMS: permette di creare mappe a partire da dati grezzi, interrogare dati e legende quindi come output si creano: immagini, kml, svg, pdf

WFS: permette di descrivere, fornire e modificare dati vettoriali quindi come output abbiamo shapefile e file gml

Al contrario di WMS, si lavora a livello di dato, non di rappresentazione. Non ci sono associazioni o collegamenti

Sono l’equivalente di una tabella di base dati.

Descrivono esattamente la struttura della base dati cui sono collegati (nome colonna -> nome attributo)

WCS: permette di descrivere e fornire dati raster come output abbiamo geotiff

WFS-T

Permette di gestire in scrittura il dato geografico. La T sta per Transaction e le operazioni che si possono fare sono quelle classiche ACID (read, update, insert, delete)

Possibili client/consumer wfs-t:

udig, openlayers, mapbuilder, geoserver

Possibili client/consumer wms:

mapserver, deegree, chamaleon, openlayers

Possibili client/consumer wfs:

mapserver, geoserver, openlayers

Operatori disponibili

WMS (1.1.1)

1. GetMap (disegno mappa)
2. GetFeatureInfo (interrogazione dati)
3. GetCapabilities (Catalogo layer, stili, funzionalità supportate)

WFS

1. GetCapabilities (Catalogo layer, capacità del server)
2. DescribeFeatureType (descrizione di ogni layer)
3. GetFeature (Estrazione dati con filtri, selezione attributi, cambio proiezione)

WFS-T

1. GetFeatureWithLock
2. LockFeature
3. Transaction

WCS

1. GetCapabilities (Catalogo layer, capacità del server)
2. DescribeCoverage (descrizione di ogni layer)
3. GetCoverage (Estrazione per area geografica, banda, dimensione)

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