Quali sono i rischi nell'archiviazione dei dati in sessione?

Question

Ho sentito parlare di script cross-site e che le persone possono accedere ai cookie e ai modi subdoli. Quindi speravo che qualcuno potesse rispondere ad alcune domande intorno a questi. Voglio prendere l'esempio di archiviare qualcosa in sessione nel modo più puro, ma usando un CMS come Drupal. Diciamo che abbiamo questo:

$data = $fancyWebService->getSuperSecureDataThatOnlyTheCurrentlyLoggedInUserCanSee(); 
$_SESSION['basic_variable'] = $data; 

1. Qualora l'utente ora viaggiare da mysite.com, a devious-site.com, c'è un modo che qualcuno possa ottenere i dati da "basic_variable", solo conoscendo che la variabile è chiamata così?
2. Esiste un modo per cui l'utente corrente può vedere una stampa della variabile $ _SERVER e vedere effettivamente tutti i contenuti memorizzati in essa?
3. Ho letto da qualche parte che i dati nella sessione o nei cookie devono essere "crittografati". Nell'esempio sopra, sono abbastanza sicuro che i dati vengano archiviati nella sessione e che questa sessione sia sicura. È questo il caso o è sicuro solo se HTTPS è abilitato?
4. Drupal memorizza alcune informazioni nei cookie, se si sceglie di utilizzare i cookie come indicato in "sessione", in che modo ciò influisce su quanto sopra?

UPDATE

per quanto riguarda la domanda 2. Voglio dire, se mi digitare quanto segue in un file php:

print '<pre>'; 
print_r($_SESSION); 
die(); 

(o semplicemente vardump la variabile di sessione) ...

Finisco con tutte le informazioni che ho memorizzato lì, non crittografate. La mia domanda è, c'è un modo in cui un utente può in qualche modo trovare un modo per ottenere l'accesso alla variabile di sessione (oltre che attraverso me esponendola) che renderebbe una cattiva idea lasciare i valori non criptati?

Answer 1

Grom utente ha una grande risposta qui che cita modi per proteggere la sessione in PHP : https://stackoverflow.com/a/7488/3874219

Mi piacerebbe iniziare dicendo PHP, specialmente 5.x.x versioni, hanno fatto molta strada nella sicurezza; tuttavia, ci sono ancora molte cose potenziali che possono accadere ai tuoi dati di sessione, poiché vengono costantemente trasmessi tra il tuo server e il client. Affrontiamo i vostri 4 punti singolarmente:

'Qualora l'utente ora viaggiare da mysite.com, a devious-site.com, è c'è alcun modo che qualcuno può ottenere i dati da 'basic_variable', semplicemente sapendo che la variabile è chiamata così?

Inerentemente, n. Le variabili e i nomi delle variabili sono memorizzati sul server e, poiché il codice viene elaborato in una vista HTML prima di essere inviato al client, il codice PHP non raggiunge mai il client. I dati memorizzati in variabili che altrimenti non vengono trasmesse al client sono sicuro sul server, a condizione che qualcuno non acceda al server o comprometta in qualche modo la sicurezza del server. Se i dati nella variabile data sono memorizzati in una sessione o cookie trasferiti sul cavo o sulla rete al client, potrebbero potenzialmente essere intercettati. Questo traffico non è crittografato per impostazione predefinita, a meno che non sia stato implementato OpenSSH tramite un certificato SSL o uno schema di crittografia simile.

'C'è un modo che l'utente corrente può vedere una stampa della variabile $ _SERVER ed effettivamente vedere tutti i contenuti memorizzati in esso?'

Se si 'echo', o altrimenti programmare il PHP per esporre i dati memorizzati in esso. Di nuovo, se la variabile viene mai messa da qualche parte dove viene inviata al client e non viene elaborata in HTML o altrimenti eliminata prima che venga inviata una risposta HTTP, è a rischio.

'Ho letto da qualche parte che i dati nella sessione o nei cookie devono essere "crittografati". Nell'esempio sopra, sono abbastanza sicuro che i dati vengano memorizzati nella sessione e che questa sessione sia protetta. È questo il caso o è sicuro solo se HTTPS è abilitato? '

Sì, HTTPS deve essere abilitato, ed è necessario avere un certificato SSL per crittografare i dati, altrimenti tutto nella vostra in chiaro le richieste HTTP/risposta sono soggetti a sniffing, attacchi di cross-site scripting, forgiatura del dominio, gli attacchi di reindirizzamento , E la lista continua. SSL sicuramente aiuta a prevenire gran parte di questo.

'negozi Drupal alcune informazioni nei cookie, se si sceglie di utilizzare i cookie come contrariamente alla 'sessione', come si fa che influenzano quanto sopra?'

I cookie sono memorizzati sul computer dell'utente. I dati contenuti nei cookie possono essere crittografati o cancellati dal server in modo che siano memorizzati in modo sicuro sul client, ma tutto è possibile. Se un potenziale hacker contraffa il tuo dominio, ottiene l'accesso ai cookie e tutto ciò che contiene. Se il cookie si collega a una sessione attiva, ha appena falsificato la propria identità e ha ottenuto l'accesso al proprio sito con la sessione della vittima. Poof. Furto di identità, modifica dannosa dei contenuti degli utenti, ecc. Drupal è stato sicuramente abbastanza a lungo da disporre di meccanismi per impedire questo; tuttavia, non sono un esperto di Drupal.

Speriamo che getti un po 'di luce. Best practice IMO, non memorizzare dati sensibili nella sessione! Se stai memorizzando informazioni identificative nei tuoi cookie, assicurati di avere un qualche tipo di implementazione per prevenire la falsificazione dei siti incrociati, ad es. in ASP.NET MVC utilizzo un token anti-contraffazione offerto nel framework.Vuoi un modo per assicurare che la persona che afferma di essere chi sono tramite cookie ha un altro modo per verificare la richiesta con detto cookie originato dal tuo sito/dominio, e non un altro.

Answer 2

I cookie sono accessibili solo dal dominio memorizzato da cui proviene il cookie. il dirottamento dipende dalla rete.

Answer 3

L'ID di sessione è memorizzato nel cookie dei client e nessun altro dominio può accedere ai cookie di altro dominio e gli stessi due server (due siti Web) non possono vedere la sessione dell'altro (finché non lo si memorizza nel server condiviso)

1: Con l'approccio generale è impossibile, ma esiste un modo. Per rendere la sessione disponibile su vari siti Web, è necessario memorizzare la sessione sul server comune e trasferire gli ID di sessione per GET/POST vars. Scrivi il tuo session_save_handler e memorizza le sessioni in un database. È possibile accedere al database da più server Web e il gioco è fatto.

2: La domanda non è chiara.

3: Sì https può proteggerti dal dirottamento di sessione.

4: La domanda è po 'poco chiaro, seguire questa URL per ottenere la differenza/rilevante tra sessione & cookie di

http://viveksoni.net/how-session-works-what-is-session/