Newsgroup: it.comp.www.asp
Titolo: Studio della sicurezza nelle pagine web

Ciao all!
Oggi vi scrivo non tanto per porvi una domanda su un dubio ma per vedere voi
come gestite il sistema e capire cosa effettivamente sia sicuro fare.
Per prima cosa inizio dicendo che voglio parlare della sicurezza nel login e
nel passare fra le pagine il discorso che l'utente e' loggato o meno.
Per l'inserimento di uid e pwd non c'e' niente da fare, o almeno, se non si
passa tramite https i dati dal form di richiesta alla pagina che valida
l'utente, non si puo' fare nulla per evitare il trasferimento in chiaro, si
intende senza usare sistemi tipo activex e simili...
Ma una volta che l'utente e' stato loggato, voi come fate a far passare
questa info alle altre pagine che possono funzionare solo in base al login
effettuato con successo?
Di metodi ce ne sono tanti, ma ogniuno ha i suoi bei buchi nella sicurezza,
un paio fra questi sono usare le sessioni, settando ad esempio un "Flag" in
una variabile di sessione, poi le altre pagine controllano se il flag e'
settato, se lo e' l'utente e' accettato.
Un altro metodo molto usato e' quello di fare la stessa cosa prima spiegata
per le session, solo che anziche' usare una session si usa un coockie.
Entrambi i metodi hanno la scomodita' di dover avere per forza un coockie
salvato dal lato client, e se qualcuno si passa il tempo ed e' abb
smaliziato potrebbe mettersi un coockie con il flag gia' settato, saltare
alle pagine successive del login e fregare tutto...
Come si potrebbe fare o quali sono le vostre soluzioni a questo problema?
Come passate l'avvenuto login fra le pagine in modo sicuro?
Grazie per l'attenzione e ciao! ;^)=
-- 
--
RedFoxy
A fox around web
Power at fox for a yiffing world!
La legge del marketing:
Non migliorare il prodotto, cerca un cliente piu' scemo.

 Come passate l'avvenuto login fra le pagine in modo sicuro?
Personalmente il login lo gestisco mediante la creazione di sessioni che
possono contenere altre informazioni oltre che il classico "authenticated =
true", quali ad esempio livelli autorizzativi o profili particolari.
Poi, con un po' di fantasia e riesci sicuramente a creare qualche grattacapo
a chi vuole rompere i marroni, ma il sito sicuro senza https (e una buona
logica sottostante) non esiste. Basta sniffare i dati di login...  ;-)
Ciao

 per le session, solo che anziche' usare una session si usa un coockie.
No questo è sconsigliabile.
Primo perchè, in qualche modo (l'hai capito da solo) qualcuno se lo 
potrebbe rigirare in autonomia.
Secondo perchè così chiunque è un grado di capire come funziona 
l'autenticazione, che variabile viene settata, come eccetera.
Con molti browser vedi TUTTO, il nome della var, il contenuto, 
eccetera.
La sessione è, invece, una var che sta sul server. Il cookie interviene 
solo per agganciare server e client tramite il sessionID.
Quindi è più sicura, perchè non so che roba è, come viene messa, e non 
posso toccarla.
Poi, succede di tutto, sappiamo che la sicurezza totale non esiste.
In IE, non ricordo da quale versione, puoi staccare i cookie ma lasciar 
passare i cookie di sessione.
Resta il problema che se uno ha cookie completamente staccati, non 
autentichi nulla.
Io risolvo lavorando, in questi casi, con un sessionID che passo in 
querystring (in ogni pagina...), salvando il tutto sul database. Con 
una serie di altri controlli, ripulisco poi il database.
C'era una discussione poco tempo fa, con dei link piuttosto 
interessanti. Appena li trovo te li mando, essendoti peraltro grato per 
altre cose (vedi la sicurezza... uno cambia nickname, account...).

 altre cose (vedi la sicurezza... uno cambia nickname, account...).
Ecco, ecco, li aveva proposti Andrea Zani
http://www.4guysfromrolla.com/webtech/041600-2.shtml
http://www.webmasterpoint.org/asp/pratica/122.asp
http://www.devarticles.com/c/a/ASP/Session-Replacement-in-ASP/
http://www.nogetec.de/asp/filter/sessionid
 (in tedesco)

Ciao RedFoxy
I cookies non li sopporto!
Session c'č e non c'č!
Querystring, piů chiaro di cosě!
La mia idea č di usare il database x mantenere lo stato
naturalmente solo per utenti loggati in area riservata!
 
--
Enjoy the .NET community! ASPItalia.com
 
http://forum.aspitalia.com/
 
http://www.aspitalia.com/

 ha scritto nel messaggio
news:MPG.1a902ffc5...@news.tin.it...

I link qui sopra mi hanno leggermente confuso, escluso il caso di Server in
Load Balancing, o voler gestire lo stato da applicativi client ad
applicazioni web, qual'è il limite reale delle session?
Quanto il fatto che si devono avere i cookies abilitati è un limite?
Vale la pena approfondire il discorso? Cambiare metodo di sviluppo?
complicare il codice?
E' o non è una masturbazione mentale questa?
VincenzoA

 dati di login...  ;-)
Il problema fondamentale dei session cookie e' che se qualcuno per un motivo
o per un altro non li ha attivi, o un proxy mal configurato li filtra, il
tutto non andrebbe...
Non so' se mi spiego...
Inoltre oltre all'id di sessione nel coockie che viene inviato al client, se
non ricordo male, vengono inviati altri dati che possono essere riformulati
per prendersi una sessione attiva, cioe' intendo, io ho la sessione 54 e
sono autenticato, arriva quello che vuole entrare e prova fino a quando non
becca la sessione giusta da inserire nel coockie di sessione (e gia' un buon
aiuto lo riceve da IIS) e a quel punto si ritroverebbe assegnati tutti
valori di quella session attiva e percio' loggato.
Non so' se mi spiego...


 
http://www.nogetec.de/asp/filter/sessionid
 (in tedesco)
Grazie li sto' leggendo proprio ora!


 naturalmente solo per utenti loggati in area riservata!
Si ma cosi' aumenti lo swapping del DB in modo mostruoso, specialmente con i
test di autenticazioni e di grado di autorizzazione!
Inoltre come uniqueid cosa usi nel querystring? la sessionid? Ma se uno ha i
coockie disattivati niente sessionid e percioi' niente querystring


 E' o non è una masturbazione mentale questa?
Dipende dalle necessita' e dal lavoro che bisogna realizzare...
Io, ad esempio, devo realizzare un sistema "always on", che deve funzionare
in qualsiasi caso e possibilita' dal lato client, senza contare che deve
avere le "mutande di ferro"
Per quanto riguarda i coockie... Ti meraviglieresti di sapere quante sono le
casistiche che non permetterebbero il corretto utilizzo di un sito,
specialmente se tutto dipende dai cookie...
Basta un proxy mal configurato e scassa i cookie in trasferimento, un
browser vecchio che non li legge, di una sicurezza troppo alta tanto da
togliere anche i cookie di session e tanto altro...
Tutto dipende dal progetto e dal target... Pensa che molti pensano di fare
siti compatibili solo con IE fregandosene del resto...


 coockie disattivati niente sessionid e percioi' niente querystring
No il SessionID esiste, solo che viene reinizializzato ad ogni pagina, 
perchè per il server quello è un utente nuovo, non potendolo 
riconoscere.
Personalmente passo il session.sessionID in querystring, dalla seconda 
pagina del sito (dove posso effettivamente capire se le sessioni vanno 
o meno: nella prima creo una var di sessione, nella seconda leggo se 
c'è).
Se poi, caso di un ecommerce che tiene in memoria i dati dalla tabella 
ShoppingCart precedente (memorizzo il sessionID di cui sopra su cookie) 
ci aggiungo roba relativa alla data corrente (discorso delle mutande di 
ferro). Sai mai che viene riavviato il server, e dopo 2 settimane uno 
si becca il sessionID di un altro, caso uno su milioni ma...
O col cookie o dopo il login, ecco apparire il sessionID della 
navigazione precedente.

 valori di quella session attiva e percio' loggato.
Diciamo che realisticamente uno fa prima a sniffare il login...  ;-)

 Diciamo che realisticamente uno fa prima a sniffare il login...  ;-)
Vero, se non fosse che il login magari lo si cripta con SSL o similari, in
modo da rendere piu' complessa la lettura dei dati passati
Ciao ;^)=
