Il passaggio dell'id di sessione come parametro url è davvero insicuro?

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

Diciamo che visito il mio forum preferito. Mi accede 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 provveduto a garantire che ci sia qualche forma di convalida su l'ID di sessione, l'amico che ha fatto clic su quel collegamento potrebbe ereditare la mia sessione e quindi sarebbe in grado di fare tutto ciò che posso fare, come me.

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

Esiste una variazione su questo tema chiamata fissazione della sessione, che implica la condivisione intenzionale di un identificatore di sessione per scopi dannosi. L'articolo di Wikipedia collegato approfondisce come funziona questo attacco e come si differenzia dalla condivisione involontaria dell'identificatore di sessione.

Perché i cookie sono più sicuri?

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

Quali possibilità ha un aggressore per entrambe le opzioni?

Nessuno di questi metodi è protetto da attacchi man-in-the-middle su comunicazioni non crittografate. I componenti aggiuntivi del browser, lo spyware e altri dispositivi nocivi lato client possono anche spiare entrambi i metodi di memorizzazione degli identificatori di sessione.

In entrambi i casi, la migliore pratica è la convalida lato server del client che dichiara di possedere un ID sessione. Di cosa si compone questa convalida è in discussione. Tieni presente che gli utenti dietro proxy aziendali possono saltare da un indirizzo IP all'altro tra le richieste, quindi bloccare una sessione a un indirizzo IP potrebbe allontanare accidentalmente le persone. L'articolo sulla correzione della sessione menziona alcune altre utili alternative.

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

Un problema è che è facile effettuare attacchi di fissazione della sessione. In questo caso, un utente malintenzionato invierà all'utente un URL preparato con un ID di sessione noto. Se l'utente fa clic su questo URL e esegue un accesso, l'attaccante avrà una sessione con privilegi. Se il sito Web richiede un cookie, tuttavia, un URL preparato in un'e-mail non sarà sufficiente.

Se un sito utilizza HTTP combinato con HTTPS, l'id verrà trasmesso in chiaro nell'URL per tutte le richieste HTTP (anche per una richiesta di immagine). Quindi, se l'attaccante può leggere una singola richiesta HTTP dopo che l'utente ha effettuato l'accesso, conosce l'id di sessione.

Una via d'uscita dal problema sarebbe 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 quanto hanno detto Charles e Martin, inserire qualsiasi cosa nell'URL rende più probabile la perdita. Ciò può avvenire tramite un'intestazione Referer in una risorsa collegata, dall'accesso all'endpoint con i record della cronologia del browser, dallo sniffing della cronologia della forza bruta, dai registri Web protetti in modo inappropriato e così via. Quindi in genere è sconsigliabile mettere tutto ciò che si desidera mantenere segreto in un URL / stringa di query.

Non ho visto PayPal utilizzare gli ID di sessione del server negli URL. Non c'è modo che sia davvero più sicuro dei cookie; il motivo per cui è stato in genere fatto in passato era per supportare i browser senza cookie abilitati. Questa è sempre meno una preoccupazione in questi giorni, e i problemi di usabilità di non dover condividere i collegamenti, oltre agli attacchi di correzione della sessione, significano che la sessione nell'URL viene solitamente evitata oggi.

Qualcosa che ho visto alcuni anni fa è stato che qualcuno ha copiato un URL (CON sessionid) in twitter. Tutti i follower avevano quindi pieno accesso all'account di quella persona su quel sito.

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

L'ID di sessione aumenta la sicurezza quando i cookie sono già utilizzati. Immagina se ci fosse un link che trasferisce denaro dalla tua banca:

https://mybank.com/transferMoney?sum=10000&destAccount=someAccount

Se ti affidi solo ai cookie, questo link può esserti fornito in un'email di truffa. Quando lo apri e fai clic su questo collegamento, poiché hai un cookie nel tuo browser, sarà effettivamente funzionante. Trasferirai con successo (e inconsapevolmente) denaro dal tuo account a quello di qualcun altro.

Se il link fosse:

https://mybank.com/transferMoney?sum = 10000&destAccount = someAccount&sessionId = jow8082345hnfn9234

quindi un truffatore maligno non può inviarti l'email come quella sopra perché indovinare l'ID della tua sessione corrente è quasi impossibile.