Memorizzazione della sessione in querystring

Questo era un uso comune ai vecchi tempi in cui i clienti non si fidavano né dei siti Web né del browser Web per la loro sicurezza e privacy e rifiutavano costantemente javascript e cookie. Poiché HTTP è un protocollo non connesso, la sessione deve utilizzare alcuni dati per passare l'id di sessione tra il client e il server. Ciò significa che se non puoi utilizzare i cookie per le richieste GET, ti rimane solo un parametro URL. Ciò è stato implementato in molte applicazioni Web come sessione tramite riscrittura degli URL .

Ora è usato raramente, perché navigare nella maggior parte dei siti disabilitando i cookie è semplicemente impossibile. Quindi gli utenti sono stati educati a consentire costantemente i cookie nei loro browser.

Dal punto di vista della sicurezza, il passaggio dell'ID di sessione nell'URL non è peggiore del passarlo in un cookie: se qualcuno (tranne che l'utente stesso) può intercettare l'URL, può anche intercettare il cookie. Inoltre, la correzione della sessione non è più semplice con l'URL che con i cookie: è il problema del server che dovrebbe invalidare i vecchi ID di sessione e crearne uno nuovo dopo una corretta autenticazione. Anche i log non sono un problema: un ID di sessione ha senso solo per la durata della sessione e non è un dato sensibile a lungo termine. L'unico posto che potrebbe causare problemi è la richiesta cross-site di reindirizzamenti. In tal caso, l'intestazione REFERER potrebbe contenere l'id di sessione. Quindi un'applicazione ben progettata che utilizza la riscrittura degli URL per le sue sessioni, dovrebbe archiviare in modo coerente l'IP del client sul lato server della sessione e controllare che l'ID della sessione e l'IP del client corrispondano.

TL / DR: tale utilizzo è noto come sessione tramite riscrittura degli URL. Ora è usato raramente perché la sessione attraverso i cookie è molto più comune. Il problema non è la sicurezza perché la sicurezza di un parametro URL non è diversa da quella di un cookie, ma quel parametro aggiuntivo viene visualizzato nella barra del browser e può intrigare un utente o richiedere la rimozione per memorizzare un URL pulito come un segnalibro .

Tra il tuo elenco di potenziali problemi e il collegamento di iain, non c'è ancora molto da dire. Il fatto che la sessione abbia funzionato in una finestra di navigazione in incognito significherebbe che i cookie non sono coinvolti nell'autenticazione. Questo lascia una grossa possibilità per la fissazione della sessione. Se non altro, il tipo di fissazione in cui il cattivo crea un collegamento con il proprio token di sessione SEGRETO e inganna la vittima visitandola e salvando informazioni sensibili.

Inoltre, ciò significherebbe che l'applicazione utilizza GET per tutte le sue transazioni di aggiornamento o utilizza il POST con i parametri URL. Nessuna di queste è considerata una buona pratica (vedi questo link per maggiori dettagli). Le probabilità sono che l'applicazione stia violando l'idempotence del metodo.

Riepilogo dei possibili effetti negativi:

• Registri di tutti i tipi che potenzialmente registrano i token di sessione
• Potenziale violazione dell'idempotence del metodo HTTP
• Correzione della sessione

Giocando all'avvocato del diavolo, mi è sembrato che una tentazione dietro questo disegno potesse essere la protezione CSRF. Senza i cookie coinvolti e il traffico protetto da SSL, questo potrebbe avere un effetto simile alla protezione CSRF. L'hacker non ha il lungo hash necessario per creare l'URL corretto e nessun cookie coinvolto.

Finché il sito è protetto utilizzando HTTPS, tutte le query nell'URL vengono inviate anche crittografate, quindi non dovrebbe esserci nulla che possa esporre la query tra il PC e il server. L'unico problema a cui posso pensare è che potresti inviarlo accidentalmente ad altre persone tramite copia / incolla o condivisione dello schermo.