[ImoLUG] [OT] JSESSIONID e sicurezza applicazioni java

Ven 21 Maggio 2010 12:47:31 CEST

Ti rispondo con una domanda. Date queste due richieste:

http://www.miabanca.it/daiUnMilioneARiccardo?jsessionid=1234567
http://www.miabanca.it/daiUnMilioneARiccardo?jsessionid=1234567

come fai a distinguere quella che l'utente ha veramente richiesto da quella
che e' stata invece 'costruita' da un utente malevolo?
(nota che non fa differenza se sposti il jsessionid dalla GET ad un cookie
).

Risposta: non puoi. Assieme al jsessionid deve passare qualcos altro che ti
dica che questa specifica richiesta e' stata davvero fatta dall'utente.
Tipicamente questo si fa con un token
XSRF<http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet>
ed
i cosiddetti "double submit cookies", che sono tecniche valide dalla notte
dei tempi, ben prima di OAuth et similia.

Nota 1: non confondere OAuth ed il processo di federazione delle credenziali
(il server A manda richieste al server B per conto dell'utente tizio) con il
processo di verifica dell'utente (come posso essere sicuro che la richiesta
che arriva sia davvero fatta dall'utente), da cui deriva quanto detto in
precedenza che passare in giro i soli jsessionid non e' abbastanza.

Nota 2: le vulnerabilita' di cui sopra sono generalmente mitigate dal fatto
che i session_id non sono sempre cosi' semplici da indovinare e, in genere,
durano poco, quindi i replay attack vanno fatti nel giro di 15-30 min. A
parte questo, si', e' veramente semplice fingersi un altro utente se non usi
altra forma di verifica delle credenziali.

Cosa succede se clicchi un link su un forum che ti manda a questa pagina,
mentre sei collegato al sito della tua banca, che usa solo il jsessionid
come fattore di autenticazione ?

<html>
<body>
<img src="donnaNuda.jpg">
<img src="http://www.miabanca.it/daiUnMilioneARiccardo"  width=0 height=0>
</body>
</html>

a) tu vedi una donna nuda.
b) parte una richiesta per la tua banca. I cookie associati vengono inviati
di conseguenza
c) io faccio su una paccata di soldi.

nessuno e' colpevole. Tu hai cliccato il link. Il tuo cookie e' andato alla
banca. La banca non ha modo di distinguere che tu non hai "volontariamente"
fatto la richiesta.

Nota che ci sono 23980518 varianti dell'esempio di cui sopra.
/R.

2010/5/21 virgilio pierini <virgilio.pierini@gmail.com>

> vi ringrazio per le interessanti risposte
> riccardo propone una piattaforma che, se ho inteso bene, è relativamente
> recente. la domanda è quindi immediata: ma prima come si faceva?
>
> cioè, la mia vecchia applicazione struts che, nel caso l'utente non avesse
> i cockies abilitati, metteva il jsessionid nella get è SUL SERIO così bucata
> da permettere ad un altro (il classico Mallory degli esempi wikipedia) di
> copiarsi l'url e impersonare il Bob o Alice di turno ?
>
> cioè SUL SERIO ad ogni richiesta il fatto di trovare in Session un oggetto
> UtenteAutenticato e fidarsi quindi dell'autenticazione fatta è sbagliato a
> fronte di tutte queste tecniche di attacco?
>
> sono confuso =8-0
>
> _______________________________________________
> 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/73ddc63a/attachment.htm>