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/

www.owasp.org

http://www.notrace.it/

OGC specifications supportati

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.

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)

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

]]> http://gengish.wordpress.com/2008/07/28/cas-a-short-introduction/feed/ 1 gengish