Newsgroup: it.comp.www.php
Titolo: sessioni e sicurezza...

Salve a tutti,
volevo sapere se memorizzando le variabili
tramite le sessioni qualche malintenzionato
può andare a leggerele?
grazie
ringo

 può andare a leggerele?
In condizioni normali.. no.

 ha scritto nel messaggio
news:5koI9.68563$2B1.1...@twister2.libero.it...

E quali sono le condizioni speciali?
marcello

 ha scritto nel messaggio
news:_wpI9.67491$3l.18...@twister1.libero.it...


La prima che mi viene in mente è un tecnico del tuo hosting che va in /tmp e
digita
cat sess_624fbbde3d5ee0f64f6f7c65e7e3194f
o simile
Ovviamente questo è esteso a chiunque che, per qualche indefinito motivo,
abbia il permesso di accedere e vedere in quella dir..


Si possono sempre salvare le sessioni in memoria con mm, invece che su
disco; certo che se qualcuno sul server si mette a fare debugging
della memoria viva... :-)
In realtà, basta anche meno: se qualcuno scopre l'id della tua
sessione (per esempio dai log del webserver se usi il trans-sid, o
monitorando i cookie in qualche modo), gli basta far girare uno script
sul server settando session_id al tuo, e voila, ha un comodo accesso
alle tue variabili...
Tieni presente anche che chiunque, sempre sapendo l'id, può
"inserirsi" nella sessione di un tuo client, semplicemente chiamando
il tuo script con PHPSESSID=idsessionealtrui.
Quindi occhio!
Ciao
Ivan

 il tuo script con PHPSESSID=idsessionealtrui.
Ok.
Soluzioni?
A me viene in mente questa...
1 Quando l'utente entra il db verifica che esista il suo nome e la sua
password.
2 Creo il timestamp
3 Imposto quindi un UPDATE della tabella utenti in una colonna 'timestamp'
4 accodo il timestamp alle variabili di sessione.
5 possibilmente (ma io non so farlo) quando l'utente esce rimetto in blank
la colonna 'timestamp' relativa a quel dato utente.
A questo punto il PHPSESSID è inutilizzabile se non durante una sessione in
atto.
Un po' si riduce il rischio.. o no?
marcello



Sì, è la tecnica che uso anch'io per l'autentificazione... Anche se il
pericolo non è del tutto risolto, è alleviato dal fatto che il
malintenzionato ha solo il tempo che passa tra una chiamata e l'altra
alla pagina per rubare la sessione, e che se lo fa l'utente legittimo
viene tagliato fuori e quindi in teoria si può accorgere che qualcosa
non va. Per il punto 5 credo che le uniche soluzioni siano un logout
esplicito o un timeout (controllato alla successiva esecuzione)...
entrambe hanno dei difetti, ma così è la vita...!
Ciao!
Ivan

il tuo script con PHPSESSID=idsessionealtrui.
Contro un provider infedele non c'e' nulla da fare, perche' gli
basta sostituire il *SERVER* e il *modulo PHP* con una versione
trojan che per esempio dumpi le variabili all'apertura, ed alla
chiusura, di ogni script. A quel punto non ti serve a niente la
crittografia SSL a 2048 bit :-)
Quindi devi poter impedire un replication attack.
Puoi monitorare il suo IP, lo User-Agent, o inviargli un cookie
crittografico. Nella sessione memorizzi l'MD5 del cookie. Cosi'
ti difendi contro la parziale compromissione del filesystem sul
server (per difenderti contro la compromissione della rete, SSL
a grandine).
Se ti arriva un tizio, con anche un solo dato sbagliato, marchi
la sessione come compromessa. Puoi verificare HTTP_REFERER e, a
patto di correre qualche rischio, la porta d'origine sul client
(varia secondo una legge prevedibile, dipendente dall'OS).
Leonardo paranoico


Urca! Come fai a prevederla? Dipende dalla quantità di connessioni che
ha il client al momento... no?
Ciao!
Ivan paranoico paranoico paranoooico

 Ivan paranoico paranoico paranoooico
aspetto emozioooni sempre più indefinibili... in-de-fi-ni-bi-li!
(CCCP - Emilia paranoica)
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.efluxa.it/netiquette/dis.html

(CCCP - Emilia paranoica)
Grande, per fortuna qualcuno coglie la citazione!
Ciao
Ivan

ha il client al momento... no?
Sì e no. Il dato diventa sempre meno significativo a mano a mano che
la distanza fra due connessioni aumenta, ovviamente. E naturalmente,
non ti serve se la connessione e' nattata perche' due client diversi
avranno porte di uscita contigue. Idem nel caso di proxy.
Leonardo
-- 
Time's angles, mages tell, conceal a place
incredible, beyond the mundane mind;
night-shrouded and between the seas of space
dread creatures drift in the ageless winds.


Nun so... cosa possiamo fare in Javascript in piů rispetto a quello
che facciamo con il PHP? Le informazioni a disposizione sono sempre
quelle... Perň, potrebbe essere utile per risolvere il problema del
logout, magari con un ping ad intervalli regolari ad uno script sul
server.
Forse tutto sommato l'unica č con SSL: insieme al cookie facciamo un
hash anche del SSL_SESSION_ID e se cambia tagliamo la nostra
sessione... Cosě ci proteggiamo anche da chi vede il nostro cookie sul
client. Credo! Che ne dici?
Ciao!
Ivan

server.
No, sto pensando vagamente e con pochi neuroni residui alla possibilita'
di avere un cookie (o un SID passato via POST/GET) che ogni volta varia,
in un modo che il server possa verificare ma non prevedere.
Ad es. il server invia 31415, memorizza a0b868bb8c1dd0197f31b7a190119e9d
e cosi' si assicura che, se uno compromette il server, non puo' sapere a
priori che il codice da ricevere e' 31415, puo' solo verificarlo.
Ma il codice "31415" puo' essere recuperato e usato (replication attack)
e quindi non posso trasmetterlo.
Diciamo allora che il server all'atto del login invia una sequenza time,
usata per sincronizzarsi, e un Javascript sul client la mixa ad username
e password (hashati) e produce un hash MD5 che viene spedito al server.
A questo punto, il server sa che l'hash memorizzato per quel cliente, in
coppa alla timestamp, deve dare un hash MD5 che e' quello che il client,
appunto, ha spedito.
In pratica bisognerebbe usare due "frames": una, che memorizza in RAM lo
hash di user+password, e ha la funzione "gotourl"; la funzione gotourl()
semplicemente prende l'ultimo SEQ ricevuto dal server, provvede all'hash
e carica l'URL nella seconda frame (magari l'unica visibile).
Se uno intercetta il timestamp, ci fa il brodo, perche' senza l'hash MD5
principale e' inutilizzabile. D'altra parte, il server non ha il modo di
sapere quale hash gli arrivera', per tradirlo: puo' solo verificarlo.
Chiaramente, scordati di fare "Apri documento in nuova finestra".
E tutti gli href dovranno essere
	href="javascript:gotourl('nuovapagina.htm');"
e non
	href="nuovapagina.htm"
(A questo punto in genere i miei colleghi urlano "LEVATENI 'R FIASCOO!")


pericolo non è del tutto risolto
si' puo' aggiungere, come ulteriore controllo, che l'indirizzo IP non
cambi: se siamo in presenza di un IP diverso, allora la sessione viene
chiusa e l'utente sbattuto fuori.
hola
Buttha

 [snip]
Ma se l'esigenza di sicurezza e' cosi' spinta, perche' non fare
autenticare il client mediante certificato SSL? Del resto, e' stato
pensato per questo.

pensato per questo.
Per esempio se il server Web e' uno spazio per pņeri, con porta 80 e isati.
Ma la risposta vera e': perche' a me mi garba fammi 'e rasponi :-)))


Ma la risposta vera e': perche' a me mi garba fammi 'e rasponi :-)))
 :-)
Beh, a questo punto dico la mia:
bisognerebbe implementare un sistema di certificazione dell'identita'
che non sia openssl (dato che non l'abbiamo a disposizione).
Ogni pagina php instaura questa sequenza:
1) genera un numero random
2) lo spedisce all'utente
3) l'utente lo firma
4) lo script php verifica la firma e se va bene prosegue
Il piccolo dettaglio che ho omesso e' che sistema utilizzare per la
certificazione.
hola
Buttha

 chiusa e l'utente sbattuto fuori.
Ehi, sai che questa e' una buona idea? :-)
Resta il fatto che la password viene comunicata al server su una
cartolina... :-(
Cordialmente,
Emiliano Farinella
-- 
"Science as a candle in the dark" -- Carl Sagan

4) lo script php verifica la firma e se va bene prosegue
Yes, e' quello che avevo elucubrato io, piu' o meno.
Ci penso su. Ti faccio sapere.
