Newsgroup: it.comp.www.php
Titolo: Session Hijacking

Ancora a parlare di sicurezza...
 
Sto sviluppando un app (mioddio quanto parlo alla moda!!) usando ZendFramework, usando "plain php" per controllare Hijacking della sessione sono solito controllo ip+useragent.
 
Siccome non sono esperto di Zend ho cercato qualcosa in rete ed ho trovato alcune risorse che reputano del tutto inutile (anzi in alcuni casi anti-produttivo) questo tipo di controlli.
 
Ora la domanda, HTTPS + cookie settati in httpOnly + rigenerazione del session_id, garantiscono una sicurezza sufficiente?
 
 
Sempre pensando che se uno poi ha la macchina compromessa non è un problema mio (magari metterò una pagina di consigli su come utilizzare il browser, tipo prima di loggarsi aprire tutti i social network, lanciare tutti i farmville del caso e loggarsi dentro a gmail, youporn e qualche sito warez (ma esistono ancora??) così stai sicuro che ti inculano la password e siamo tutti contenti... ahahahah)
 
 
Altra domanda, che mi ricordo aver già fatto tempo fa ma non la ritrovo nel newsgroup, c'è modo per salvare le informazioni sulla sessione in modo che se qualcuno ha accesso al server non le possa vedere? Fantasia vero? L'idea che i sysadmin delle banche possano vedere tutti i dati dei correntisti mi intriga.
 
La questione tecnica è che ho il DB criptato con AES e l'utente deve digitarla  (la pwd è diversa per ogni utente) e soprattuto da qualche parte me la devo salvare e pensavo di salvarla nell'SQL usando:
 
SET @userKey='password';
 
e poi
 
INSERT INTO miaTabellaSegreta SET datoPrivato = AES_ENCRYPT("HoUccisoKennedy",@userKey)
 
Secure enought?
 
J.

 Secure enought?
 
Follia pura! Innanzitutto la "password" dell'utente utilizzata come key, 
se sbaglia a digitarla il db far� l'insert come ordinato ma poi voglio 
vedere come si estraggono i dati, poi c'� il problema lato client di 
sniffer & co, e se qualcuno riesce ad accedere al web-server pu� sempre 
mettersi le password da parte in un bel file per i tempi di crisi 
mandando a remengo l'intera architettura, ma l'incubo peggiore � senza 
ombra di dubbio l'utente che richiama dopo 3 mesi lamentando d'aver 
scordato la password o che � assolutamente certo che sia quella ma il 
sistema non l'accetta e ci si ritrova con un cliente inviperito (a dir 
poco), un database inservibile e probabilmente anche qualche azione 
legale al seguito.
 
Nessuno al mondo � tenato fesso da cifrare un db con chiavi fornite 
dall'utente, i DB industriali utilizzano hardware come Sun Crypto 
Accelerator 6000 PCIe, basta fare una ricerca su Google "Oracle Advanced 
Security Transparent Data Encryption"
 
Per l'autenticazione dei client invece si utilizzano smart card 
contenenti certificati x.509 possibilmente emessi da CA accreditate dai 
rispettivi governi, per l'Italia
http://www.digitpa.gov.it/certificatori_firma_digitale
 
 
O si crea una propria Certificate Autority (Banche e grandi enti ne 
hanno una propria) ed emettono smart card o Token per i propri dipendenti
 
Questo se vogliamo *parlare* di sicurezza, il resto sono barzellette..
 
 

 Questo se vogliamo *parlare* di sicurezza, il resto sono barzellette..
 
Grazie
 
J.

 Si concordo, ma la smart card è somodissima, per poter accedere devi avere la smart + il lettore e cmq devi spedire le info attraverso la rete, una giusta misura non credi sia nella password + token?
 
Qesta e lunga.. e devo proprio scappare ma torneremo sull'argomento
 
Bye


 Qesta e lunga.. e devo proprio scappare ma torneremo sull'argomento
 
Ok!
 
 
J.

>> Si concordo, ma la smart card e' somodissima, per poter accedere devi avere la smart + il lettore e cmq devi spedire le info attraverso la rete, una giusta misura non credi sia nella password + token?
 
Analizziamo semplicemente i costi delle 2 soluzioni:
 
Lato utente:
Smart card + lettore o in alternativa tokenUSB: meno di 100€ e può 
accedere a tutti i siti della PA + tutti quelli che implementeranno la 
stessa tecnologia.
In alcune regioni come il Trentino alto Adige è gratis dato che il 
certificato di autenticazione è integrato nella tessera sanitaria e il 
lettore lo danno gratis all'attivazione della stessa 
http://www.cartaservizi.provincia.tn.it
 
Strumento standard di autenticazione di tutti i cittadini dell'UE (tra 
l'altro)
 
password + token: dai 35 ai 50€ per ogni token, per ogni sito internet 
al quale accedere con la suddetta tecnologia e dato che i siti sono 
tanti si avranno tanti token quanti siti richiedono questo tipo di 
autenticazione
 
Lato server:
Integrazione dell'autenticazione tramite certificati digitali: € 0 (ZERO)
 
Integrazione dell'autenticazione tramite password + token: € 5000 
(cinquemila)
 
Veda lei cosa preferisce
 
 
 
 
 

 Integrazione dell'autenticazione tramite password + token: € 5000 (cinquemila)
 
A cosa sono dovuti i 5.000€?
 
J.

 A cosa sono dovuti i 5.000€?
 
5.000 per iniziare.. in genere per l'appliance, poi ci sono le licenze 
software che vanno in base al numero di token
 
i prezzi reali per 10.000 utenti li trovi qui
 
http://www.entrust.com/strong-authentication/identityguard/calculator.cfm
 
 
Se ti avanza una milionata di euro.. parliamone!
 
 
 

 Se ti avanza una milionata di euro.. parliamone!
 
Ok, mi hai convinto ... ;)
 
J.

 Ok, perfetto direi che per l'identificazione questa è la Via, ma visto che a me non interessa identificare la persona fisica, ma solamente l'utente, potrebbe essere interessante fornire direttamente il token con dentro un certificato valido solamente per l'accesso al server sfruttando le funzionalità dell'Aladdin.
 
Peccato che così l'utente si ritroverebbe un token in più (che qualcuno 
dovrà pagare) utilizzabile esclusivamente nel suo sito/dominio, si fa 
prima e meglio ad inserire il link dove acquistare i dispositivi 
completi di certificato di autenticazione + firma qualificata tipo
http://www.pec.it/ArubaKey.aspx
 e problema risolto.
 
Ora, negli ultimi giorni ho lavorato alla semplificazione 
dell'installazione per rendere la cosa più indolore possibile.
 
Il tutto si limita a scompattare un paio di tar.gz ed inserire un paio 
di link uno che punta dalla Home al file di login e l'altro nel file di 
login che punta nuovamente al file in cui si va a gestire la cosa via DB.
 
In parole povere viene inizializzata una sessione che crea il cookie 
PHPSESSID, quindi registra in $_SESSION il "codice fiscale" dell'utente 
loggato.
 
Basta inserire un include('../path/include.php');
ed ecco disponibile il $codice_fiscale, da qui in poi lasciamo allo 
sviluppatore la gestione delle credenziali, probabilmente nella maggior 
parte dei casi sarà sufficiente inserire un campo nella tabella del db 
per collegare username -> codice_fiscale
 
In caso di 1 utente + account tipo conti correnti bancari (per esempio) 
è sufficente gestire il login mettendo in correlazione il/i numeri di 
conto con i/il codice/i fiscali attraverso una tabella di DB.
 
Ovviamente nell'arco dell'intera vita dell'utente il codice fiscale 
rimane univoco e inalterabile

 rimane univoco e inalterabile
 
Qui parli di Italia, all'estero come funziona? in UK c'e' il nin in usa il SSN, ma nel resto del mondo non ne ho idea.
 
 
J.