> SSL protegge dallo spoofing lungo il percorso, ma come detto prima da me e
> dopo anche da Matteo Flora ci sono tante bei sistemi che hanno accesso a
> questa url IN CHIARO:
> - il javascript che ho segnalato prima e che segnala anche Flora di Omniture
> aka Adobe.
> - la browser history (adesso vado sul pc di mio fratello che ha vodafone e
> gli guardo la history...)
> - javascript che accedono alla history del browser
> - HTTP referrer -> La url viene consegnata alla pagina successiva...
(o a un provider di contenuti esterni, se ce ne sono, come e' stato
fatto notare ipotizzando uno scenario con banner provider, dove una
informazione di questo tipo non solo viene utilizzata ma e' essenziale
per distinguere quale sito clicca di piu' i banner e come ricompensare
chi li ospita).
Altro modo per mettere in evidenza il rischio legato al metodo seguito:
-Un server VNC nascosto, installato all'insaputa dell'utente (mi e'
capitato di scoprirne uno presso chi non sapeva nemmeno cosa fosse),
magari addirittura da lui stesso (tramite un trojan). Ovviamente, col
passaggio al POST, da un keylogger non ci si difende; ma almeno da
questo si', ed e' gia' qualcosa. Paradossalmente, un VNC nascosto, o un
equivalente "geneticamente modificato" :-) per essere lui a "chiamare
casa", rischia di "carpire" perfino i dati da un metodo di inserimento
molto differente che ho visto in giro e che era venduto come piu' sicuro
di altri: vi era stata implementata a video una tastiera (in AJAX, Flash
o altro: non lo so perche' non ho avuto modo di esaminarlo da vicino) da
azionare col mouse.
Credo si possa riformulare lo scopo di questa discussione, nata come
PASSWORD GET vs. POST over HTTPS ma di natura molto generale, domandando
e domandandosi: e' sufficiente assumere che un servizio/applicativo di
rete sia ben protetto "solo" perche' usa qualche buon layer
crittografico nella connessione di rete? Secondo me non del tutto, dato
che la crittografia protegge, appunto, la connessione soltanto,
lasciando fuori tutto il resto. Nel caso scatenante, ci sono dati assai
vitali "disclosed", e molto piu' a lungo, rispetto a numerose altre
applicazioni che pure girano in HTTPS; il che comporta certamente una
vulnerabilita' maggiore, a prescindere dal modo in cui un attaccante
puo' arrivare a sfruttarla. L'assunzione che il client sia sicuro sotto
qualsiasi punto di vista, fisico e non, sembra il tallone d'Achille, in
questo caso.
Il suggerimento piu' valido, nell'immediato, e' senz'altro l'uso del
POST, come da inizio del thread.
Un suggerimento anche migliore, per un futuro piu' lontano, e'
senz'altro l'impiego di un metodo di autenticazione basato sulla
gestione della sessione, nel quale i dati inseriti dall'utente per
identificarsi siano utilizzati solo al momento di iniziarla, e non in
maniera persistente durante tutta la sessione stessa. Cio' implica una
buona sicurezza nel caso si usi un identificatore di sessione one-time
gestito lato server e utilizzato "al volo" dal browser, quindi reso non
valido quando non serve piu'. Se si preferisce non lasciare tracce
sull'hard disk del client, come risulta con un sito in HTTPS, per il
quale i browser non dovrebbero tenere alcuna disk cache, e' possibile
non mettere il Session-ID in un cookie (che e' anche lui un file
sull'hard disk) e passarlo in POST (campo hidden nell'HTML ritrasmesso
di pagina in pagina dopo il login); possibilmente, non in GET,
altrimenti si finirebbe ancora piuttosto vicini al punto dal quale si e'
partiti.
Se, infatti, qualcuno "leggesse" il session-ID in GET da una URL mentre
una sessione ha luogo (e sono io il primo ad ammettere che bisognerebbe
essere proprio svelti e/o avere una fortuna sfacciata), si potrebbe
comunque arrivare a usare l'applicativo e la sessione "rubata". In una
tale situazione, si potrebbe comunque cambiare (se non viene richiesta
daccapo quella corrente) la password dell'utente legittimo, allo scopo
di tagliarlo fuori dal suo account (se ne accorgerebbe, certo; ma
sarebbe anche tardi). Col POST, un modo che mi viene in mente, sul
momento, per "esporre" quei dati sarebbe che l'utente stesso aprisse il
sorgente della pagina per andare a vedere dove sono i campi hidden...
cioe' che li andasse a cercare, di proposito, e proprio mentre viene
spiato. Questo e' effettivamente meno probabile. Vale anche per username
e password, ma con un Session-ID il rischio, cioe' l'ammontare del danno
se/quando non e' piu' potenziale ma reale, e' gia' piu' basso.
saluti,
Marcello Magnifico
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
