Nell'API Java Servlet, cosa viene fatto per garantire che l'ID di sessione di qualcuno non venga rubato?Cosa impedisce che l'ID di HttpSession venga rubato?
Ad esempio, se avessi una sessione attiva e qualcuno in qualche modo prendesse possesso del mio id di sessione, potrebbe usarlo?
Niente lo impedisce. Ottieni l'ID di sessione, puoi prendere parte alla sessione.
Nel solito caso di cookie questo non è un rischio di per sé. L'attaccante non dovrebbe essere in grado di leggere cookie di sessione di un utente a meno che:
hanno ottenuto man-in-the-middle capacità, nel qual caso hai problemi molto peggio solo ID di sessione;
hai lasciato un buco di cross-site-scripting, nel qual caso hai problemi molto peggiori rispetto agli ID di sessione;
sei vulnerabile agli attacchi DNS-rebinding/cross-domain-cooking, nel qual caso dovresti risolverlo consentendo solo le note note Host: richieste.
(Mentre si può provare le sessioni di legatura in indirizzi IP, questo rischia di rompere le sessioni valide a causa, ad esempio, i proxy round-robin. IP può essere utilizzato come parte di una strategia più ampia per il rilevamento di attività sospette, ma sul pubblico Internet non è una buona idea richiedere sempre che ogni richiesta in una sessione provenga dallo stesso IP.)
Sfortunatamente in Servlet vi è un altro caso, ad eccezione dei cookie: parametri jsessionid=. Dal momento che compaiono nell'URL stesso, questo li rende molto più dispendiosi (ad es. Tramite referrer e link incollati) più. E questo è lontano dall'unico problema pratico con gli ID di sessione dei parametri. Scombussolano la navigazione e distruggono SEO.
A mio parere jsessionid= Gli URL sono uno dei peggiori errori iniziali di Servlet, una strategia di fallback dei cookie screditata dal passato che non dovrebbe essere utilizzata per nulla. Ma certamente non dovrebbero essere autorizzati a concedere l'accesso a qualsiasi dato privilegiato; considerare l'utilizzo dell'autenticazione di base HTTP invece se è necessario un meccanismo di fallback per i browser che non supportano i cookie.
In Servlet 3.0 è possibile disabilitare facilmente gli indirizzi jsessionid= utilizzando <session-config> nello web.xml; sfortunatamente nelle versioni precedenti ti viene lasciato a bocca aperta con i filtri se vuoi disabilitare correttamente la funzione.
Sì, potrebbero usarlo. Non viene fatto nulla per proteggerlo a meno che non si carichi tutto il traffico su SSL.
Questo è il modo in cui funziona Firesheep, che ha ricevuto molta attenzione per rendere facile il furto di sessioni.
Il trasferimento di tutti i dati su HTTPS è davvero l'unica soluzione? Non ci sono framework o soluzioni alternative note? E anche se tutti i dati sono trasferiti su HTTPS, qualcuno non potrebbe scrivere un programma per provare a indovinare un ID sessione? –
Sì, tutte le informazioni che si inviano all'utente in modo che possano essere restituite potrebbero essere intercettate, quindi la crittografia è davvero l'unico modo per fermarlo. Per quanto riguarda l'ipotesi, solitamente gli ID di sessione sono progettati per essere abbastanza difficili da indovinare che non è pratico. –
Sì, l'ID sessione consente a qualcuno di accedere alla sessione corrispondente.
È possibile memorizzare l'IP utilizzato durante il login nella sessione e quando l'IP cambia richiede all'utente di effettuare nuovamente il login. Inoltre (non sono sicuro che sia fatto automaticamente) si potrebbe fare lo stesso per l'User Agent, non aumentando la sicurezza contro gli attacchi malevoli, solo contro gli utenti stupidi dando via il loro sessionid accidentalmente se è passato tramite GET e non un cookie.
+1 per la sessione-config in servlet 3.0 – Bozho