[ImoLUG] [OT] JSESSIONID e sicurezza applicazioni java

[Riccardo Govoni ☢]

Posto che a) non conosco Pentaho, b) devo ancora prendere il caffe' e c)
oggi a Londra c'e' un sole che spacca e questo mi da alla testa piu' di una
boccia di lambrusco:

Quanto dice il "referente" e' vero. Il riconoscimento di una sessione basato
su cookie / parametri della richiesta e' il funzionamento standard delle web
applications. MA, non ha assolutamente nulla a che fare con
l'autenticazione/autorizzazione di un utente.

Un session_id ha il solo scopo di permettere al server di correlare
informazioni di stato con richieste separate nel tempo provenienti da uno
stesso browser. Punto. Affidare a tale session_id anche il ruolo di token di
autenticazione/autorizzazione/proxied login vuol dire andare in cerca di
guai. Per talmente tante ragioni da riempirci il Tamigi: session hijacking,
replay attacks, etc .... Spostare il jsessionid da parametro GET, a POST o
cookie non fa differenza sostanziale sul profilo di rischio, il problema e'
a priori (GET e' pure peggio, in quanto i parametri GET sono generalmente
loggati da server/proxies attraverso cui la richiesta passa). http->https fa
poca differenza se il client e' un browser, vedi xsrf.

Non mi e' chiaro come Pentaho deve interagire con la tua applicazione. Se si
tratta solo di permettere alla tua app di forwardare richieste a pentaho in
modo tale da permettere a pentaho di riconoscere una *sessione* vista in
precedenza (e/o viceversa), allora puo' anche andare, ma bada che sto
parlando di *sessione* e non di *utente* (quindi Pentaho dovrebbe anche
ricevere informazioni di autenticazione extra, oltre al jsessionid, come ad
esempio tokens xsrf per ogni richiesta che "forwardi" ). Se pentaho si fida
di un jsessionid (e questo soltanto) per definire le
credenziali/autorizzazioni di un utente, allora non va bene.

Ci sono diversi sistemi  ben piu' solidi di un jsessionid per federare il
processo di autorizzazione/autenticazione tra piu' server che devono
interagire con uno stesso client. OAuth, tanto per citarne uno (qui c'e' un
overview,
http://developers.sun.com/identity/reference/techart/restwebservices.html,
tanto per avere l'idea, ignorando le specifiche librerie / server che tira
in ballo). Non so quanta flessibilita' tu abbia nella scelta, dipende da
cosa offre Pentaho, e dal tipo di interazione che il client vuole.

/R.
P.s: OAuth beginner overview (include una discussione sui replay attacks):
http://hueniverse.com/oauth/

2010/5/21 Mario Giammarco <mgiammarco@gmail.com>

>
>
> Il giorno 21 maggio 2010 09.58, valerio balbi <valerio.balbi@gmail.com> ha
> scritto:
>
> > Mi è stato risposto, dal referente dello sviluppo, che "il riconoscimento
>> di
>> > una sessione basato su cookie/header HTTP è il funzionamento standard
>> delle
>> > web application" solo che non mi ha convinto del tutto e chiedo a voi
>> lumi:
>> > siamo sicuri che vada bene così?
>>
>>
> Come consulente java ti posso dire che in molte grosse aziende il concetto
> di "programmazione sicura" e' nullo.
> Il project manager o l'analista non hanno competenze di sicurezza, non le
> vogliono avere, e ritengono che quello che fanno
> loro sia sicuro "a priori", visto che, fra l'altro, hanno sicuramente
> copiato quella soluzione da qualcun altro (senza comprenderla) e, in ogni
> caso, quegli attacchi come il "replay attack" accadono solo nei film, sono
> cose per fissati e comunque non capitano a loro e tu  in nessun caso gli
> farai perdere tempo a rifare le stime per il progetto perche' devi
> aggiungere "la sicurezza".
>
> Chiuso lo sfogo (che comunque e' utie perche' fa capire i meccanismi
> psicologici e non tecnici che avvengono all'interno di un progetto in
> aziende reali quando occorre prendere decisioni tecniche importanti)
> sicuramente una cosa cosi' ha una parvenza di sicurezza solo con HTTPS.
>
> L'ultima versione di pentaho supporta un meccanismo di autenticazione java
> chiamato acegi, che sta diventando uno standard di fatto per java. La
> soluzione piu' corretta e' quella di vedere se tale framework puo' essere
> utilizzato nel vostro caso.
>
>
>
> _______________________________________________
> ImoLUG mailing list
> imolug@lists.linux.it
> http://lists.linux.it/listinfo/imolug
> Connettivita' offerta da Waymedia - http://www.waymedia.it/
>
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.linux.it/private/imolug/attachments/20100521/c255e19b/attachment-0001.htm>