Causare la negazione del servizio da parte di "Session Spaming"

Come dice Anders, la possibilità che un utente malintenzionato occupi l'intero spazio dei nomi dell'ID di sessione non è un problema. Tuttavia ci sono altri colli di bottiglia che potrebbero essere sfruttati. Quelle ovvie sono la capacità di memorizzazione delle sessioni e l'impatto di un numero crescente di set di dati di sessione sul costo di recupero di un singolo set di dati.

Sebbene i dati di sessione siano piccoli, poiché vi è un grande vantaggio in termini di prestazioni per l'archiviazione dei dati di sessione in memoria, la quantità di spazio per allocata per l'archiviazione di sessione potrebbe essere dell'ordine di Mb / host anziché di Gb / host. per archiviazione non volatile. Sui cluster, potrebbero esserci dei colli di bottiglia nella larghezza di banda della replica. I file system meno recenti possono rallentare durante la dereferenziazione dei file in una directory con migliaia di voci.

What is this kind of attack called?

Nessuna idea (è un tipo di Denisal of Service, destinato a risorse limitate)

How can I prevent it?

Assicurati di avere più capacità per lo storage della sessione di quanto pensi di aver bisogno. Se la gestione della sessione non rimuove i dati in modo sincrono alla scadenza, assicurati di disporre della garbage collection aggressiva.

RTFM: il gestore predefinito di PHP, ad esempio, ha un'opzione per la distribuzione dei dati di sessione su più directory.

Controlla i tuoi sistemi.

How high is the risk in a real world scenario? (The attacker still needs a valid authentification.)

Direi che è possibile ma non ho mai sentito parlare di ciò che accade nella pratica. Se un determinato sito è vulnerabile? Fai la matematica - ad es. Supponiamo che tu usi memcache per l'archiviazione della sessione, che abbia 500 MB assegnati per l'archiviazione, una sessione TTL di 1 ora e una sessione media di 0,2 Mb, il che significa che per riempire lo storage un utente malintenzionato dovrebbe creare 2500 sessioni in un'ora o nuova sessione ogni 1,5 secondi - è fattibile. OTOH, con una dimensione della sessione di 0,02 Mb, 4 GB di spazio di archiviazione e un TTL di 10 minuti, è necessario creare oltre 300 sessioni al secondo, il che diventa difficile, soprattutto se si considera la larghezza di banda necessaria.

Se stai usando un buon sistema per generare ID di sessione, questo non sarebbe un problema. Per impedire a un utente malintenzionato di indovinare gli ID di sessione tramite forzatura bruta, è necessario disporre di uno spazio molto grande, in modo tale che in pratica ci siano molti ID possibili per eseguire questo attacco.

Un utente malintenzionato che è in grado di riempire l'intero spazio degli ID di sessione disponibili sarebbe in grado di impersonare qualsiasi utente che ha effettuato l'accesso forzando il suo ID sessione, qualcosa di molto peggio di DoS. Quindi, per proteggere da sistemi di rischio molto più grandi, i sistemi già utilizzati con ID di sessione con sufficiente entropia rendono praticamente impossibile.

Ad esempio, anche se l'ID di sessione ha solo 32 bit di entropia e una sessione dura per un giorno intero, è comunque necessario avviare 100 miliardi di nuove sessioni al secondo per utilizzarle tutte. Ciò sarebbe sufficiente per eseguire il server DoS solo dal traffico, quindi il numero limitato di ID di sessioni possibili non sarebbe il collo di bottiglia.

Un altro esempio è ID di sessione PHP . Di default stanno generando tramite MD5 una serie di cose, inclusa l'ora corrente. Quindi, a meno che non si verifichi una collisione hash per caso (estremamente improbabile) non ci saranno duplicati.

In aggiunta a ciò, suppongo che la maggior parte dei servizi abbia un qualche tipo di limite sul numero di sessioni aperte per un utente o un IP.

Poiché questo non è un attacco pratico, non penso che abbia un nome, ma sarebbe una forma di negazione del servizio. Penso che tu l'abbia battezzato con un buon nome nel tuo titolo.

The webserver will create a session and the user stores the session ID in his browser. Now the user delets his session cookie and refreshes the site. The user will get another session. But the webserver holds two sessions now.

Se sei preoccupato per questo, la cosa logica da fare è limitare il numero di sessioni simultanee che un utente può avere. Un sito web che visito con sessioni piuttosto intensive di risorse fa proprio questo: ti è permesso accedere da tre browser contemporaneamente. Accedi da un quarto e la sessione più vecchia è scaduta.

Imposta il numero di sessioni in base all'utilizzo previsto, ad es. una sessione per il desktop di casa, una per il desktop di lavoro, una per il laptop o lo smartphone e alcuni extra per situazioni inaspettate.

È molto facile eseguire questo tipo di attacco, usando curl o wget.

In uno dei progetti su cui ho lavorato, abbiamo utilizzato una cache di sessioni LRU (utilizzata da poco tempo) per utente e impostato la dimensione della cache LRU su 10. Quindi, supponendo che l'utente malintenzionato stia utilizzando lo stesso nome utente / password, non occuperà più di 10 slot. Questo ha funzionato abbastanza efficacemente per noi.