Come proteggere i valori delle sessioni del negozio nelle applicazioni web?

Sì, è consigliabile eseguire hash token di sessione all'interno del database. In questo modo le sessioni non possono essere dirottate se i dati sono esposti. I token di sessione devono essere generati con almeno 64 bit di entropia .

Pertanto, valore fornito all'interno di cookie = token, valore memorizzato nel database = token hash.

A partire dal 2016, per creare l'hash si consiglia di SHA-2 . Nota che i sali non sono necessari per i valori generati usando una sufficiente entropia.

Spesso è richiesto un server di database per la memorizzazione delle sessioni lato server in cui i server sono raggruppati (anche se è possibile utilizzare un livello di memorizzazione nella cache). Sebbene tu possa utilizzare gestori personalizzati PHP per fare ciò, sembra che gli autori di Joomla abbiano deciso per eseguire il rollover, che è vulnerabile agli attacchi di estrazione dei dati come citato.

È inoltre consigliabile limitare l'accesso al meccanismo di archiviazione. Ad esempio, un account di database con accesso in scrittura alla tabella può essere utilizzato per l'accesso e il logout e l'aggiornamento della scadenza della sessione e un account di database per l'accesso in lettura per il controllo della sessione di accesso. Il resto dell'applicazione potrebbe utilizzare un account di database che non può accedere alla tabella delle sessioni. Un "pepe" segreto / "sale di sistema" potrebbe essere utilizzato per mitigare altri attacchi in cui la tabella di sessione potrebbe essere scritta.

No.

Nel codice che ci hai mostrato ci sono molti trucchi di prestigio, ma non una vera magia della sicurezza.

Generazione degli ID

Se accedo al sito web della mia banca e ottengo un cookie di sessione con valore 435812, non è necessario essere un hacker particolarmente esperto 733T per pensare che potrei vedere qualcosa di interessante se lo cambio in 435811, 435810, ...

Gli ID di sessione devono essere imprevedibili, ma allo stesso tempo unici . L'uso di un hash crittografico è un buon modo per creare un insieme di valori casuali e sparsi. Per coincidenza, la maggior parte delle implementazioni genera un valore che può essere trasferito su diverse rappresentazioni (pensate a urlencode, htmlentities, mysqli_real_escape_string ecc.) Senza ulteriore escape.

Recupero della sessione L'intero punto dei dati di sessione è che sono le informazioni memorizzate sul server che possono essere recuperate in una data successiva. Ciò significa che le richieste successive da parte di un utente devono essere associate allo stesso set di dati. Dal codice che ci hai mostrato, Joomla 1.1 sembra eseguire questa operazione mantenendo una tabella di ricerca che associa il valore del cookie all'ID di sessione. Se è possibile iniettare SQL, è probabile che si possa iniettare SQL con un join o una sottoquery al suo interno.

Modellazione delle minacce Ciò che è ancora peggio della mancanza di protezione che questo fornisce, è che rende l'enumerazione delle sessioni ancora più semplice - dal momento che un elenco delle sessioni disponibili è accessibile nel database.

Ma il blackhat per l'iniezione SQL è solo un modello di minaccia. Anche l'iniezione di codice è un rischio (in particolare sui CMS non mantenuti e pronti all'uso come Joomla. Inserire l'id di sessione direttamente nel cookie di sessione e utilizzare un gestore basato su file è altrettanto vulnerabile se l'utente malintenzionato può inserire codice PHP nel sistema.

Poi c'è la possibilità di attaccare lo storage direttamente - sia sul posto che da un backup per scoprire quali dati sono presenti nella sessione.

il modo migliore per gestire i valori delle sessioni

L'archiviazione in un database è il secondo minimo comune denominatore dopo averli memorizzati utilizzando il gestore predefinito sul filesystem. Semplifica la separazione dei dati di sessione tra i vhost su host condivisi (anche se non molto). È anche facile scalare su più dispositivi che servono lo stesso sito. E se il codice non ha i soliti privilegi di selezione sulla tabella sottostante ma funziona attraverso la separazione dei privilegi (ad esempio utilizzando stored procedure eseguite come un diverso UID del database), non possono essere enumerati.

Tuttavia, anche in questo caso l'applicabilità è limitata e non affronta il caso in cui i dati sono compromessi.

La mia soluzione era di cifrare i dati di sessione con una chiave generata casualmente che non è memorizzata sul server. Quindi i dati sono protetti a riposo. Ci sono dei limiti a questo approccio: limita la capacità e sarebbe un PITA per il supporto. Potrebbero esserci altri problemi che non ho previsto.