Concordo... Non capisco davvero il problema del GET o del POST. Semmai avete controllato che la sessione utente sia stata aperta sul server e che sia difficilmente riproducibile o identificabile?
Come diceva Stefano il problema è drive-by download con tutte le conseguenze, quindi il tallone d'achille come giustamente si diceva nella discussione (anche se io preferisco dire l'anello debole della catena) è client side, per questo è opportuno prendere le opportune precauzioni server side: 1. Canale di comunicazione criptato (SSL va benissimo, fin quando non ci saranno i computer quantistici :P) 2. Meccanismo solido e sicuro di sessione lato server (non mi dilungo nella tipologia e topologia di secure session sharing in architetture web) 3. Eventuale criptazione (e.g. one time pad) per scambio informazioni client-server (cookie, stringhe sia in GET e in POST etc etc) 4. Utilizzo di strong authentication (e.g. two factor authentication) per le aree riservate del sito 5. Evitare tutti i controlli e i metodi client side, quali active-x, flash,javascript, ajax per lo scambio di informazioni che si vogliono mantenere riservate Sicuramente mi è sfuggito qualcosa, ma l'ora è tarda Buona Notte Fausto -----Original Message----- Roberto Scaccia wrote: Esistono gli Extended Certificate che sono ben visibili dagli utenti. Se poi l'utente è talmente tonto da cascare in siti di phishing oppure la rete è talmente bucata che piazzano sniffer ovunque o peggio fare MTM, non è che lo puoi imputare al GET/POST :-) Ma mi viene il dubbio che forse mi sono perso qualche cosa.... Stefano Zanero wrote: No, ma nemmeno inventarsi problemi assurdi, quando i problemi di sicurezza delle transazioni di oggi si chiamano drive-by download. -- Cordiali saluti, Stefano Zanero________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
