Newsgroup: it.lavoro.professioni.webmaster
Titolo: Form e sicurezza dei dati: soluzione artigianale

 Voi che ne pensate della soluzione?
Che volendo potrei sniffare il traffico da e verso la tua macchina e quindi ti
leggo pure la chiave. Comunque almno in questo modo un minimo di lavoro lo
daresti.
Ciao,
 Stefano
----------
"X WindowSSS, teSSSoro mio... lo odieremo per SSSempre"
Bill Gollum
----------

 leggo pure la chiave.
Quindi la chiave viaggerebbe insieme ai dati anche se č contenuta in una
variabile di sessione?
Mao
--------------------------------
Inviato via 
http://usenet.libero.it


Secondo me č molto interessante come metodo.
Sě, molto ingegnoso.
Per quanto riguarda la chiave puoi evitare di usare le session. Puoi usare
application oppure ancora salvarla sul server da qualche parte (db o file di
testo) e associarla all'utente prendendo l'ID della sua sessione. ID
SESSIONE-->CHIAVE

 migliore da suggerirmi?
Può funzionare come soluzione di ripiego, ma utilizzerei SSL se avessi 
una qualsiasi esigenza di sicurezza.
-- 
Roberto Lupi

 testo)
Potrebbe essere una soluzione, perņ ho paura che non risolva del tutto il
problema (almeno se ho ben capito quello che intendevi); ti faccio un
esempio di ciņ a cui avevo pensato:
- l'utente richiede la pagina contenente il form;
- il server invia la pagina al client insieme alla chiave;
- la chiave a questo punto č visibile in chiaro dall'utente all'interno del
sorgente HTML (in quanto contenuta come variabile nel JavaScript che
effettua la criptazione) e gią qui si ravvisa la necessitą di avere chiavi
diverse per utenti diversi;
- l'utente clicca sul tasto "Invia" del form scatenando l'evento onSubmit;
- lo script parte, cripta i dati con la chiave in esso contenuta e li invia
cosģ al server;
- i dati giungono cripati al server;
- il server decripta i dati.
Affinchč la pagina di destinazione possa decriptare i dati, č necessario che
la chiave sia resa disponibile in qualche modo alla pagina di destinazione
stessa; ma come? Se la inviassi insieme ai dati criptati non avrei risolto
nulla perchč sarebbe come spedire una cassetta chiusa a chiave con la chiave
attaccata. Se la chiave fosse contenuta in una variabile application o in un
file txt o db, il client non dovrebbe rispedirla al server insieme ai dati,
ma sarebbe comunque uguale per tutti gli utenti (per cui sarebbe sufficiente
che qualcuno desse un'occhiata al JavaScript per scoprirla). Il problema č
che la chiave dovrebbe essere sempre diversa per ciascun utente (in modo che
non ci sia una regola fissa per criptare i dati) e deve allo stesso tempo
essere nota anche al server (che deve decriptare i dati). In definitiva la
chiave dovrebbe viaggiare in un solo senso (dal server al client) nel
momento in cui l'utente richiede la pagina con il form ma non dovrebbe
tornare indietro (dal client al server) nel momento in cui l'utente invia i
dati. Per questo avevo pensato ad una variabile session, ma ho il dubbio che
tali variabili siano comunque scambiate tra client e server e quindi
intercettabili con uno sniffer.
Comunque grazie molte per il tuo contributo.



Non credo proprio che le variabili di sessione viaggino per andare da
qualche parte; penso piuttosto che rimangano allegramente immagazzinate in
qualche area di memoria dell'application server, per cui sniffare non
servirebbe a niente.
IMHO, ovviamente
Rimangono comunque tutti i problemi evidenziati da Roberto Lupi
Lupetto


Quindi, se ho capito bene, l'unica variabile che si scambiano client e
server č l'ID di sessione?
Grazie.


 ha scritto nel messaggio
news:F_zcb.346330$lK4.11...@twister1.libero.it...


 cui questo richiede la pagina contenente il form?
<cut>
Il succo e':
per poter criptare i dati del form con javascript devi eseguire l'operazione
sul client, il che significa che anche la chiave deve trovarsi sul client.
Dal momento che la chiave viene generata sul server, per arrivare al client
passa in chiaro sulla rete e puo' essere sniffata. Dal momento che anche
l'algoritmo risiede sul client (e' in javascript), puo' esser sniffato anche
lui insieme alla pagina che lo contiene, per cui l'eventuale sniffatore ha
tutto il necessario per fregarti ;)
Ciao, Lupetto

 tutto il necessario per fregarti ;)
No affatto. Sai cosa sia PGP?
Hai notato che le mail inviate con questo sistema contengono la chiave?
si chiama "chiave pubblica" apposta. Perchč la usi per criptare, ma non per
DEcriptare

 ha scritto nel messaggio
news:JwVcb.349104$Ny5.11...@twister2.libero.it...



si, lo so, di questo ha gia' parlato Roberto Lupi in un post precedente in
questo stesso thread: io mi sono limitato a chiarire i punti sottintesi del
post dello stesso
Roberto che spiegava  che senza  una chiave pubblica il
sistema del nostro amico sarebbe aperto a tutti gli sniffatori del mondo ;)
Ciao, Lupetto

 server è l'ID di sessione?
Esatto. Il client riceve l'ID della sessione, ma non il contenuto della 
sessione stessa.
-- 
Roberto Lupi

 DEcriptare
Sì, è ciò che scrissi nel mio precedente messaggio.
In ogni caso, stiamo trascurando la cosa piu' importante che rende 
decisamente sconsigliabile lo schema descritto in un'applicazione reale.
Il protocollo SSL (HTTPS) ha due finalità:
1) rendere la comunicazione fra il server ed il browser indecifrabile a 
terzi;
2) autenticare uno oppure entrambi gli interlocutori.
Sono due obiettivi interconnessi, non possono essere scissi se si vuole 
ottenere una comunicazione sicura.
La soluzione proposta cerca di soddisfare il primo obiettivo, ma ha 
alcune limitazioni e problemi:
- un eventuale sniffer ha a disposizione la chiave pubblica del server, 
l'algoritmo di crittazione e l'esatta struttura dei dati crittati (e con 
buona probabilità, conosce il dominio dei dati in chiaro -- es. un nome 
contiene solo determinati caratteri, è inutile ipotizzare che il testo 
in chiaro possa contenere caratteri quali §$%&£! dove è stato codificato 
un nome) -- tutti elementi utili per poter mettere in piedi una ricerca 
della chiave privata del server.
- non sono un esperto di crittoanalisi, ma -a naso- direi che è 
opportuno utilizzare una coppia di chiavi (pubblica/privata) differenti 
per ogni pagina servita all'utente; altrimenti, usando una sola chiave 
per server/pagina/utente, si fornirebbe ad un eventuale sniffer un 
corpus di testo criptato molto più vasto da poter sottoporre ad analisi. 
Inoltre una chiave valida per lungo tempo è molto più rischiosa che una 
la cui validità è limitata.
- in Javascript, non è facile implementare un algoritmo di crittografia 
a chiave pubblica ed un algoritmo di compressione (per ovviare al primo 
punto della lista, rendendo equiprobabili i simboli del testo da 
cifrare), né credo siano disponibili implementazioni già pronte e di 
grande qualità.
L'altro aspetto fondamentale da considerare è l'affidabilità 
dell'interlocutore. Nello schema evidenziato non c'è alcun metodo per 
determinare se chi sta comunicando è degno di fiducia oppure no:
- potendo fare spoofing, è possibile impersonare il server nella 
comunicazione con il client ed impersonare il client nella comunicazione 
con il server. Uno scenario di questo tipo (Man in the middle) non è 
possibile con HTTPS (il client riconosce il server grazie al certificato 
controfirmato da un terzo fidato -- i.e. una certification authority).
-- 
Roberto Lupi