Newsgroup: it.lavoro.professioni.webmaster
Titolo: Un problema di sicurezza: aprire una sessione e portarsi dietro l'ID di un utente.

Sto lavorando ad un progetto in PHP e sono arrivato al punto in cui ho 
necessità di una funzionalità di accesso che abbia un minimo di decenza.
Naturalmente utilizzo le sessioni, e quindi indirettamente i cookie. Mi 
è sorto perciò un dubbio: come variabile di sessione ci metto l'ID 
dell'utente che ha effettuato il login. Se l'utente in questione è un 
po' sgamato e cambia l'ID salvato nel cookie, potrebbe facilmente 
impersonare un altro utente, giusto?
Una soluzione a questo problema, avevo pensato, potrebbe essere 
associare nel database, al momento del login, l'ID dell'utente con l'ID 
di sessione e poi controllare ad ogni nuova richiesta di pagina se 
utente e sessione corrispondono.
Magari esiste qualche altro metodo che non passa per il database e che 
quindi è più conveniente?
Grazie.

impersonare un altro utente, giusto?
Sì. La cosa più efficiente da fare è usare come session-id il default
di PHP, e poi salvare l'id utente come
	$_SESSION['userid'] = ...
Es.:
<?php
	define('SESSION_NAME', 'xyzzy');
	session_name(SESSION_NAME);
	session_start();
	if (isset($_REQUEST['user']))
	{
		// Richiesta di login
		// Controlla utente e password da $_REQUEST
		if (tutto bene)
		{
			$_SESSION['userid'] = userid_appena_recuperato
		}
	}
	if (!isset($_SESSION['userid']))
	{
		// Mostra la form di login
		readfile('login-page.html');
		die();
	}
...
Leonardo
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

Grazie per il codice.
Il mio dubbio in realtà era un altro, e riguardava la facile modifica, 
da parte di un utente smaliziato, dell'ID stoccato nella sessione. Così 
facendo può impersonare facilmente un altro utente.
Il punto è: il modo migliore per tenere a bada l'utente smaliziato è 
tenermi una copia degli ID di sessione e utente nel database, oppure 
esiste una soluzione migliore?

 dell'utente che ha effettuato il login
Se è una "variabile di sessione" come la intendo io (In $_SESSION in PHP) 
allora il suo valore è memorizzato da qualche parte nel server associata al 
session_id, di conseguenza l'utente non ha modo di cambiarne il valore.
Puoi essere certo che tutto ciò che metti lì non è visibile né modificabile 
dall'utente.
Ciao,
-- 
  Daniele Orlandi					つづく

 Grazie.
Prova:
http://www.phpclasses.org/package/1818-PHP-Database-based-session-management.html
J.

facendo può impersonare facilmente un altro utente.
Non c'e' nessun ID che l'utente possa modificare. L'unico dato che
l'utente ha sul PC è una roba del tipo (semplificando)
.
tuosito.com
	xyzzy	aa1b8fac82937a0445f18c14c4c1d5165fc1278b
e se l'entropia funziona come deve, non c'e' modo per altri (salvo
XSS attack e simili) di ottenere quella sequenza aa1b8.. .
Se fornisci il cookie sbagliato, diciamo aa1b8...278c (ho cambiato
solo l'ultima cifra), il server ti risponde picche.
Poi, SUL SERVER, esiste una directory dove c'e' un file (poniamo)
	aa1b8fac82937a0445f18c14c4c1d5165fc1278b.txt
con dentro scritto
	userid:		1701
	name:		James Tiberius
	access:		Fleet Captain
	...
 
ma arrivarci non e' facile, con la maggior parte degli hoster.


Ah bene, ho capito.
Pensavo invece che la sessione venisse salvata nei cookie lato client. 
Adesso è più chiaro, grazie!


Ricevuto. Leonardo ha già provveduto a dare una spiegazione abbastanza 
dettagliata.


Eh però io volevo proprio evitare l'accesso al database. Cmq buono a 
sapersi, questa libreria potrà essere utile per altri tipi di progetto.

 Adesso è più chiaro, grazie!
*può* succedere che i dati della sessione vengano messi nel cookie, in 
effetti è così che dovrebbe funzionare per tenere HTTP veramente stateless.
Non è il caso con PHP ma in ogni caso se i dati vengono messi nel cookie di 
solito vengono criptati o per lo meno firmati dal server.
