Perché passare l'id della sessione come parametro url non sicuro?

Is passing the session id as url parameter really insecure?

Sebbene non sia intrinsecamente non sicuro, può essere un problema a meno che il codice non sia molto ben progettato.

Diciamo che visito il mio forum preferito. Mi registra e aggiunge il mio ID di sessione all'URL in ogni richiesta. Trovo un argomento particolarmente interessante, e copia & incolla l'URL in un messaggio istantaneo al mio amico.

A meno che l'applicazione non abbia adottato misure per garantire che ci sia qualche forma di convalida sull'ID di sessione, l'amico che ha cliccato su quel link potrebbe ereditare la mia sessione, e quindi essere in grado di fare qualsiasi cosa io possa fare, come me.

Memorizzando gli identificativi di sessione nei cookie, elimini completamente il problema di condivisione dei link.

C'è una variazione su questo tema chiamato la correzione della sessione , che implica una condivisione intenzionale di un identificatore di sessione per scopi dannosi. L'articolo di Wikipedia collegato approfondisce il modo in cui funziona questo attacco e in che modo si differenzia dalla condivisione non intenzionale dell'identificatore di sessione.

Why are cookies more secure?

I cookie possono essere più sicuri qui, perché non sono qualcosa che i normali utenti possono copiare & incollare, o anche visualizzare e modificare. Sono un predefinito molto più sicuro.

What possibilities does an attacker have for both options?

Né di questi metodi sono al sicuro da attacchi man-in-the-middle su comunicazioni non criptate. Componenti aggiuntivi del browser, spyware e altri fastidi sul lato client possono anche spiare entrambi i metodi di memorizzazione degli identificativi di sessione.

In entrambi i casi, convalida sul lato server che il client che dichiara di possedere un ID di sessione è la procedura migliore. Di che cosa è composta questa convalida è in discussione. Tieni presente che gli utenti dietro i proxy aziendali possono saltare tra gli indirizzi IP tra le richieste, pertanto il blocco di una sessione a un indirizzo IP potrebbe accidentalmente allontanare le persone. L'articolo correzione della sessione menziona alcune altre alternative utili.

La maggior parte dei siti Web memorizza lo stato di accesso dell'utente nella sessione e se un utente malintenzionato ha l'id di sessione, ha anche i privilegi dell'utente connesso. In altre parole, le due preoccupazioni relative al mantenimento della sessione e dell'autenticazione sono spesso accoppiate.

Un problema è che è facile fare attacchi per la sessione . In questo caso, un utente malintenzionato invia un URL preparato con un ID di sessione noto all'utente. Se l'utente fa clic su questo URL e fa un login, l'utente malintenzionato dovrebbe avere una sessione con privilegi. Se il sito richiede un cookie, allora un URL preparato in un'email non sarà sufficiente.

Se un sito utilizza HTTP miscelato con HTTPS, l'id verrebbe trasmesso in chiaro nell'URL per tutte le richieste HTTP (anche per una richiesta di immagine). Quindi, se l'utente malintenzionato può leggere una singola richiesta HTTP dopo che l'utente ha effettuato il login, conosce l'id della sessione.

Una soluzione al problema sarebbe quella di separare le due preoccupazioni, mantenendo la sessione e l'autenticazione. È quindi possibile lasciare l'ID di sessione non protetto, solo per mantenere la sessione, e utilizzare un cookie separato per verificare lo stato di accesso. Questo cookie deve essere configurato per essere inviato solo alle pagine HTTPS.

Oltre a ciò che hanno detto Charles e Martin, l'inserimento di qualsiasi cosa nell'URL rende più probabile la fuga di informazioni. Ciò può avvenire attraverso un'intestazione Referer in una risorsa collegata, dall'accesso all'endpoint con i record della cronologia del browser, dallo snervamento della cronologia della forza bruta, dai registri Web non protetti in modo appropriato e così via. Quindi è generalmente sconsigliabile mettere tutto ciò che si vuole mantenere segreto in una stringa URL / query.

Non ho visto PayPal che utilizza gli ID di sessione del server negli URL. In nessun modo sarebbe davvero più sicuro dei cookie; il motivo per cui in passato era in genere era supportare i browser senza i cookie abilitati. Questo è sempre meno un problema al giorno d'oggi, e i problemi di usabilità di non essere in grado di condividere link, oltre agli attacchi di fissazione della sessione, significano che la sessione in URL è solitamente evitata oggi.

Qualcosa che ho visto alcuni anni fa era che qualcuno ha copiato un URL (WITH sessionid) in twitter. Tutti i follower hanno quindi avuto accesso completo all'account di tali persone su quel sito.

Quindi sì, inserire un sessionID nell'URL è una cattiva idea.

L'ID sessione si aggiunge alla sicurezza quando i cookie sono già utilizzati. Immagina se esiste un link che trasferisce denaro dalla tua banca:

link

Se fai affidamento sui cookie da solo, allora questo link ti può essere dato in una email truffaldina. Quando lo apri e fai clic su questo link, dal momento che hai un cookie nel tuo browser, sarà effettivamente funzionante. Con successo (e senza volerlo) trasferirai denaro dal tuo account a quello di qualcun altro.

Se il link fosse:

link

quindi lo scammer malintenzionato non ha potuto inviarti l'e-mail come quella sopra perché indovinare l'ID della sessione corrente è quasi impossibile.